The case for imposing legal liability on providers of insecure software has been in the making by scholars and researchers for decades. It is recently back in the spotlight as one of the strategic objectives outlined in the recent National Cybersecurity Strategy released by the White House. It has been called "revolutionary" and a "landmark moment for the industry," but "risky" and possibly "the most controversial aspect" of the strategy at the same time.

This issue invites strong objections from manufacturers and divides experts in legal and security communities. Not all insecure software is created equal; the key is to strike the right balance.

Why liability, why now

As cyber incidents continue to rise, the strategy urges more mandates on technology companies to protect their software from vulnerabilities and consumers from the risk of data breaches. When these companies ship products with insecure default configurations or known vulnerabilities, end users are left holding the bag, and the entire ecosystem suffers.

Market forces are not enough

The strategy points out market forces alone have not been enough to drive broad adoption of best practices. That leads to a race to the bottom as software vendors use contract law to shield themselves from liability. Ultimately, the strategy reflects the Biden administration's belief that the cascading, harmful effects of insecure software may not be adequately abated without the ability to impose legal consequences for failing to implement reasonable security.

Incentivizing reasonable security

The strategy echoes Cybersecurity and Infrastructure Security Agency Director Jen Easterly's proposal for Congress to advance legislation, to shift liability onto the providers who should be taking reasonable precautions to secure their software. The proposal would prevent them from disclaiming liability by contract, establish a standard of care and provide "a safe harbor to shield from liability those providers that do take reasonable measurable measures to secure" their software.

Legal precedence and framework

The theory of holding manufacturers of a product liable for defects is over a century old. Automobile makers used to disclaim liability for any flaws until the landmark decision in MacPherson v. Buick Motor Company established the product liability theory in 1916. It placed the absolute liability for any product defects with the manufacturer because it is in the best position to know the details. The same principle can be applied to those in the software supply chain who are best positioned to understand and address the risks in their software.

Liability for breaching standard of care

While product liability is absolute, it may only apply when insecure software is viewed as defective. An alternate theory of liability is based on a negligence claim. However, it requires a consumer to prove the manufacturer owed them a duty of reasonable care, the duty was breached and the breach caused them actual harm, or "causation." The exact standard would generally depend on industry-wide best practices such as reasonable security standards. Even if a breach is established, causation and actual damages become increasingly difficult to prove as software becomes more complex.

Liability for technology is complex

The challenge lies in designing a liability regime that incentivizes software providers to improve the security of their products without crippling the software industry or unacceptably burdening economic development and technological innovation.

Liability schemes can be designed in a manner far more nuanced than critics suggest. It would make sense not to hold all software providers to the same standard of liability, but  rather take the software’s intended use and associated harms into account. It should not be based on the number or types of vulnerabilities, but on deviation from reasonable security safeguards. Adopting such safeguards or standards could constitute the basis for a safe harbor to shield the provider from liability.

Shared responsibility can evolve into liability 

There is precedent in data privacy where a self-regulatory model evolved into regulation. The EU General Data Protection Regulation and the California Consumer Privacy Act established an expectation of reasonable care for protecting data, with accountability for those who fail to comply, while allowing safe harbor mechanisms for reducing friction in trans-Atlantic data transfers. Establishing the concept of safe harbors allows the industry to mature incrementally, leveling up security best practices to retain a liability shield.

An example of a self-regulatory approach in cybersecurity is the shared responsibility model. Though encouraging, cloud and software providers should take more responsibility to avoid errors or misconfigurations, according to Jason Chan, former vice president for security at Netflix. "Rather than expecting the end user (who is often not sophisticated in security practices) to do what it takes to use software securely, the providers should do it for them by implementing secure defaults," urges Chan, who is credited for implementing the secure-by-design philosophy at Netflix. That would be better than taking action after the fact, he says. For example, Peloton added a pin code to let users control who can use the product after multiple reports of accidental unsafe use. Similarly, Amazon Web Services tightened the default permissions for its user accounts after reports of numerous breaches caused by insecure configurations.

Liability risk may impact functionality

As a side effect of potential liability for insecurity, some providers may scale back the functionality their software provides. In other words, they may want to avoid risk exposure by focusing on building fewer features with more scrutiny for security defects.

Liability for insecure software may also conflict with liability protections for platform providers under Section 230, which protects them from liability resulting from third-party content, including taking or not taking action to remove such content. In situations when malicious content uploaded by the user affects the interactions of other users with the software, infecting them with malware for example, the presence of malware in the software could be viewed as a defect and subject to absolute liability, or inaction by the provider to remove the malware be subject to liability under negligence.

"There are many open questions about how liability would work and be limited, including what 'reasonable precautions' and standards of care would look like, how small and medium-sized businesses would be accommodated, and how safe harbor compliance would be evaluated," said RStreet Director of Cybersecurity and Emerging Threats Brandon Pugh, CIPP/US. "Holding a manufacturer accountable for willfully failing to act on security is different from holding a manufacturer that tried yet failed to prevent every vulnerability," he added.

Insurance can play a role

If software providers are prevented from disclaiming liability for insecurity by contract as envisioned in the strategy, it may be natural for them to rely on insurance to reduce their financial exposure. This is not unlike the role cyber insurance plays today in mitigating the risk of exposure to data breach liability that is often not allowed to be disclaimed by contract. More specifically, professional liability insurance, also called errors and omissions coverage, already protects from claims of negligence or professional malpractice for breaching a standard of care (if it can be proved and recovery is available), while product liability insurance may cover claims based on absolute liability, should it extend to software.

Coverage may also bring immunity

In the wake of the rising costs of data breaches, underwriters are now taking a fine-tooth comb to commercial cybersecurity practices. Insurers are focused on maintaining healthy cyber risk portfolios and raising the bar for coverage based on the cybersecurity maturity of the insured. On one hand, this creates incentives for software providers to adopt good cybersecurity hygiene. On the other, it may also make them eligible for safe harbor protection under the strategy.

This is a net-positive outcome because the providers are now incentivized to invest in a mature cybersecurity program to reduce their risk of exposure to liability, and they may potentially shield themselves fully from the liability while doing so.

Risk exposure will vary

It should be recognized that some providers may be unable to maintain the required level of cybersecurity maturity to protect themselves from liability exposure, or may be overwhelmed by cyberattacks that are "uninsurable." The risk may be passed to others in the ecosystem.

One scenario is the creation of a federal cyber insurance backstop to stabilize the markets against catastrophic risk, as anticipated in the strategy, effectively spreading the loss to the taxpayers. Another is the creation of clever financial instruments, such as catastrophe bonds, to pass the risk to those who invest in them.