Should Software Vendors Be Liable for Security Flaws?

TL;DR

Software liability could improve security by making vendors bear some of the costs created by insecure products, giving executives a financial reason to fund safer design, testing, and development. The opposing case warns that liability functions like regulation, could restrain innovation, and may misdiagnose a market in which customers have repeatedly favored inexpensive, feature-rich software over more reliable alternatives.

Transcript

So our goal today is to solve the unsolvable, is to resolve this issue once and for all, to help us understand is software liability our saving grace or the kiss of death? In order to help us make a decision, we have, uh, an esteemed, uh, set of debaters. I'd like to introduce Mr. Bruce Schneier, who is taking our for position, and Mr. Marcus Ranum... Read More

Key Insights

• Insecure software imposes recurring social costs through theft, productivity losses, network failures, inconvenient security controls, and purchases of protective products and services. Schneier argues that these expenditures manage the consequences of insecurity without necessarily improving the underlying software that creates the problem.
• A security externality exists when much of the cost caused by insecure software is borne by customers or society rather than the vendor. Schneier argues that weak consequences, limited bad press, and small market-share effects give vendors insufficient financial reasons to prioritize security.
• Software liability changes incentives by increasing the financial cost of releasing insecure products. The proposed objective is to make secure design, better implementation, adequate testing, longer development cycles, or reduced feature scope less expensive for a vendor than continuing insecure development practices.
• The appropriate liability level is somewhere between making vendors pay all security losses and making them pay none. Schneier presents liability as an iterative legal process that can allocate partial responsibility among multiple contributors, much as courts assess drivers, vehicles, and road conditions in automobile cases.
• Automobile liability is presented as evidence that legal responsibility can improve product safety. Schneier cites McPherson versus Buick, involving wooden wheels that could disintegrate at high speeds, to argue that letting buyers pursue manufacturers created incentives to correct dangerous defects.
• Liability costs would ultimately be passed to software customers, so Schneier does not predict large overall savings. His claimed benefit is a change in where the money goes: spending would support improvements to underlying software instead of repeatedly paying for losses and defensive measures.
• Software liability functions as regulation in Ranum's argument because it would place the software industry under greater control. He acknowledges that regulation improved air-travel safety but questions whether imposing it on a vibrant, growing industry would preserve the innovation that makes software valuable.
• Customer preferences have rewarded inexpensive, feature-rich software despite hidden reliability costs, according to Ranum. He argues that reliable systems already existed, including VAX VMS, IBM mainframes, and NASA software, but consumers allowed more mediocre alternatives to dominate the market.

Questions & Answers

Q: Why could software liability improve computer security?

Software liability could improve security by making vendors bear part of the financial consequences of insecure products. Schneier argues that vendors currently receive stronger marketplace rewards for features, performance, and rapid release than for security. If insecure design, poor implementation, or inadequate testing became more expensive, executives would have a business reason to invest in secure development, longer development cycles, and fewer risky features.

Q: What is a security externality in software development?

A security externality occurs when the costs created by insecure software are borne largely by parties other than the vendor that produced it. Customers and society pay through information theft, financial theft, productivity losses, unavailable networks, inconvenient security measures, and defensive products and services. Because vendors experience comparatively limited consequences, the economic incentives do not reliably encourage them to correct the underlying insecurity.

Q: Would software vendors have to pay for every security loss?

The liability proposal presented in the debate does not require vendors to bear every loss caused by insecure software. Schneier argues that making vendors pay either zero percent or one hundred percent would represent two extremes, with an appropriate balance somewhere between them. Courts could assign partial responsibility through an iterative legal process, considering the conduct and contribution of the different parties involved.

Q: How does automobile liability support the case for software liability?

Schneier uses automobile liability to show that courts can address complicated responsibility and encourage safer products. An accident can involve two cars, two drivers, and road conditions, yet courts still allocate partial liability. He also cites McPherson versus Buick, a case involving wooden wheels that could disintegrate at high speeds, as an example of manufacturer liability motivating correction of dangerous defects.

Q: Would software liability reduce what society spends on security?

Schneier does not claim that liability would produce large overall cost savings. Vendors facing liability expenses would pass at least some of those costs to customers, so society would continue paying for security. The proposed improvement is that more spending would flow toward secure design, implementation, testing, and development processes, rather than being consumed mainly by theft, disruption, inconvenience, and products that manage existing weaknesses.

Q: Why might software liability reduce innovation?

Ranum argues that liability would effectively operate as government regulation by bringing a vibrant, growing industry under greater control. He accepts that regulation can improve safety, using air travel as an example, but questions whether regulated industries become more innovative. From this perspective, imposing legal responsibility could constrain the experimentation and rapid development that characterize software, even if it also encourages greater reliability.

Q: Can the market make software vendors improve security?

Ranum argues that vendors already face a market form of liability because customers can stop buying poor products, causing their producers to change or fail. He points to Japanese manufacturers gaining ground against Detroit by offering economical and sufficiently reliable cars. Applied to software, his argument is that dissatisfied customers should reject unreliable products and reward vendors that produce better systems.

Q: Why does Ranum partly blame customers for unreliable software?

Ranum argues that consumers chose free or inexpensive, mediocre software with many hidden costs over products that were more expensive and reliable. He cites VAX VMS, IBM mainframe operating systems, and NASA software as evidence that dependable systems could be built. In his view, market demand favored abundant features and attractive interfaces, so customers helped create the incentives that allowed less reliable software to dominate.

Summary & Key Takeaways

• Bruce Schneier argues that society repeatedly pays for insecure software through theft, lost productivity, operational disruptions, inconvenient security measures, and defensive products. Because vendors bear little of these costs, they lack sufficient financial motivation to improve underlying systems. Partial liability could redirect spending toward preventing insecurity rather than merely managing its consequences.

• Marcus Ranum argues that imposing liability would effectively regulate a vibrant software industry and could impair innovation. He treats security as part of general system reliability and points to VAX VMS, IBM mainframes, and NASA systems as evidence that dependable software can be built when customers accept the associated priorities and costs.

• The debate contrasts two mechanisms for improving software: legally shifting some costs to vendors or allowing customers and competition to discipline poor producers. Both positions acknowledge that more secure and reliable software is possible. Their disagreement concerns who created current incentives and whether courts, regulation, consumer choice, or market competition should correct them.