<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: CWE/SANS Top 25 Most Dangerous Programming Errors</title>
	<atom:link href="http://www.veracode.com/blog/2009/01/cwesans-top-25-most-dangerous-programming-errors/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.veracode.com/blog/2009/01/cwesans-top-25-most-dangerous-programming-errors/</link>
	<description>Application security testing, analysis, and metrics</description>
	<lastBuildDate>Tue, 15 May 2012 22:16:53 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Chris Wysopal</title>
		<link>http://www.veracode.com/blog/2009/01/cwesans-top-25-most-dangerous-programming-errors/comment-page-1/#comment-2523</link>
		<dc:creator>Chris Wysopal</dc:creator>
		<pubDate>Mon, 02 Feb 2009 18:15:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.veracode.com/blog/?p=607#comment-2523</guid>
		<description>@Tejeddine:

I agree with your approach. There is more to finding security vulnerabilities then just automated static and dynamic analysis. I mention them because these are approaches people are using today to find vulnerabilities cheaply and easily and are a great starting point yet usually not sufficient.

I wrote a book, &quot;The Art of Software Security Testing&quot;, which taught traditional QA testers and developers how to use the tools and techniques they already have at their disposal for finding non-security bugs and repurpose them for security bugs. I think test harnesses and unit testers fall into this category.

While I think this is a good approach I am not holding my breath.  Most organizations have not invested the time and resources to build up and train an internal security testing group or trained their QA people on security testing techniques. For them using automated tools can be a great start to tackling the problem of shipping software containing the CWE/SANS top 25 programming errors.  As an organization matures they can get better at more semi-automated and manual techniques.


-Chris</description>
		<content:encoded><![CDATA[<p>@Tejeddine:</p>
<p>I agree with your approach. There is more to finding security vulnerabilities then just automated static and dynamic analysis. I mention them because these are approaches people are using today to find vulnerabilities cheaply and easily and are a great starting point yet usually not sufficient.</p>
<p>I wrote a book, &#8220;The Art of Software Security Testing&#8221;, which taught traditional QA testers and developers how to use the tools and techniques they already have at their disposal for finding non-security bugs and repurpose them for security bugs. I think test harnesses and unit testers fall into this category.</p>
<p>While I think this is a good approach I am not holding my breath.  Most organizations have not invested the time and resources to build up and train an internal security testing group or trained their QA people on security testing techniques. For them using automated tools can be a great start to tackling the problem of shipping software containing the CWE/SANS top 25 programming errors.  As an organization matures they can get better at more semi-automated and manual techniques.</p>
<p>-Chris</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tejeddine Mouelhi</title>
		<link>http://www.veracode.com/blog/2009/01/cwesans-top-25-most-dangerous-programming-errors/comment-page-1/#comment-2504</link>
		<dc:creator>Tejeddine Mouelhi</dc:creator>
		<pubDate>Sat, 31 Jan 2009 10:37:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.veracode.com/blog/?p=607#comment-2504</guid>
		<description>I was looking forward to have an answer to my point. I will go with thinking that I  was absolutely right about what I wrote in my previous post and there was nothing you can argue about. Good for me!
I thought the point of writing this blog is to discuss interesting subjects with the security community and not only to advertize about your company.

Best regards,
Tejeddine Mouelhi,</description>
		<content:encoded><![CDATA[<p>I was looking forward to have an answer to my point. I will go with thinking that I  was absolutely right about what I wrote in my previous post and there was nothing you can argue about. Good for me!<br />
I thought the point of writing this blog is to discuss interesting subjects with the security community and not only to advertize about your company.</p>
<p>Best regards,<br />
Tejeddine Mouelhi,</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tejeddine Mouelhi</title>
		<link>http://www.veracode.com/blog/2009/01/cwesans-top-25-most-dangerous-programming-errors/comment-page-1/#comment-2449</link>
		<dc:creator>Tejeddine Mouelhi</dc:creator>
		<pubDate>Mon, 19 Jan 2009 10:26:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.veracode.com/blog/?p=607#comment-2449</guid>
		<description>Hello,

It is interesting to see that you consider only two ways to perform security testing: automated tool, and manual penetration testing.
Why don&#039;t you consider semi-automated emerging tools like those based on JUnit, like for example JWebUnit, Selenium etc, which provide a good framework for writing security tests.

Automated tools are not efficient for detecting subtle flaws (i suggest reading this interesting study about the limitation of automated tool - http://portal.acm.org/citation.cfm?doid=1029911 ).

On the other hand, penetration testing can help detect flaws. But that really depends on the expertise of the tester, and when done manually it cannot be covering all parts of the code (consider large web apps), and will only reveal a small piece of existing flaws. I can see that this good enough for vendor, to say that they were able to find many flaws, but does that offer any guarantee of the absence of other flaws ?

A good trade-off between the two approaches, would be to use semi-automated tool, to manually write tests but helped by good framework.

I looking forward to read you opinion on this, as a security expert.

Kind regards,</description>
		<content:encoded><![CDATA[<p>Hello,</p>
<p>It is interesting to see that you consider only two ways to perform security testing: automated tool, and manual penetration testing.<br />
Why don&#8217;t you consider semi-automated emerging tools like those based on JUnit, like for example JWebUnit, Selenium etc, which provide a good framework for writing security tests.</p>
<p>Automated tools are not efficient for detecting subtle flaws (i suggest reading this interesting study about the limitation of automated tool &#8211; <a href="http://portal.acm.org/citation.cfm?doid=1029911" rel="nofollow">http://portal.acm.org/citation.cfm?doid=1029911</a> ).</p>
<p>On the other hand, penetration testing can help detect flaws. But that really depends on the expertise of the tester, and when done manually it cannot be covering all parts of the code (consider large web apps), and will only reveal a small piece of existing flaws. I can see that this good enough for vendor, to say that they were able to find many flaws, but does that offer any guarantee of the absence of other flaws ?</p>
<p>A good trade-off between the two approaches, would be to use semi-automated tool, to manually write tests but helped by good framework.</p>
<p>I looking forward to read you opinion on this, as a security expert.</p>
<p>Kind regards,</p>
]]></content:encoded>
	</item>
</channel>
</rss>

