J.M. Seitz wrote: >> Software security can be tricky when it comes to requirements, >> mostly because customers and consumers don't explicitly demand > security, rather they impicitly expect it. > > Wait a second here, don't customers also implicitly expect that the > software is going to run? I mean I haven't seen a requirements document > _ever_ that has said "The software must start.". They just implicitly > expect that its going to do that. > > Doesn't seem like a big surprise that most customers will _expect_ that > "Hey, I don't want this software pwnable after you're done with it." > > Not sure where the trickiness you are referring to comes from? > > JS > > ps. Didn't AW publish your book(s)? :) I would be real surprised > [turning on Tom Ptaceks snarky bit] if there's any mention of them.
If it isn't in the RFP then it's not a requirement, regardless of what the customer implicitly expected. The customers don't see a value to the added cost(s) of a secure system, unless they have a business requirement to adhere to such as PCI compliance, or HIPAA. If a requirement is important to the business it must be explicit, but this means the folks writing the RFP must have the understanding to make sure it is in the RFP, otherwise the you could end up with the better system (more secure) not being selected because it costs more. Now the company who bids the project in a more secure fashion will also get a tangible benefit from code review and other processes that make for a secure system, but they won't invest in this avenue until the RFP requires it. John _______________________________________________ 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. _______________________________________________
