Secure Coding mailing list archives
Software security video podcast
From: wisseman_stan at bah.com (Wisseman, Stan [USA])
Date: Mon, 29 Oct 2007 10:35:17 -0400
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: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] 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 demandsecurity, 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 at 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. _______________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4405 bytes Desc: not available Url : http://krvw.com/pipermail/sc-l/attachments/20071029/3374da7c/attachment.bin
Current thread:
- Software security video podcast Gary McGraw (Oct 18)
- Software security video podcast J.M. Seitz (Oct 18)
- Software security video podcast John Mason Jr (Oct 27)
- Software security video podcast Wisseman, Stan [USA] (Oct 29)
- Software security video podcast Shea, Brian A (Oct 29)
- Software security video podcast John Mason Jr (Oct 27)
- Software security video podcast J.M. Seitz (Oct 18)