> If it isn't in the RFP then it's not a requirement, regardless of what the customer implicitly expected.
DHS has a draft guide to raise the awareness of those in the acquisition process about the need for software security and how to include the RFP language. https://buildsecurityin.us-cert.gov/daisy/bsi/resources/dhs/908.html The comment period is still open if you have suggestions on how to improve the guide. Stan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Mason Jr Sent: Saturday, October 27, 2007 1:12 PM To: Secure Coding Subject: Re: [SC-L] Software security video podcast 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. _______________________________________________
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. _______________________________________________
