Secure Coding mailing list archives
Economics of Software Vulnerabilities
From: gem at cigital.com (Gary McGraw)
Date: Tue, 13 Mar 2007 07:23:06 -0400
In my opinion, though fuzz testing is certainly a useful technique (we've used it in hardware verification for years), any certification based solely on fuzz testing for security would be ludicrous. Fuzz testing is not a silver bullet. The biggest stumbling block for software certification is variability in final environment. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com -----Original Message----- From: Gadi Evron [mailto:ge at linuxbox.org] Sent: Mon Mar 12 21:48:25 2007 To: Crispin Cowan Cc: fuzzing at whitestar.linuxbox.org; Ed Reed; sc-l at securecoding.org Subject: Re: [SC-L] Economics of Software Vulnerabilities On Mon, 12 Mar 2007, Crispin Cowan wrote:
Ed Reed wrote:For a long time I thought that software product liability would eventually be forced onto developers in response to their long-term failure to take responsibility for their shoddy code. I was mistaken. The pool of producers (i.e., the software industry) is probably too small for such blunt economic policy to work.I'm not sure about the size of the pool. I think it is more about the amount of leverage that can be put on software: * It is trivial for some guy in a basement to produce a popular piece of open source software, which ends up being used as a controlling piece of a nuclear reactor, jet airplane, or automobile, and when it fails, $millions or $billions of damages result. The software author has no where near the resources to pay the damage, or even the insurance premiums on the potential damage. * In contrast, with physical stuff it is usually the case that the ability to cause huge damage requires huge capital in the first place, such as building nuclear reactors, jet planes, and cars. With this kind of leverage, the software producers don't have the resources to take responsibility, and so strict liability applied to authors reduces to "don't produce software" unless, possibly, you work for a very large corporation with deep pockets. Even then, corporate bean counters would likely prevent you from writing any software because the potential liability is so large.It appears, now, that producers will not be regulated, but rather users and consumers. SOX, HIPAA, BASEL II, etc. are all about regulating already well-established business practices that just happen to be incorporating more software into their operations.Much like the gun industry. Powerful, deadly tools that, if used inappropriately, can cause huge damage.
Indeed, and I found your posts enlightening. Still, today an alternative presentsitself in the now more likely realm of software security certification and testing. It has become more easier and potentially regulated now that fuzzers have become: 1. Good enough. 2. Measurable. 3. Widely accessible. Gadi. _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ ---------------------------------------------------------------------------- This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ----------------------------------------------------------------------------
Current thread:
- Economics of Software Vulnerabilities Ed Reed (Mar 06)
- Economics of Software Vulnerabilities Crispin Cowan (Mar 12)
- Economics of Software Vulnerabilities Gadi Evron (Mar 12)
- <Possible follow-ups>
- Economics of Software Vulnerabilities Gary McGraw (Mar 13)
- Economics of Software Vulnerabilities Gadi Evron (Mar 13)
- Economics of Software Vulnerabilities Gary McGraw (Mar 13)
- Economics of Software Vulnerabilities Crispin Cowan (Mar 19)
- Economics of Software Vulnerabilities Ed Reed (Mar 19)
- Economics of Software Vulnerabilities Crispin Cowan (Mar 19)
- Economics of Software Vulnerabilities Steven M. Christey (Mar 19)
- Economics of Software Vulnerabilities Ed Reed (Mar 20)
- Economics of Software Vulnerabilities Arian J. Evans (Mar 21)
- Economics of Software Vulnerabilities Steven M. Christey (Mar 21)
- Economics of Software Vulnerabilities mudge (Mar 21)
- Economics of Software Vulnerabilities Crispin Cowan (Mar 19)
- Economics of Software Vulnerabilities Crispin Cowan (Mar 12)