Biden's cybersecurity strategy raises questions of liability

When the Biden-Harris administration announced their new National Cybersecurity Strategy on March 2, it introduced five distinct pillars: 1) Defend Critical Infrastructure, 2) Disrupt and Dismantle Threat Actors, 3) Shape Market Forces to Drive Security and Resilience, 4) Invest in a Resilient Future, and 5) Forge International Partnerships to Pursue Shared Goals.

Arguably the most innocuous sounding of these five could prove to be the most contentious; pillar three sets out the strategic objective (3.3) to “shift liability for insecure software products and services.” This would entail, among other things, legislation that will establish liability (of manufacturers and software publishers) for insecure or vulnerable products and services. The requirement could also be seen as work to support and extend the “Securing Open Source Software Act of 2022” which is still undergoing committee scrutiny.

Shifting Responsibility from Buyers to Vendors

While the aim of moving the burden from those least capable of effecting change (the customer) to those most capable (the vendor) seems worthwhile at first glance, there are potential pitfalls that must be very carefully considered. Should software vendors be liable for vulnerabilities in the products they sell?  Are they already liable to some degree, or would new legislation be required in order to make it so?

In almost every case, the end-user license agreement for software products will reveal a host of exculpatory clauses, exonerating the vendor of responsibility for any kind of direct, indirect, consequential (and just about every other applicable adjective) damages “whatsoever” that may arise from the installation or use of (or inability to use) the software product. Is this reasonable or indeed fair?

Software products are not a tangible asset and as such escape much of the legislation that applies to the sale of goods and their fitness for purpose. However, a huge number of successful compromises of systems and enterprises arise from the exploitation of a vulnerability or flaw in an application or operating system, or a weak default configuration, and often results in direct data loss and its associated consequences such as exposure of intellectual property or personal identifiable information, brand damage, and financial loss.

Assessing the Impact of Liability

At first glance the case for enforcing some kind of liability on vendors seems obvious. Make the vendor legally responsible for the quality of their product and thus increase their focus on secure code development and maintenance. Lower the number of vulnerabilities in published products and create an ecosystem where vendors routinely produce more robust software. The idea is not a new one. Indeed, in the United Kingdom all the way back in 2007, a House of Lords Science and Technology Committee report on personal internet security reached the following conclusion (8.15):

“We therefore recommend that the Government explore, at European level, the introduction of the principle of vendor liability within the IT industry. In the short term we recommend that such liability should be imposed on vendors (that is, software and hardware manufacturers), notwithstanding end user licensing agreements, in circumstances where negligence can be demonstrated. In the longer term, as the industry matures, a comprehensive framework of vendor liability and consumer protection should be introduced.”

Similar calls have been echoed by such luminaries as Bruce Schneier and the European Commission. But what would be the consequences and does adequate cover exist already?

The first and most obvious is that it may well increase the cost of developing software. It is impossible to create invulnerable code, so vendors would be obliged to take out unlimited liability insurance contracts against the inevitable stream of lawsuits (the cost of this being passed on to the customer).

This level of liability could effectively sound the death-knell for free and open-source software (FOSS), much of which forms the basic underpinning of today’s web-based services (for both public and private sectors) as well as the security of our communications – Particularly when the temptation might exist for companies to skimp on even the most basic of security practices, passing the buck to the software vendor when a breach occurs.

Patching Vulnerabilities is a Grey Area

Another unintended consequence could be equally costly for the buyer. What happens when the vendor releases an updated product addressing identified flaws with an earlier version? Would cover cease for the now legacy versions, obliging customers to commit to expensive and perhaps unnecessary upgrades to continue to benefit from their newfound legal protection? Where do we truly stand right now? Are those end-user license agreements worth the bits they’re written on? Is new legislation required or even worthwhile?

In the traditional defense of the ignorant, “I Am Not A Lawyer!” So, I’ll defer to the opinion of a colleague who says: “if a software vendor negligently exposes its software to vulnerabilities, in particular because of defects in the software or non-compliance with best practices, under current law it can be held liable for all consequences arising therefrom. Exculpatory clauses in end-user license agreements can limit liability but the validity of such clauses have to be examined on a case-by-case basis.”

Bear this in mind though: the vast majority of breaches involving vulnerabilities are the result of the exploitation of those for which a patch has already been released by the vendor. Even with a physical good such as a car, the vendor is not required to fix the (potentially life-endangering) fault, only to issue a recall and make the necessary changes. Is it really so different, and if you don’t respond to the recall notice, or install the patch, where should the liability lie in those cases?