Biden’s National Cybersecurity Strategy will hold Software Companies liable for defects

It has been nearly two weeks since the Office of the National Cyber Director has released a National Cybersecurity Strategy grouped into five pillars. For those looking for details on the entire plan, please read the fact sheet and full 39 page announcement for the most information we know at the moment.

Within Strategic Objective 3.3 the administration states that software makers “must also be held liable when they fail to live up to the duty of care they owe consumers, businesses, or critical infrastructure providers.” This defines the intention behind the strategic objective, but remains broad in the definition of those entities. As we know, the software supply chain is a complex co-mingling of components and technology stacks, all of which could be defined as a liable entity. So let’s collect the criteria from the announcement which can help us identify an entity held liable:

‣ Companies that “fail to live up to the duty of care they owe consumers”

‣ Entities which “fail to take reasonable precautions to secure their software”

‣ Vendors which “ignore best practices for secure development”

‣ “Stakeholders most capable of taking action to prevent bad outcomes”

Duty of Care

Let’s first critically analyze what is meant by duty of care. This could reference 1. An obligation to obey a law. 2. A legal obligation to another person, who has a corresponding right. 3. An obligation whether legal, moral, or ethical.

Based on these definitions it’s indicative that future law regarding software rights will define software makers responsibilities. Additionally in this strategic objective it states that future legislation is set to “prevent manufactures of and software publishers with market power from fully disclaiming liability by contract”.

Expect future definition surrounding “publishers with market power” to emerge in the coming months. I would anticipate that those who represent a majority of software component distribution relative to commercial offerings to be held liable of security defects, regardless of the developer or software origin.

Reasonable Precautions and Best Practices

The overall strategy makes it reasonably clear that the NIST Secure Software Development Framework (SSDF) will serve as a foundation for the safe harbor framework. While the framework is not yet published and requirements are unknown, we do know that it will evolve to incorporate “software development, software transparency, and vulnerability discovery”. What is yet to be defined are the ramifications for those who fail to comply.

Expect that software utilized in high-risk scenarios will require higher standards of care. In particular with respect to the development, validation, and verification practices of critical infrastructure. For software makers which have historically taken a closed source only stance, anticipate software build and software provenance to be a condition of this additional transparency and vulnerability discovery requirement.

Taking Action

I have saved the broadest and most fun for interpretation for last, taking actions to prevent bad outcomes. Actions taken could refer to 1. Civil lawsuit or criminal prosecution, i.e. civil action and common law action. However, the preventative nature of Strategic Objective 3.3 would suggest it’s more likely defined as 2. An act or related series of acts; conduct or behavior... Let’s hope that further clarification prevents one definition from leading to another.

While attempting to define bad outcomes, I would encourage businesses to look beyond generalized software security defects and consider their SEC 10-K item 1A Risk Factors. Risk of cyber incidents and data breach alone do not encompass all of the impacts perpetrated by software defects. The inevitability of operational, financial, and other material impacts resulting from direct or third party software defects are significant.

Expect the definition of taking action to evolve with the landscape of software security and software defects. However, Strategic Objective 3.3 does cite specific software security activities. These include performing “coordinated vulnerability disclosure across all technology types and sectors; promote the further development of SBOMs; and develop a process for identifying and mitigating the risk presented by unsupported software”. Software makers will need to know their software bill of materials, and drive risk reduction of the vulnerabilities within them.