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