Perspectives on Code Scanning

[Brian.A.Shea at bankofamerica.com (Shea, Brian A)]

" And answering that correctly requires input from the customer.  Which
we (TINW) won't have until customers recognize a need for security and
get enough clue to know what they want to be secure against."

I can't exactly agree with this as there is a distinction (or should be
IMO) between security features and security of the code.

If you are asserting that the customer must tell you how many security
features to implement based on their requirements. I'll agree 100%.
Stuff like, "I don't need 3 types of military grade encryption added,
I'm just doing recipe sorting."  That kind of stuff.

However if you are waiting around for the customer to request software
that isn't subject to buffer overflows or can't be hijacked by input
validation I think you are missing the point.  That level of security
comes out of the quality of the dev team, process, and company producing
the software, not out of customer requirements.  Customer expect this
level of security implicitly just like they expect their toasters won't
burst into flames every time they try to toast a bagel.  They have
learned to accept less by the craptastic quality of code from many
vendors for many years, but would happily revert to the initial
expectation of "I just want it to work and not provide additional risk
to my organization".

It remains (weakly) arguable that IF the customer really wanted secure
software they'd have stronger legal agreements with suppliers that allow
recourse and compensation for failed security, but that brings in yet
another of the often technically clueless, Lawyers.

I do believe that the focal point of getting change from where we stand
now is at the feet of the customer, because it starts out as an economic
problem first.  If you pay more to get secure code or pay to buy weak
security but fast to market code, then you somewhat get what you paid
for.  Vendors will produce the lowest quality for the highest price if
the market lets them.

PS - speaking of lawyers... :)  The views expressed here are my own, not
those of my company ... etc etc.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of der Mouse
Sent: Thursday, June 07, 2007 8:07 AM
To: SC-L at securecoding.org
Subject: Re: [SC-L] Perspectives on Code Scanning

> --- the software should work and be secure (co-requirements).

And already we have trouble, because this immediately raises not only
the question "what does `work' mean?" but also "secure against what?".

And answering that correctly requires input from the customer.  Which
we (TINW) won't have until customers recognize a need for security and
get enough clue to know what they want to be secure against.

And we all know how likely customers are to have clue (of just about
any sort).

(Actually, there are markets where the customer usually is clued.
Oddly enough, they also tend to be markets wherein software isn't
security Swiss cheese. :-)

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               mouse at rodents.montreal.qc.ca
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
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.
_______________________________________________