> 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 [EMAIL PROTECTED] _______________________________________________ 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. _______________________________________________
