<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.5450.4" name=GENERATOR></HEAD>
<BODY
style="WORD-WRAP: break-word; khtml-nbsp-mode: space; khtml-line-break: after-white-space">
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=128241415-02012007>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=128241415-02012007></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=128241415-02012007>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=128241415-02012007></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=128241415-02012007>Of
course, some shops when they promote code move binaries which invalidates the
above.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Temin, Aaron L.
[mailto:atemin@mitre.org]<BR><B>Sent:</B> Thursday, December 21, 2006 1:38
PM<BR><B>To:</B> McGovern, James F (HTSC, IT); Secure
Coding<BR><B>Subject:</B> RE: [SC-L] Compilers<BR><BR></FONT></DIV>
<DIV dir=ltr align=left><SPAN class=164463018-21122006><FONT color=#0000ff>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=164463018-21122006><FONT
color=#0000ff></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=164463018-21122006><FONT
color=#0000ff>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=164463018-21122006><FONT
color=#0000ff></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=164463018-21122006><FONT color=#0000ff>-
Aaron</FONT></SPAN></DIV><BR>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> sc-l-bounces@securecoding.org
[mailto:sc-l-bounces@securecoding.org] <B>On Behalf Of </B>McGovern, James F
(HTSC, IT)<BR><B>Sent:</B> Thursday, December 21, 2006 10:31
AM<BR><B>To:</B> Secure Coding<BR><B>Subject:</B> [SC-L]
Compilers<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><SPAN class=682132815-21122006><FONT face=Arial color=#0000ff size=2>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?</FONT></SPAN></DIV><FONT
size=3><BR><BR>*************************************************************************<BR>This
communication, including attachments, is<BR>for the exclusive use of
addressee and may contain proprietary,<BR>confidential and/or privileged
information. If you are not the intended<BR>recipient, any use, copying,
disclosure, dissemination or distribution is<BR>strictly prohibited. If you
are not the intended recipient, please notify<BR>the sender immediately by
return e-mail, delete this communication and<BR>destroy all
copies.<BR>*************************************************************************<BR></BLOCKQUOTE></BLOCKQUOTE></FONT></BODY></HTML>