Software Testing Blog

Software Liability Revisited

I sauntered over to the RSA session on Software Liability which was to be a debate between Bruce Schneier and Marcus Ranum. Frankly, I was more interested in meeting Bruce Schneier in person than in the topic, which has been bantered about in academic circles and blogs for close to a decade now. So, I was quite surprised at the standing room only session.

While neither party disagreed that we need more secure software, there was a lively debate on how we should go about achieving this goal: whether it be via regulatory action (in the form of software liability) or market demand.

Schneier came down on the side of software liability, taking the stand that software vendors should be liable for the malfunction of their products just as manufacturers of physical products such as cars, medical devices and chainsaws are held liable. He cited the landmark case of MacPherson v. Buick Motor Co , where the car manufacturer was held liable for a defective car that caused personal injury, even though the car was sold through a dealer. Schneier argued that introducing product liability for software would dramatically improve the quality of software. Currently, software vendors are only concerned with insecure software costs that immediately impact them, not with the total costs of insecure software – for instance, the cost in millions of dollars from a data breach to the companies that use the software and to the end users who have lost personal and financial information. So dealing with externality costs here would improve things by moving costs to where it is most effectively spent, i.e. fixing the risk rather than just mitigating it.

Ranum took the side of market demand – that the market should be left to determine quality – if consumers continue to choose to settle for “free and mediocre over good and expensive”, then so be it. However, if corporations and consumers boycotted buggy software products by refusing to purchase them, this will put financial pressure on the software industry to change how security is viewed. He trotted out the car analogy saying that Japanese car manufacturers, by producing better quality cars, essentially destroyed the Detroit car industry. He argued that introducing more regulation was not the answer, as it would stifle innovation by giving unfair competitive advantage to large software companies who can afford the costs to ensure better software quality.

The debate ended with a quick poll where folks in the audience texted in their votes. Ironically a glitch in the polling software allowed a voter to cast multiple votes but I decided to participate anyway, figuring that a less than robust voting option was better than none. My actions probably did not help with future improvements of this voting app. Incidentally, Schneier won by a huge margin with 75% of the votes. From the questions posed to the debaters as well as polling results, I sensed a level of frustration in the audience over this issue.

From the perspective of code development, this topic has its roots in the age old conflict of priorities between developers and security teams where additional features continue to do battle with product security. It is not that developers do not want to develop high quality, secure products but they often have to choose between developing new features and releasing the products quickly to market over fixing defects sent to them by the security audit teams. Besides the lack of financial incentives to invest in strengthening security, developers are not traditionally trained to be security experts and most of the automated tools for identifying defects in software code are the premise of the security team and designed with the security auditor in mind.

However, with the recent breaches and massive losses incurred as hacking becomes an organized crime, I suspect that software liability will become more than just an academic debate. We are already seeing class action suits filed against companies like Sony and Dropbox for the loss of private customer data. The risks are accelerating and the stakes are getting too high for this issue to be ignored. The solution may not be just a matter of putting software liability legislation in place – it should also be combined with increased security training for developers as well as proper testing tools designed for the needs of the developer.

Leave a Reply

Your email address will not be published. Required fields are marked *