CH. 5 - Bad Code:
Exploring Liability in Software Development
Chapter Description
The debate over liability standards for software developers continues to rage, without resolution. Summarizing the key technical and legal issues in establishing liability for software vendors, this chapter explains the status quo and proposes what an effective liability regime could look like in the near future.
Jane Chong
Author
Jane Chong is a graduate of Yale Law School. She previously researched national security issues at the Brookings Institution as a Ford Foundation Law School Fellow.
Chapter Highlights
-
Socially Acceptable Bad Code. Most security breaches are made possible by vulnerabilities, yet poor quality software remains the market norm. Experts have long attributed this state of affairs not to the technical challenges of producing safer code, formidable though they are, but to social acceptance of software insecurity.
-
End Use License Agreements (EULAs). These contracts have long been bundled with virtually all software products and force users to “take it or leave it.” Software vendors typically shunt all the risks associated with their products onto users through these boilerplate license agreements, which the courts have generally treated as enforceable contracts since the mid-1990s. Software vendors are, as a result, virtually bulletproof, as they may simply contract away responsibility for the deficiencies of their products with sweeping disclaimers. Software users, not vendors, bear the costs of insecure software.
-
Understanding Negligence. Negligence typically requires establishing four elements: that the software vendor owed the user a duty, that the vendor breached that duty, that the breach caused the user injury, and that harm was caused by the injury to the user as a result of that breach. But each of these elements poses special challenges in the software context.
-
Market Failure. Not only are users relatively apathetic about software security, we systematically disregard it in favor of functionality. The appetite for more and improved features has encouraged the industry’s “fix-it-later” culture. Thus software companies look for bugs late in the development process and knowingly package and ship buggy software with impunity, relying on timely release and incremental patching as a primary security strategy. Users are sluggish about deploying security fixes, even in the case of critical vulnerabilities (research shows 75% of targeted attacks could be prevented through regular patching).
-
Limiting Liability. The objective must be to influence vendor design and development choices without unduly restricting them. This balance might be struck by imposing on vendors certain self-certification or public reporting requirements that make transparent and easily understandable to consumers their adherence to or departure from industry standards and best practices. Best practices, in turn, could constitute an affirmative defense against regulatory fines, and might range from periodic independent security audits to participation in a ratings system for software security. That said, not all software providers can or should be subject to liability or regulation. Most notably, imposing liability on contributors to free open source software is an incoherent proposition.