What Heartbleed tells us about software liability

[Commentary] The technology press has been awash in stories recently about the so-called Heartbleed bug that releases sensitive user data from any service using the OpenSSL encryption library.

To hold companies accountable for Heartbleed, we would need not product liability or restrictions on contract liability waivers, but rather, some sort of tort liability for service operators. Internet services can grow very popular very quickly. Consequently, increased liability could result in a structural shift in the Internet ecosystem.

Large, established companies such as Facebook or Google would likely become more averse to security risks, making them more cautious and shy about innovation. Small startup companies, on the other hand, who are constantly at risk of failing, would not have the resources or incentives to increase security and would take the risk of innovating without investing in security. Therefore, smaller companies would get an increasing advantage over their slower-moving, larger rivals who delayed new innovation in order to minimize security risks. Such a market, where low-security startups represent an increasing share of the computing industry, would be inherently more hazardous.

Ideally, large companies would voluntarily collaborate to improve the security of common shared infrastructure like OpenSSL or Linux. However, no intervention along these lines is likely to more than a moderate benefit. We don’t have robust ways to measure security improvements, or how security-critical any piece of code is. As a result, we aren’t going to be able to construct robust incentives here. Ultimately, the right lesson to draw from the Heartbleed bug is that we do not yet know the right technical or social mechanisms for building large software systems securely and economically.

[Rabkin is a researcher interested in techniques for building and debugging complex software systems]