I am not sure I agree that this is any more achievable than claiming a bank building should allow all valid customers in, but keep out all thieves. While we can and should make great strides, we will always have some exposure because we have to let some things through. The only way we can have perfectly secure code is to not allow someone to use it. The same is true of bug free code, but that is another argument. :)
Isn't this kind of like wanting the "evil bit" to be set in all malicious packets? Great idea, but not achievable.
-- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Benjamin Tomhave <list-s...@secureconsulting.net>:
we are now trapped in a box of our own making that has us squabbling over academic minutiae like how to teach secure coding when we should not have to consider this topic at all - the code itself should be inherently secure.
_______________________________________________ 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. _______________________________________________
