<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.11" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Badness-ometers are good.  Do you own one?</title>
	<link>http://www.cigital.com/justiceleague/2007/03/19/badness-ometers-are-good-do-you-own-one/</link>
	<description>The Cigital Software Security and Quality Blog</description>
	<pubDate>Mon, 13 Oct 2008 00:29:58 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.11</generator>

	<item>
		<title>by: gem</title>
		<link>http://www.cigital.com/justiceleague/2007/03/19/badness-ometers-are-good-do-you-own-one/#comment-28</link>
		<pubDate>Fri, 23 Mar 2007 17:55:44 +0000</pubDate>
		<guid>http://www.cigital.com/justiceleague/2007/03/19/badness-ometers-are-good-do-you-own-one/#comment-28</guid>
					<description>Interesting analogy.  I think I would liken the "gate review checklist" item...what might otherwise be termed an assurance activity with an associated quality gate...more to a regular and necessary maintenance activity than to something needed while you're driving.  However, if we limit ourselves to dashboard gauges, maybe code review is like the gas gauge?  I love the "idiot light" idea though...have to think about this some more.

With regard to whether is it better to use a badnessometer to look for really stupid mistakes than code review to look for really stupid mistakes, my intuition is that you will find more actionable results with code review than you will with security testing.  In the end you should do both, and trying to determine relative value for either seems a waste of time.

gem

BTW, on the pen testing front, my views are not at all the same as marcus's.  I was simply the interviewer.  You can find the complete podcast here http://www.cigital.com/silverbullet/show-003/.</description>
		<content:encoded><![CDATA[<p>Interesting analogy.  I think I would liken the &#8220;gate review checklist&#8221; item&#8230;what might otherwise be termed an assurance activity with an associated quality gate&#8230;more to a regular and necessary maintenance activity than to something needed while you&#8217;re driving.  However, if we limit ourselves to dashboard gauges, maybe code review is like the gas gauge?  I love the &#8220;idiot light&#8221; idea though&#8230;have to think about this some more.</p>
<p>With regard to whether is it better to use a badnessometer to look for really stupid mistakes than code review to look for really stupid mistakes, my intuition is that you will find more actionable results with code review than you will with security testing.  In the end you should do both, and trying to determine relative value for either seems a waste of time.</p>
<p>gem</p>
<p>BTW, on the pen testing front, my views are not at all the same as marcus&#8217;s.  I was simply the interviewer.  You can find the complete podcast here <a href="http://www.cigital.com/silverbullet/show-003/." rel="nofollow">http://www.cigital.com/silverbullet/show-003/.</a>
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Scott Wright</title>
		<link>http://www.cigital.com/justiceleague/2007/03/19/badness-ometers-are-good-do-you-own-one/#comment-25</link>
		<pubDate>Thu, 22 Mar 2007 01:19:51 +0000</pubDate>
		<guid>http://www.cigital.com/justiceleague/2007/03/19/badness-ometers-are-good-do-you-own-one/#comment-25</guid>
					<description>I am trying to think of an analogy.  I guess a Badness-ometer is, to software security metrics, what an oil pressure gauge is to a car dashboard.  Would that make a Gate Review Checklist item such as "Code-review-completed" something akin to an "Idiot-Light"?

I can't help but remember a McGraw/Ranum interview article in an IEEE publication about how, in Marcus Ranum's opinion, penetration testing is the stupidest idea he's ever heard of. Something about how ~"people who don't understand how their system works hire other people who don't understand how their system works, to simulute attacks by other people who don't understand how their system works..."~

It was a very amusing discussion, and almost convincing, if it weren't for real-world constraints on most development organizations, and the fact that no matter how good the development cycle security techniques are, there will always be holes, especially in larger systems with complex interconnected parts.

All this to say, I agree that the Badness-ometer is a much better thing than a "Code-review-completed" idiot light.</description>
		<content:encoded><![CDATA[<p>I am trying to think of an analogy.  I guess a Badness-ometer is, to software security metrics, what an oil pressure gauge is to a car dashboard.  Would that make a Gate Review Checklist item such as &#8220;Code-review-completed&#8221; something akin to an &#8220;Idiot-Light&#8221;?</p>
<p>I can&#8217;t help but remember a McGraw/Ranum interview article in an IEEE publication about how, in Marcus Ranum&#8217;s opinion, penetration testing is the stupidest idea he&#8217;s ever heard of. Something about how ~&#8221;people who don&#8217;t understand how their system works hire other people who don&#8217;t understand how their system works, to simulute attacks by other people who don&#8217;t understand how their system works&#8230;&#8221;~</p>
<p>It was a very amusing discussion, and almost convincing, if it weren&#8217;t for real-world constraints on most development organizations, and the fact that no matter how good the development cycle security techniques are, there will always be holes, especially in larger systems with complex interconnected parts.</p>
<p>All this to say, I agree that the Badness-ometer is a much better thing than a &#8220;Code-review-completed&#8221; idiot light.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
