On Thu, 7 Jun 2007, Michael Silk wrote:

> and that's the problem. the accountability for insecure coding should
> reside with the developers. it's their fault [mostly].

The customers have most of the power, but the security community has
collectively failed to educate customers on how to ask for more secure
software.  There are pockets of success, but a whole lot more could be

>From a developer-focused perspective, we need to deal with (1)  ensuring
that developers KNOW how to produce secure code (or interpret tool
results), but then (2) actually produce the secure code within given
deadlines.  I know that (2) is a common topic on this list, but deadlines
won't change until customers force the issue, which currently requires
weaning them from featuritis, which has such low prospects of success that
it's starting to depress me, so I'll stop and we've talked about this
before anyway.

> > It would seem to be that tools that developers plug into their IDE
> > should be free since the value proposition should reside elsewhere.

I personally love this sentiment, but that's not how the current market is
working, and I'm not sure how it would shift to that point.  There might
be lessons from the anti-virus community's long history (nowadays mostly
covering the same stuff usin a subscription model, but they still compete
on speed more than quality of information to the end user).  I don't know
what the vuln scanning tool indusry is up to these days (Nessus, Retina,
etc.) but I do know that management-friendly reporting was the bane of
that technology's existence for years.

- Steve
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.

Reply via email to