Perspectives on Code Scanning

[James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))]

While developers create the problems, I don't believe it is their fault. If you were to analyze the SDLC of a Fortune 
enterprise or even software vendor they all have a common problem in that the reward systems for developers are all 
about features and time to market where security is always a last minute thought and prioritized last. Developers in an 
outsourcing context would probably get it handed to them if they were to spend additional time writing secure code if 
the client didn't ask for it. 

I believe this is a management problem and that management needs tools to help them understand how big of a problem 
they create for others. Developers should be cut a break and be given tools to do their jobs properly and there 
shouldn't be expense incurred to do so.

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org]On Behalf Of Michael Silk
Sent: Wednesday, June 06, 2007 7:00 PM
To: McGovern, James F (HTSC, IT)
Cc: Secure Coding
Subject: Re: [SC-L] Perspectives on Code Scanning


On 6/7/07, McGovern, James F (HTSC, IT) <James.McGovern at thehartford.com> wrote:
> I really hope that this email doesn't generate a ton of offline emails and hope that folks will
> talk publicly. It has been my latest thinking that the value of tools in this space are not really
> targeted at developers but should be targeted at executives who care about overall quality
> and security folks who care about risk. While developers are the ones to remediate, the
> accountability for secure coding resides elsewhere.

and that's the problem. the accountability for insecure coding should
reside with the developers. it's their fault [mostly].



> It would seem to be that tools that developers plug into their IDE should be free since the
> value proposition should reside elsewhere. Many of these tools provide "audit" functionality
> and allow enterprises to gain a view into their portfolio that they previously had zero clue
> about and this is where the value should reside.
>
> If there is even an iota of agreement, wouldn't it be in the best interest of folks here to get
> vendors to ignore developer specific licensing and instead focus on enterprise concerns?
>
>
> *************************************************************************
> 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 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.
> _______________________________________________


-- 
mike
68 65 6c 6c 6f 20 74 6f 20 79 6f 75 2c
20 68 65 78 20 64 65 63 6f 64 65 72 2e
_______________________________________________
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.
_______________________________________________