<?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: Static Application Vulnerability Testing: Binary Scanning vs Source Code Scanning</title>
	<atom:link href="http://www.webadminblog.com/index.php/2010/07/22/static-application-vulnerability-testing-binary-scanning-vs-source-code-scanning/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.webadminblog.com/index.php/2010/07/22/static-application-vulnerability-testing-binary-scanning-vs-source-code-scanning/</link>
	<description>Real Web Admins.  Real World Experience.</description>
	<lastBuildDate>Mon, 06 Feb 2012 14:28:57 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Tony Czarnik</title>
		<link>http://www.webadminblog.com/index.php/2010/07/22/static-application-vulnerability-testing-binary-scanning-vs-source-code-scanning/comment-page-1/#comment-694</link>
		<dc:creator>Tony Czarnik</dc:creator>
		<pubDate>Thu, 13 Jan 2011 12:42:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.webadminblog.com/?p=474#comment-694</guid>
		<description>I&#039;ve worked for a SSCA (source) vendor and now my security firm partners with a SBCA (binary) vendor. A partial list of advantages using binary analysis include: testing the same code the attacker sees, testing the entire software supply chain and greater accuracy (less FPs and less FNs). If you are a developer that is knowledgeable about appsec, are doing agile and have an SSCA plug-in to your IDE, cool, but most developers are security novices at best and although you may not care about your company&#039;s COTS vendor security, your management cares alot  since PCI, HIPAA etc do and when your PII gets breached bad things happen and all employees feel the pain.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve worked for a SSCA (source) vendor and now my security firm partners with a SBCA (binary) vendor. A partial list of advantages using binary analysis include: testing the same code the attacker sees, testing the entire software supply chain and greater accuracy (less FPs and less FNs). If you are a developer that is knowledgeable about appsec, are doing agile and have an SSCA plug-in to your IDE, cool, but most developers are security novices at best and although you may not care about your company&#8217;s COTS vendor security, your management cares alot  since PCI, HIPAA etc do and when your PII gets breached bad things happen and all employees feel the pain.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Sapp</title>
		<link>http://www.webadminblog.com/index.php/2010/07/22/static-application-vulnerability-testing-binary-scanning-vs-source-code-scanning/comment-page-1/#comment-655</link>
		<dc:creator>John Sapp</dc:creator>
		<pubDate>Mon, 23 Aug 2010 03:12:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.webadminblog.com/?p=474#comment-655</guid>
		<description>My thought is that static binary analysis is better utilized during the QA stage as this would allow feature/functionality testing and security testing to be performed concurrently with no impact to schedule.  Additionally, the independent validation is a great way to ensure that developers are not bypassing security requirements.

When time is a factor, security takes a backseat to feature/functionality so developers will end up ditching anything that gets in the way, which means those expensive tools will not get used and the Total Cost of Ownership and value proposition are washed away.

Next, I would suggest reading the following documents for some additional perspective on static binary:

&quot;What You See Is Not What You eXecute&quot; http://www.cs.wisc.edu/wpis/papers/wysinwyx05.pdf

&quot;Some Bad News and Some Good News&quot; http://msdn.microsoft.com/en-us/library/ms972826</description>
		<content:encoded><![CDATA[<p>My thought is that static binary analysis is better utilized during the QA stage as this would allow feature/functionality testing and security testing to be performed concurrently with no impact to schedule.  Additionally, the independent validation is a great way to ensure that developers are not bypassing security requirements.</p>
<p>When time is a factor, security takes a backseat to feature/functionality so developers will end up ditching anything that gets in the way, which means those expensive tools will not get used and the Total Cost of Ownership and value proposition are washed away.</p>
<p>Next, I would suggest reading the following documents for some additional perspective on static binary:</p>
<p>&#8220;What You See Is Not What You eXecute&#8221; <a href="http://www.cs.wisc.edu/wpis/papers/wysinwyx05.pdf" rel="nofollow">http://www.cs.wisc.edu/wpis/papers/wysinwyx05.pdf</a></p>
<p>&#8220;Some Bad News and Some Good News&#8221; <a href="http://msdn.microsoft.com/en-us/library/ms972826" rel="nofollow">http://msdn.microsoft.com/en-us/library/ms972826</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Josh</title>
		<link>http://www.webadminblog.com/index.php/2010/07/22/static-application-vulnerability-testing-binary-scanning-vs-source-code-scanning/comment-page-1/#comment-653</link>
		<dc:creator>Josh</dc:creator>
		<pubDate>Thu, 22 Jul 2010 21:30:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.webadminblog.com/?p=474#comment-653</guid>
		<description>After talking with one of my developers this afternoon about this, a couple of corrections.  First, it sounds like at least in the Java world that this service is likely decompiling binaries into Java byte code and not pure assembly though the sales guy did say &quot;assembly&quot;.  Second, I&#039;ll withdraw my cynicism of the capability for the service to determine the line number of a vulnerability from said assembly (or byte) code.  It turns out that by adding a debug flag you are able to get down to a line number from the disassembled code.  So if you&#039;re using debug for production code, this would likely work as advertised.  I guess we&#039;ll call that category a draw.</description>
		<content:encoded><![CDATA[<p>After talking with one of my developers this afternoon about this, a couple of corrections.  First, it sounds like at least in the Java world that this service is likely decompiling binaries into Java byte code and not pure assembly though the sales guy did say &#8220;assembly&#8221;.  Second, I&#8217;ll withdraw my cynicism of the capability for the service to determine the line number of a vulnerability from said assembly (or byte) code.  It turns out that by adding a debug flag you are able to get down to a line number from the disassembled code.  So if you&#8217;re using debug for production code, this would likely work as advertised.  I guess we&#8217;ll call that category a draw.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

