Integration of some of the static techniques found in tools like fortify into compilers does make sense. However, not all of the kinds of things should be put in the compiler (how many coders do you know that use the -Wall??!). So one use case for some of the knowledge would be compiler enforcement. Note that compilers are notorious for computing and then throwing out many things statically. They are designed to get their transformation business done, not to do real analysis.
Still other things should be worked directly into the languages. C and C++ suck for security. And most importantly, rules tailored directly to the enterprise situation at hand require a platform like fortify. At cigital we have developed sets of custom rules for customers with great results. This cuts down false positives and makes it possible to enforce guidelines and standards that make sense for the business (think J2EE here). Bottom line...we need it all, and we need it now. gem P.S. Ken's course was co-designed by me and is based on my book. You might pick up a copy. company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com -----Original Message----- From: McGovern, James F (HTSC, IT) [mailto:[EMAIL PROTECTED] Sent: Thu Dec 21 10:47:50 2006 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. ************************************************************************* ---------------------------------------------------------------------------- This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ---------------------------------------------------------------------------- _______________________________________________ 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. _______________________________________________
