mailing list archives
Re: On product vulnerability history and vulnerability complexity
From: "Forrest J. Cavalier III" <mibsoft () mibsoftware com>
Date: Mon, 03 Apr 2006 13:19:46 -0400
Crispin Cowan wrote:
Steven M. Christey wrote:
One difficulty is that we can't really know a product's full audit
history. If a researcher looks at a piece of software and finds
nothing of interest, that doesn't get reported. (Sardonix, we hardly
Agreed. Sardonix was clearly not fun enough to engage the community, but
we still need some way to record "I audited this code and found nothing
Everyone could publish digital signatures of all the source code they run using
one key, and digital signatures (with a different key) of all the source code
No need for a central repository of signatures. Just cross-link the web pages
and let the web and google-ish engines figure out the valuation/reputation of
someone's trusted key.
Reputation will keep people honest, or at least sort out the bad from the good.
Automatic reputation might be possible if you keep track of vulnerabilities
reported and ding the reputation of keys that signed the buggy code.
Fault injection might be a useful check too, but you have to be careful you
aren't training people to run diff cleverly against Open Source code from
If you require that the audit includes creating test cases/test frameworks, you
can do automated code coverage tests as a crude measure of audit quality. (You
can't produce very high coverage test cases without code audits.) Some people
will want to pay for test cases, which auditors can distribute only for a fee.
Once you have enough reputation, publishing keys and signatures alone to
subscribers might be a viable business model, especially when you distribute
keys and signatures specifically for each customer, so they don't transfer, and
you get recurring revenue stream for the code quality (and license
Just a half-baked idea. Does selling software quality assurance make sense?