Once again though, using security-oriented constructs requires that the developers use them and use them correctly. Static code analysis tools (like Fortify) aren't after-the-fact, they should be inline during the process of development. If you can create a development process and environment of security you have won 90% of the war and the Klingons shall subside when the mighty static analysis ship sails into port. Now relying solely on a black box testing suite or a fuzzer, is just validating the code your attackers already know is weak. Don't get me wrong, I incorporate some fuzzing in our testing process, but this is only because its repeatable, automated, and it enables me to spend some time answering emails to interesting mailing lists. :) </2cents> JS
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Thursday, December 21, 2006 8:38 AM To: Gunnar Peterson Cc: Secure Mailing List Subject: Re: [SC-L] Compilers Gunnar, I think the problem space of secure coding will never be pervasively solved if it relies on the licensing of tools for every developer on the planet. Folks have been conditioned to not pay for developer level tools and now use Eclipse, etc. Putting it only in the hands of a few folks may be useful or it may be futile, only time will tell. In terms of your analogy of using try/catch blocks, I would say the following: First, languages within the last ten years require you to use them and they are not optional for the developer to skip in many situations. Second, compilers actually check try/catch blocks which says that compilers can and do play an important role which the community should leverage vs avoid. This does beg another question of should the community be helping the folks who design languages to build in security-oriented constructs that we can leverage instead of waiting for after-the-fact find-it utilities? -----Original Message----- From: Gunnar Peterson [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 10:55 AM To: McGovern, James F (HTSC, IT); Secure Mailing List Subject: Re: [SC-L] Compilers Sure it should be built into the language, and I assume it will be eventually. Heck it only took 30 or 40 years for people to force developers to use Try...Catch blocks. -gp On 12/21/06 9:30 AM, "McGovern, James F (HTSC, IT)" <[EMAIL PROTECTED]> wrote: 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. _______________________________________________
_______________________________________________ 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. _______________________________________________
