When designed poorly, any software can pose risks to the public. Things like the loss of personally identifiable information or enlistment into a botnet for a distributed denial-of-service attack are just the tip of the proverbial iceberg. Fortunately, there is a useful — if unsexy — solution on the horizon: shifting product liability for bad code.
Software Liability Laws
In today’s software landscape, there is virtually no liability for software failures. The standard ‘click-wrap’ contract that comes with any software package disclaims liability and shifts responsibility to the end-user – and for the most part, courts have upheld those agreements. In 1986, a federal court held that Apple held no liability for bugs in its software because they made no claim that the code was bug-free.
But when life and death are an issue, responsibility and liability cannot be far behind. We don’t know what the disaster that triggers a call for reform will look like: It could be in the medical field with a failure of life-saving technology, or the automotive field when ransom-war hits a self-driving carr. Whatever it is though, there will be inevitable demands for liability systems. And if the industry is not proactive in its approach, it may well face increasing regulatory intervention.
In fact, we already see movement in this realm: Since 2013, the Federal Trade Commission has successfully settled with several companies it has accused of failing to take reasonable steps to secure their products. Most recently, the FTC filed a complaint against D-Link Corporation for allegedly preventable vulnerabilities in its routers and internet cameras.
Fortunately, companies can proactively adopt best practices and standards of software development including the process by which code is written and patched. This method requires the development of audit and grading mechanisms to support insurance risk-rating. If we assume there is some degree of liability for bad code, and we need it to be insured. Liability, after all, means money – specifically, money paid to those injured by the alleged flaw in the code. No company wants to bear that cost by itself.
How to Reduce Liability for Bad Code
To reduce liability for bad code, ask yourself the following questions:
- Can you explain to policymakers and insurers how you design and develop your software products? Do you do adversarial testing on your products and for critical components of your supply chain? If not, why not?
- Are you open to third-party research that finds flaws in your systems? Too often, developers are resistant to outside scrutiny. If you have a good-faith report of a problem, how do you respond to it?
- What are the forensics of your systems? Do they provide tamper-evident, forensically sound logging, and evidence capture to facilitate safety investigations?
- Are your systems updated securely, quickly, and agilely?
- Finally, how is your software incorporated in the physical systems? Is there, for example, physical and logical isolation that separates critical systems from non-critical systems?
It is almost impossible to think of any other consumer product in widespread use for which some type of liability does not exist. From cars to pharmaceuticals, to the ladder in your garden shed – a flawed product means that the manufacturer will pay.
Software’s privileged status is not sustainable – especially as consumers grow more dependent on software for their personal safety and health. Software liability is inevitable – it’s only a question of how, when, and why.
Take a proactive approach to software liability concerns with third-party software testing. Contact us to learn more.