mailing list archives
Creating a publicly maintained vulnerability database
From: full-disclosure () lists netsys com (Steven M. Christey)
Date: Fri, 19 Jul 2002 16:42:13 -0400 (EDT)
Jay D. Dyson said:
Look, I have nothing against someone trying to make a buck. That
is the cornerstone of the capitalist system. What burns my biscuits is
that the monolithic security companies are not making this money off their
own efforts, but by leeching off the egalitarian contributions of those
who possess a skill set the businesses are not willing to pay for.
With organizations like CERT/CC projecting 4,000+ vulnerabilities this
year alone, the amount of research and quality-checking that is
required to maintain a good vulnerability database is growing
prohibitive, even if most of the vulnerabilities were discovered and
announced by many people in the community.
As suggested by others, a publicly maintained vulnerability database
is a possibility, but it would need a large-scale community effort to
populate and maintain, and there would be issues of quality control.
Maintaining a vulnerability database also requires some different
skills than vulnerability research or system administration:
- a stronger emphasis on writing for multiple audiences (technical
details and high-level summaries)
- identifying different technical areas and finding/keeping skilled
people to cover them (e.g. crypto, Linux kernels, CGI, programming
- defining what will be in the database (this was an issue in the
early days of CVE because everyone has different definitions of
"vulnerability," and it's still an issue to some degree)
- ironing out details like workaround and fix information (even
determining whether the vendor has fixed the problem can be a
challenge; researcher-suggested patches can be broken; some
workarounds aren't feasible)
- trying to distinguish between closely related vulnerabilities (is
there one vulnerability or two? Did vendor X and Y really fix the
same issue? Did vendor W's fix really address researcher Z's report
from two months earlier?)
- deciding on a severity metric (IMHO, high/medium/low must die)
- getting consistent terminology (your XSS is not my XSS (or CSS)!
Same with remote/local, directory traversal, etc.)
- ensuring accuracy of information (which is sometimes problematic
even in "full disclosure" instances)
- actually validating whether the reported vulnerabilities are real or
not (a daunting challenge for anything but the most commonly
deployed products and configurations)
- then designing, implementing, and maintaining the databases and the
server(s) that support it.
Chris Wysopal said:
Even so a completely non-corporate and free vuln database would be
something good for the community.
NIST's ICAT database (http://icat.nist.gov) is freely available for
download. It is built on top of the CVE list. Unfortunately, that
means that some of CVE's challenges pose difficulties for ICAT,
e.g. with respect to CVE's delays in making candidate numbers
available after an issue has been disclosed. (BTW, we're focusing on
improving our timeliness, which should improve noticeably in the
If everyone is serious about building and maintaining their own open
vulnerability database, then consider using the following resources:
1) Working group reports from the 2nd vulnerability database workshop
at Purdue CERIAS, January 1999, especially the appendices.
There is some good discussion regarding issues in creating "open"
or "federated" vulnerability databases.
(Google offers this file in text format, but the document structure
is lost a little. http://citeseer.nj.nec.com/meunier99final.html
may provide alternate formats)
2) Purdue CERIAS has done some followup work in trying to create a
public vulnerability database.
"Sharing Vulnerability Information using a Taxonomically-correct,
Web-based Cooperative Database"
- Creating a publicly maintained vulnerability database Steven M. Christey (Jul 19)