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 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 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: