On Nov 29, 2007, at 6:35 PM, Leichter, Jerry wrote:
So he's not completely naive, though the history of security metrics andstandards - which tend to produce code that satisfies the standards without being any more secure - should certainly give on pause.One could, I suppose, give rebates based on actual field experience: Look at the number of security problems reported per year over a two- year period and give rebates to sellers who have low rates.
Right, so this is where I believe the entire idea would fall apart. I don't think we have adequate metrics today to measure products fairly. Basing the tax on field experience would also be problematic to measure well, although I could see this leading to development organizations getting some sort of actuarial score.
But the real problem with it, as I said, is metrics. Should it be based on (say) defect density per thousand lines of code as reported by (say) 3 independent static code analyzers? What about design weaknesses that go blissfully unnoticed by code scanners? (At least the field experience concept could begin to address these over time, perhaps.)
I do think that software developers who produce bad (security) code should be penalized, but at least for now, I still think the best way of doing this is market pressure. I don't think we're ready for more, on the whole, FWIW. But _consumers_ wield more power than they probably realize in most cases.
Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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. _______________________________________________
