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.


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.

Reply via email to