Bad Code: Part V

Does holding software providers accountable for the insecurity of their code amount to going nuclear on the industry---the equivalent of pushing the big red button? I argue that this is the way critics see it, in the fifth and final installment of our Security States cyberliability series. Meanwhile proponents see liability as a far subtler weapon, along the lines of a many-levered machine. The distinction is a crucial one, one that suggests the two sides are talking past each other. Here's an excerpt from Part 5:

[H]olding software providers accountable for their code need not entail exposing software providers to lawsuits for any and all vulnerabilities found in their products. Liability critics battle a straw man when they make arguments like this one, from computer security authority Roger Grimes: “If all software is imperfect and carries security bugs, that means that all software vendors—from one-person shops to global conglomerate corporations—would be liable for unintentional mistakes.” Liability is a weapon far more nuanced than its critics believe. Geer and Grimes see liability as a big red button—a kind of nuclear option, to be avoided at all costs. Meanwhile proponents understand liability as a complex machine ideally outfitted with a number of smart levers. Consider: software’s functions range from trivial to critical; security standards can be imposed at the development or testing stage, in the form of responsible patching practices or through obligations for timely disclosure of vulnerabilities or breaches; the code itself might be open-source or proprietary or in any case free. An effective liability regime is one that takes these many factors into account when it comes to designing rules, creating duties or imposing standards.

Part 1 of the series explored the problems stemming from our collective unwillingness to hold software providers accountable for vulnerability-ridden code. Part 2 argued that the technical challenges associated with minimizing software vulnerabilities weigh in favor of, not against, imposing liability on software makers. Part 3 explained why leaving software security in the hands of the market is an idea about as bad as the average software user's cyber hygiene. Part 4 described why nothing short of rules on the books would change the current user-liability regime.