Because software licenses and the
Uniform Commercial Code severely limit vendors from liability for security flaws
in their code, companies today cannot
be effectively sued or punished when
they are negligent and the flaws are exploited to cause economic harm.
9 Legislation or regulation is needed to change
this and remove the ability of companies
to exempt themselves through licensing
agreements. Developing a suitable liability regime will be a challenge, however, as the system must address the
concerns of both software developers
and users. Perhaps a good start would
be for ACM to sponsor a workshop that
brings together a diverse community of
stakeholders and domain experts to recommend a course of action.
Of course, holding software companies accountable will not solve all
our security woes. Many cyber-attacks
exploit weaknesses unrelated to faulty
software, such as weak and default
passwords and failure to encrypt sensitive information. But companies are
liable when their systems are attacked,
and they can be successfully sued for
not following security standards and
best practices. The time has come to
make software vendors liable as well.
1. Baker, H. Re: Zero-day bounties. The Risks Digest 28. 25
(Sept. 9, 2014).
2. Bilge, L. and Dumitras, T. An empirical study of zero-day attacks in the real world. CCS’ 12 (Oct. 16–18,
Raleigh, N.C.); http://users.ece.cmu.edu/~tdumitra/
3. Carman, A. Shellshock used to amass botnet and
execute phishing campaign. SC Magazine (Oct. 15,
4. CERT Coding Standards; http://www.cert.org/secure-coding/ index.cfm.
5. Finifter, M., Akhawe, D., and Wagner, D. An empirical
study of vulnerability rewards programs. USENIX
Security 13; https://www.eecs.berkeley.edu/~daw/
6. Geer, D. Cybersecurity as realpolitik. Blackhat 2014;
7. National Vulnerability Database, National Institute of
Standards and Technology; https://web.nvd.nist.gov.
8. Rice, D. Geekonomics: The Real Cost of Insecure
Software, Addison Wesley, 2008.
9. Scott, M.D. Tort liability for vendors of insecure
software: Has the time finally come? Maryland
Law Review 67, 2 (2008); http://digitalcommons.
10. Zetter, K. Obama: NSA must reveal bugs like Heartbleed,
unless they help the NSA. Wired (Apr. 15, 2014); http://
Dorothy E. Denning ( email@example.com) is Distinguished
Professor of Defense Analysis at the Naval Postgraduate
School in Monterey, CA.
The views expressed here are those of the author and
do not reflect the official policy or position of the U.S.
Department of Defense or the U.S. federal government.
Copyright held by author.
ity or code the licensee decides.”
escape clause, which would cover free
and open source software, would allow
users to inspect and cut out any software they did not trust.
My main concern with Geer’s proposal relates to absolving any code offered
commercially from liability. As a practical matter, very few users are in a position to inspect source code. Even those
that are can miss significant flaws, as
seen with Heartbleed, a flaw in OpenS-SL that gives attackers access to sensitive information, and also ShellShock.
In addition, exemption does nothing
to incentivize the production of more
secure open source code. At the same
time, penalizing a large, volunteer community for flaws in their code would be
both difficult and distasteful.
A better way around this dilemma
might be to exempt the immediate developers of open source code, but hold
accountable any company that embeds
it in their products or that offers services for open source products. Under
such a provision, if an individual or
group of volunteers offers a free, open
source App, they would not be accountable, though any company offering it
through their App store would be.
This compromise would incentivize software companies to pay greater
attention to security in all of the code
they offer through their products and
services, regardless of whether the
code is developed in house, by a contractor, or within the open source community; and regardless of whether the
product is released with source code or
the capability to disable certain functions. Moreover, given that many companies contribute to open source development, they would be incentivized
to promote secure coding practices in
the open source community as well as
within their own development teams.
Importantly, as with other forms of
liability, software liability should be
tied to standards and best practices, as
well as the damage and harm that result
from security flaws. The objective is not
to penalize companies who invest considerable resources in software security
but find their code vulnerable to a new
exploit that nobody had anticipated.
Rather, it is to bring all software up to
a higher level of security by punishing
those who are negligent in this domain,
for example, by putting out code that
fails to check inputs. Standards and
best practices for secure coding have ad-
vanced considerably, and readers inter-
ested in learning more might start with
CERT’s Secure Coding Web portal.
The argument is often made that
software liability will inhibit innovation,
but we should inhibit the introduction
of faulty software. Moreover, assigning
liability will likely stimulate innovation
relating to secure software development. Another argument against software liability is that it will raise the price
of software. While this may be true, it
should lower the costs we all pay from
cyber-attacks that exploit software vulnerabilities, costs that have been rising
over the years and fall on the backs of
users as well as software companies.
Bug bounties emerged under current
market forces and are likely here to
stay. I oppose a program that would
attempt to have the U.S. government
corner and fund this market, in part
because it would reduce the incentive
for software companies to produce
more secure code and could make the
A better strategy is one that increases the incentives for the development
of secure software but decreases those
for putting out sloppy code. One way of
achieving this is by holding companies
responsible for all the code they sell
and service, including both proprietary
and open source. Under this strategy,
companies could be sued for damages
caused by cyber-attacks that exploited
flaws in their code, and penalties would
be inflicted according to whether the
code was developed under standards
and best practices for secure coding.
Developing a suitable
will be a challenge,
as the system must
address the concerns
of both software
developers and users.