Sardonix Security Auditing Portal

[Crispin Cowan <crispin () wirex com>]

 Back in the summer of 1998, the Linux Security Audit Project 
http://lsap.org was founded as a mailing list.  Inspired by the 
spectacular work of OpenBSD, LSAP was intended to orchestrate the 
systematic security auditing of source code commonly found in Linux 
distributions.

Since then, LSAP has failed to really live up to its mission.  While the 
LSAP mailing list has become a very nice chat room for discussing 
security issues, not much software is actually audited any more.

We propose to address this under used potential by providing a real & 
effective web portal to facilitate & encourage source code auditing.  
This web site will facilitate and encourage source code auditing in the 
following ways:

   * Identify auditors: we don't care if auditors are anonymous, but
     they should be authentic.  I.e. you can go by a handle if you want
     to, but you should have a public key, so we know it's you.
   * Repository for audited code:  importantly, identifying who has
     audited the code, and what issues were found.
   * Todo's:  a list of unaudited code that could use some attention. 
     With source code, so would-be auditors don't have to go find it.
   * Score keeping:  this part is very important.  There's two kinds of
     scores to keep:
         * Auditor's score: each auditor is scored based on the volume
           of code they have audited, and the number of bugs
           SUBSEQUENTLY found in code that they declared clean.
         * Code's score: the trustworthiness of a piece of code is a
           function of the people who have audited the code.

The score keeping is really the most important part of the web site, 
with two key roles to play:

   * the karma whore effect: we conjecture that a web site that will
     mechanically compute a number of how l33t you are will attract
     people to audit code.  Consider how hard people will work just
     score karma points on Slashdot :-)
   * assuring code quality: scoring the code in terms of the number &
     quality of eyes that have read it will give code consumers a
     reasonably valid way to determine the level of trust they can put
     in that code.

We also will be encouraging responsible reporting. The audit submission 
form explicitly asks you if you have followed the RFP
http://www.wiretrip.net/rfp/policy.html and notified the package 
maintainer prior to publishing your findings.

What we need:  community feedback.

   * Generally:  what do folks think of the model?  What changes, if
     any, do people think it needs to make it work?
   * Specifically: the scoring functions are critical, as people will
     generally act to maximize figures of merit. This can get
     pathological, e.g. stock brokers churning the market to make
     commission.  What should the scoring functions look like for
     auditors? for programs?

The whole project is intended to leverage community skepticism of claims 
of security, and the community's joyful habit of criticizing the work of 
others, and so we call it Sardonix.  You can view the beginnings of the 
project here http://sardonix.org including subscribing to the Sardonix 
mailing list  http://mail.wirex.com/mailman/listinfo/sardonix First, we 
expect discussion/flaming :-) about the particular structure of the web 
site, followed by actually implementing the software behind the design 
the community decides it wants. And then we will get down to some auditing.

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

       The Olympic Games: A Century of Corruption and Graft
             The FIS: Crushing the soul of snowboarding