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. And there is an effective, if unsexy, solution on the horizon: shifting product liability for bad code.
In today’s software landscape, there is essentially 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. As long ago as 1986, a federal court held that Apple could not be sued for bugs in its software, having disclaimed liability and made no claim that the code was bug free.
But where life and death are at 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 in the automotive field when a self-driving car is hit with ransom-ware… 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 are already seeing 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.
But whatever the ultimate mechanism used to ensure the industry bears some of the costs of insecure code, the way for companies to be proactive is to adopt best practices and standards of software development that involve the process by which code is written and patched.
This will require the development of audit and grading mechanisms to support insurance risk-rating. If we assume there is some sort of liability for bad code – now we are going to need insurance for it. Liability, after all, means money – specifically, money paid to those who are injured by the alleged flaw in the code. No company wants to bear that cost by itself.
So, some questions to ask yourself if we are to look out at this horizon:
- 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 capable of being securely updated in a prompt and agile way?
- Finally, how is your software incorporated in the physical systems you are building? Is there, for example, a 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 is a unique exception whose privileged status cannot be sustained forever – 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.