Martin Gilje Jaatun wrote: > 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".
The problem (certainly as I see it) is that the customer is likely to say "Make it secure" without really understanding what that means. Secure against what exactly? Or you'll get a list of security features that the customer wants, but as we all know security features != secure product. Instead we've taken a combined approach of including customer requirements and adding specific requirements of our own focusing a good Secure development practices. > If we can "brainwash" the coming generations of programmers into > accepting Karen's definition of "quality code", we might finally be > getting somewhere. And that's the trick we've been attempting here. Secure software is nothing more than really good quality code. We already use coding guidelines and have a strong(ish) process of code reviews. So we have augmented our coding and review guidelines to include secure coding aspect such as input/output validation, good memory management etc. That said there is still a lot of scope for improvement in the rest of the software development process (testing and design in particular). CJC
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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. _______________________________________________
