Secure Coding mailing list archives

Compilers


From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Tue, 2 Jan 2007 10:21:08 -0500

I think my perspective is not just about overlap in terms of an abstract syntax tree but more in terms of usability. 
Security warnings should appear inline with other types of warnings from a developers perspective. When the information 
is presented separately, it will be an opportunity to ignore. It is harder to ignore compiler output.
 
Likewise, one of the lifecycle oriented things I have seen in several shops is that source code gets moved through 
environments and gets recompiled. So if I check in code to the integration environment, the build "tool" will extract 
and compile. Likewise, when code gets promoted to say QA environment, the code is extracted again and recompiled. This 
allows for build tools that emit metrics and track warnings in a centralized place to take advantage of security 
considerations as well.
 
Of course, some shops when they promote code move binaries which invalidates the above.

-----Original Message-----
From: Temin, Aaron L. [mailto:atemin at mitre.org]
Sent: Thursday, December 21, 2006 1:38 PM
To: McGovern, James F (HTSC, IT); Secure Coding
Subject: RE: [SC-L] Compilers


It would be worth knowing more about the basis you use for drawing the conclusion, but if it's just the overlap between 
compilers and static analyzers represented by the abstract syntax tree, I don't think that's enough to warrant building 
one into the other (it might argue for having a shared parser, but I don't think parsers are hard enough to build to 
make that worthwhile).  I would also suggest that looking for security weaknesses fits more into the unit testing part 
of development rather than the compiling part.  As for "standalone," I think Jtest is built as an Eclipse plug-in; I 
don't know if you'd consider that standalone or not, but at least the developer doens't have to start up another shell 
to run it.
 
Also, depending on the customer's organization, it might not be the developer who is running the security static 
analysis.  I was talking with an organization that was thinking of having the security group run the static analysis, 
as part of the acceptance phase of an iteration.
 
- Aaron


  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of McGovern, James F (HTSC, 
IT)
Sent: Thursday, December 21, 2006 10:31 AM
To: Secure Coding
Subject: [SC-L] Compilers


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070102/82c91a16/attachment.html 


Current thread: