Shostack + Friends Blog Archive


Liability for bugs is part of the solution

Recently, Howard Schmidt suggested that coders be held personally liable for damage caused by bugs in code they write. The boldness of this suggestion is exceeded only by its foolhardiness, but its motivation touches an important truth — alot of code stinks, and people are damaged by it.

The reason good programs (which means those with fewer bugs) do not drive poor programs from the market lies in the information asymmetry characterizing the software market. As discussed by Ross Anderson [PDF], the market for software is a “market for lemons“: sellers know more about the quality of their product than do buyers, leading buyers to assume the worst, lest they (in their optimism) be taken to the cleaners. Higher-quality products are thus driven from the market, leaving a market of lemons.

Solutions to this suboptimality include the use of guarantees — presumably, a car dealer willing to warranty a vehicle for many months has reason to believe it is not a lemon, and evaluation schemes: an automaker who can point to a “5-star rating” by an independent evaluator presumably can command a higher price.

Legal liability is also an appropriate remedy in that the possibility of getting hammered by a jury provides an incentive to be truthful about product quality, but my point is that it is only part of the mix.

In the case of software, guarantees are rare but not unheard of, and some evaluation schemes wind up being captured by vendors.

Independent researchers who identify SW vulnerabilities also act as evaluators of a sort — if, that is, all SW is subject to the same amount of scrutiny. It isn’t, of course, which is why rigorous research into methods of predicting software quality is critical. Andy Ozment is doing good stuff [PDF] on this.

Hopefully, continuing research and greater data availability will allow us to have a more compact and tractable for non-geeks version of this (from instead of a shrink-wrap license:

Software Facts

Name InvadingAlienOS
Version 1996.7.04
Expected number of users 15

Modules 5 483
Modules from libraries 4 102

% Vulnerability

Cross Site Scripting 22 65%
Reflected 12 55%
Stored 10 55%

SQL Injection 2 10%

Buffer overflow 5 95%

Total Security Mechanisms 284 100%
Authentication 15 5%
Access control 3 1%
Input validation 230 81%
Encryption 3 1%
AES 256 bits, Triple DES

Report security flaws to: ciwnmcyi@mothership.milkyway

Total Code 3.1415×109 function points 100%
C 1.1×109 function points 35%
Ratfor 2.0415×109 function points 65%

Test Material 2.718×106 bytes 100%
Data 2.69×106 bytes 99%
Executables 27.18×103 bytes 1%

Documentation 12 058 pages 100%
Tutorial 3 971 pages 33%
Reference 6 233 pages 52%
Design & Specification 1 854 pages 15%

Sun Java 1.5 runtime, Sun J2EE 1.2.2,
Jakarta log4j 1.5, Jakarta Commons 2.1,
Jakarta Struts 2.0, Harold XOM 1.1rc4, Hunter JDOMv1

Compiled with gcc (GCC) 3.3.1

Stripped of all symbols and relocation information.

When vendors know we know what they know, they won’t act so much like used car salesmen, particularly if it’d get them hauled into court.

Edited at 2342 CST 10/20/2005 to add author ID at top, and missing paragraph tag

3 comments on "Liability for bugs is part of the solution"

  • Chris Walsh says:

    I should add that *personal* liability is foolish, and that *vendor* liability isn’t.

  • 1 Raindrop says:

    Product Security Evolution

    The Emergent Chaos Jazz Combo has a post on vendor liability as part of the solution. I agree that liability may indeed be part of the solution, but what about the market? I know that software is likely to remain a market for lemons, but Oracle’s recen…

  • What the heck is up with software facts labels?

    Chris Walsh points to in favor of Paul Black’s Software Facts labels. The analogy here (explicitly made by Black) is to the “Nutrition Facts” labels found on food). But compare Black’s sample label to a real nutrition label: –> Software…

Comments are closed.