Bad Code: Part IV

If you believe software providers should be held more accountable for insecure code or coding practices, you might be tempted to point an accusing finger at the contract law framework that courts use to parse software license agreements. The problem is a little bigger than contract law, I argue, in the latest installment of our Security States cyberliability series. Part 1 in 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. Here is an excerpt from Part 4:

UCC freedom-to-contract principles serve as the pretext by which courts are able to uphold the liability disclaimers and limitations on remedies found in all commercial software licensing agreements. But this is not the end of the story. Other factors help explain why, in one high-profile case after another, software users alleging defects and security breaches get their cases thrown out of court. These factors are important insofar as they offer insight into how the courts understand code—and suggest that the grounds on which courts construe the rules of contract law in favor of software providers would similarly forestall user attempts to impose liability on providers through existing consumer protection laws or through claims sounding in tort. Indeed, software liability is unlikely to get off the ground without the help of legislation or regulation specifically designed to impose certain duties on software providers.