<?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: Software Security Labels: Should we throw in the towel?</title>
	<atom:link href="http://spiresecurity.com/?feed=rss2&#038;p=525" rel="self" type="application/rss+xml" />
	<link>http://spiresecurity.com/?p=525</link>
	<description>Risk and Cybersecurity Analysis</description>
	<lastBuildDate>Wed, 21 Aug 2013 23:28:51 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Steve Christey</title>
		<link>http://spiresecurity.com/?p=525&#038;cpage=1#comment-809</link>
		<dc:creator>Steve Christey</dc:creator>
		<pubDate>Thu, 27 Oct 2005 08:33:44 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=525#comment-809</guid>
		<description><![CDATA[I feel your pain regarding solid metrics for measuring software vulnerability.  The bias in vulnerability research can be unintentional as well.  There are approximately 300 different flavors of vulnerabilities by my count, yet most researchers only focus on 10 or 20.  Every researcher has their own preference or skill area.  The public record of vulnerabilities is nowhere near reliable, but it&#039;s the best we have for now.  The best clues are how complex the discovered vulnerabilities are (you rarely see a 100% obvious buffer overflow in a major software package these days - most overflows involve multiple bugs, complex attack scenarios, or previously unexplored functional areas such as file formats).

The research community needs to establish reasonably formal analysis methods that are repeatable and comprehensive, then deploy those methods on multiple products, and publish their results.  Only then can you possibly compare the security of products.  At least it would be a start.

Steve Christey
CVE Editor

]]></description>
		<content:encoded><![CDATA[<p>I feel your pain regarding solid metrics for measuring software vulnerability.  The bias in vulnerability research can be unintentional as well.  There are approximately 300 different flavors of vulnerabilities by my count, yet most researchers only focus on 10 or 20.  Every researcher has their own preference or skill area.  The public record of vulnerabilities is nowhere near reliable, but it&#8217;s the best we have for now.  The best clues are how complex the discovered vulnerabilities are (you rarely see a 100% obvious buffer overflow in a major software package these days &#8211; most overflows involve multiple bugs, complex attack scenarios, or previously unexplored functional areas such as file formats).</p>
<p>The research community needs to establish reasonably formal analysis methods that are repeatable and comprehensive, then deploy those methods on multiple products, and publish their results.  Only then can you possibly compare the security of products.  At least it would be a start.</p>
<p>Steve Christey<br />
CVE Editor</p>
]]></content:encoded>
	</item>
</channel>
</rss>
