Hi all,

Very good questions.  

I think a service like the one you describe would be useful mostly as a way of 
identifying the depth of the problem.  Simply wielding a tool as a consultant 
does nothing to train the guys creating bugs not to do so in the future...and 
so the market will correct that over time in an efficient way.  But the fact 
remains that many potential customers and users of static analysis tools have 
no idea how much of a mess they have.  An outsourcing approach could help with 
that.  They'll find out they need em.

I believe so strongly in the "do anything to get started" thing that I also 
endorse the use of (really amazingly silly) application security testing tools. 
 I call these badnessometers (see chapter 1 of "software security"...and ken's 
slides for that matter).  But knowing that your web code sucks is better than 
remaining completely clueless.

In the end, tool integration *into dev* is the key to success with static 
analysis.  Many of our customers are having huge enterprise-wide success 
because they are learning to use, feed, tune, and train dev about these tools.  
The best are recycling the things they learn about their code back into 
training (and into better rules to enforce).

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com.


 -----Original Message-----
From:   McGovern, James F (HTSC, IT) [mailto:[EMAIL PROTECTED]
Sent:   Tue Jan 02 12:23:50 2007
To:     sc-l@securecoding.org
Subject:        [SC-L] Building Security In vs Auditing

I read a recent press release in which a security vendor (names removed to both 
protect the innocent along with the fact that it doesn't matter for this 
discussion ) partnered with a prominent outsourcing firm. The press release was 
carefully worded but if you read into what wasn't said, it was in my opinion 
encouraging something that folks here tend to fight against. The outsourcing 
firm would use this tool in an auditing capacity for whatever client asked for 
another service but it would not become part of the general software 
development lifecycle for all projects. 

- It didn't mention any notion of all developers within the outsourcing firm 
having tools on their desktop to audit as they develop

- It didn't mention any notion of training all developers within the 
outsourcing firm on secure coding practices

- It did hint that one time periodic audits from a metrics perspective would be 
useful to clients that wanted this new service but didn't say how developers 
would be able to iterate on the code and reduce bugs. I would think that any 
offering that removes developers from the feedback loop while developing code 
and instead focusing on management-oriented (non-developer metrics) is 
generally a bad idea.

- It didn't mention even how many folks from their security practice were to 
receive training in secure coding practices

- Should we think of security as an extra "service" or something that should be 
incorporated into the SDLC in a consistent sustainable manner?


I am far offbase and drunk too much of Ken Van Wyk's Kool-aid from his 
wonderful training course by thinking that this type of initiative does more 
harm than good?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************


_______________________________________________
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.
_______________________________________________




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------

_______________________________________________
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