Karen, Matt & all, Goertzel, Karen [USA] wrote: > I'm more devious. I think what needs to happen is that we need to redefine > what we mean by "functionally correct" or "quality" code. If determination of > functional correctness were extended from "must operate as specified under > expected conditions" to "must operate as specified under all conditions", > functional correctness would necessarily require security, safety, fault > tolerance, and all those other good things that make software dependable > instead of just correct. > I couldn't agree more!
However, I have had several discussions with a colleague who is fairly well known in the"Software Process Improvement Mafia" on the topic of how to ensure that security requirements are considered for _all_ kinds of code, not just "security software". Particularily in the context of agile development techniques, security keeps getting the short end of the stick, losing every time to "working features". His stance on this is that "if security were important to the customer, the customer would provide and prioritize security requirements". To me, this is a bit like saying "If the customer doesn't explicitly state that the software should be Y2k-proof, he/she is not really bothered about it". If we can "brainwash" the coming generations of programmers into accepting Karen's definition of "quality code", we might finally be getting somewhere. -Martin _______________________________________________ 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. _______________________________________________
