Bad Code: Part II

On a technical level, building secure software is really hard---but that's an argument for, not against, an intelligently designed liability regime. That's the bottom line in my post today over at Security States. This is the second installment in a series on whether and how to hold software makers financially liable for the insecurity of their products. Part 1 offered an overview of the problems associated with holding software makers responsible for insecure code. Part 2 opens:

It’s true: perfectly secure software is a pipe dream. Experts agree that we cannot make software of “nontrivial size and complexity” free of vulnerabilities. Moreover, consumers want feature-rich, powerful software and they want it quickly; and this tends to produce huge, bulky, poorly-written software, released early and without adequate care for security. Those who oppose holding software makers legally accountable for the security of their products often trot out this reality as a kind of trump card. But their conclusion—that it is unreasonable to hold software makers accountable for the quality of their code—doesn’t follow from it. Indeed, all of the evidence suggests that the industry knows how to make software more secure, that is, to minimize security risks in software design and deployment—and that it needs a legal kick in the pants if it is to consistently put that knowledge into practice.