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:[EMAIL PROTECTED] 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: [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. _______________________________________________
