mailing list archives
Re: Creating a publicly maintained vulnerability database
From: full-disclosure () lists netsys com (Pascal Meunier)
Date: Fri, 19 Jul 2002 16:17:36 -0500
We have just overhauled our cooperative vulnerability database
(fixing many bugs), adding an exploit section with IDS rules, and
modifying it to allow the use a moderation process instead of a
3-reviewer process. What is interesting about it is that anybody can
improve a record by working on a copy and submitting it so that it
will supersede the original. As a basis it imports CVE information
daily but it is not bound by it. One drawback to it is that
operational policies have not been clearly defined; another is that
there currently isn't enough information in it.
Please have a look; accounts are and will remain free. We will keep
working on it. Feel free to make suggestions too, for features or
operational policies. At this point, I would very much like to know
what else it would take for the community to get involved in it, and
I am willing to share the stewardship with interested individuals and
companies. It is publicly accessible at:
Assistant Research Scientist, CERIAS
At 4:42 PM -0400 7/19/02, Steven M. Christey wrote:
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"
Pascal Meunier, Ph.D., M.Sc.
Assistant Research Scientist,