Secure Coding mailing list archives

Compilers


From: atemin at mitre.org (Temin, Aaron L.)
Date: Thu, 21 Dec 2006 13:38:28 -0500

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/20061221/6cf1a382/attachment.html 


Current thread: