Compilers

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

Gunnar, I think the problem space of secure coding will never be pervasively solved if it relies on the licensing of 
tools for every developer on the planet. Folks have been conditioned to not pay for developer level tools and now use 
Eclipse, etc. Putting it only in the hands of a few folks may be useful or it may be futile, only time will tell.
 
In terms of your analogy of using try/catch blocks, I would say the following: First, languages within the last ten 
years require you to use them and they are not optional for the developer to skip in many situations. Second, compilers 
actually check try/catch blocks which says that compilers can and do play an important role which the community should 
leverage vs avoid.
 
This does beg another question of should the community be helping the folks who design languages to build in 
security-oriented constructs that we can leverage instead of waiting for after-the-fact find-it utilities?
 
 

-----Original Message-----
From: Gunnar Peterson [mailto:gunnar at arctecgroup.net]
Sent: Thursday, December 21, 2006 10:55 AM
To: McGovern, James F (HTSC, IT); Secure Mailing List
Subject: Re: [SC-L] Compilers


Sure it should be built into the language, and I assume it will be eventually. Heck it only took 30 or 40 years for 
people to force developers to use Try...Catch blocks. 

-gp


On 12/21/06 9:30 AM, "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com> wrote:



I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have 
been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the 
compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what 
large vendors ignore, how far off base in my thinking am I?


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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061221/8df67565/attachment.html