Re: [PEN-TEST] Common Vulverabilities and Exposures (CVE)

["Steven M. Christey" <coley () LINUS MITRE ORG>]

A common question we receive regarding CVE is why it doesn't contain
typical vulnerability database information such as fixes, risk level,
affected OS, etc.  Its simplicity is by design.

Al Huger's comments touched on one of the reasons why CVE is so
"sparse" in terms of the information it provides.  If CVE is to be
accepted as a standard, then it needs to minimize overlap with other
vulnerability databases.  Otherwise, if CVE competes with such
databases, then it minimizes the vendor's incentive to use it.  Note
that we already rely on several sources, including SecurityFocus, to
provide the information that we use to populate CVE.  See
http://cve.mitre.org/cve/datasources.html for more details.

The primary intention of CVE is to provide a common name for use by
all vulnerability-related databases, products, services, etc., to
support comparison and information sharing.  The description and
references are useful in ensuring that you have obtained the correct
name for whatever vulnerability you have in mind.  Additional
information isn't necessary for the task of finding the CVE name for
something.  On occasion, we've considered adding some other fields,
but we've consistently decided against it.  That's why we try to
describe CVE as a dictionary instead of a database.

It wasn't quite expected that some people would consider using it to
seed their own databases.  However, it can still require significant
effort to "upgrade" to a real database.  A full-fledged vulnerability
database requires a lot of resources to create and maintain.  The
amount of work that goes into writing a good description is largely
unseen by the public; a lot of analysis typically goes into
understanding the problem well enough to describe it.  Even CVE, as
simple as it may appear, is labor-intensive.

So, commercial databases - or a "free" database, if one is ever
created and consistently supported long enough to be useful - may be a
more cost-effective option than trying to build a database from
scratch, or extending an existing one.  Due to the number of databases
available, many of them with a commercial use, I do not expect that
CVE will ever be extended to fulfill some people's need/desire for a
complete vulnerability database.  This could undermine the primary
goal of CVE, which is to be used by the providers of vulnerability
information, as opposed to being a primary source of that information.
There is often a fine line between the two.


Steve Christey
CVE Editor
The MITRE Corporation