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

--- the software should work and be secure (co-requirements).  The user
community has been educated to accept CTL-ALT-DEL and wait as an acceptable
method of computing (and when things are really haywire - resintall the OS
and loose all your work).   We've got a long way to go for them to expect
software to also be secure, since they now accept that it doesn't work right
as SOP.

Mike Hines

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