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@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.
_______________________________________________
