lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 03 Apr 2006 13:19:46 -0400
From: "Forrest J. Cavalier III" <mibsoft@...software.com>
To: crispin@...ell.com
Cc: bugtraq@...urityfocus.com
Subject: Re: On product vulnerability history and vulnerability complexity


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
>>knew ye.)
>>  
> 
> 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
> wrong."

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 
they audited.

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 
different sources.

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 
assurance/insurance.)

Just a half-baked idea.  Does selling software quality assurance make sense?



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ