Except when they're hardware bugs. :) I think the differentiation is also meaningful in this regard: I can specify software that does non-secure things. I can implement that software 100% correctly. Ipso facto - no software bugs. But the fact remains that the software doesn't validate input because I didn't specify it to validate input, or it doesn't encrypt passwords because I didn't specify it to do so. I built to spec; it just happened to be a stupid spec. So the spec is flawed - but the implemented software conforms to that stupid spec 100%, so by definition it not flawed. It is, however, non-secure.
-- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_ka...@bah.com -----Original Message----- From: sc-l-boun...@securecoding.org on behalf of Benjamin Tomhave Sent: Thu 19-Mar-09 19:28 To: Secure Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) Why are we differentiating between "software" and "security" bugs? It seems to me that all bugs are software bugs, ...
_______________________________________________ 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. _______________________________________________
