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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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.
***********************************************************************
**
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@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.
_______________________________________________
