[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVE numbering


Adam Shostack said:

>one thing that jumps out at me is that you seem to have started at
>CVE-1, which means that we lose the ability to be roughly
>chronological and backfill.  In our discussions at the CERIAS
>workshop, we had suggested starting at 10,000, so that we can put in 1
>as "Moth in vaccuum tubes"

I don't think the CVE numbering scheme will ever be able to be
completely accurate in terms of chronology, and if we are to follow
the "purity" of the CVE concept, that sort of information is better
left to more comprehensive vulnerability databases (or CMEX at best).

As Andre pointed out, renumbering could be a problem as well.  To
maintain stability, we want to avoid renumbering as much as possible.

However, I do agree that there is a use for distinguishing between
"new vulnerabilities" and "old vulnerabilities" with respect to the
date that the CVE goes public.  I.e., vulnerabilities that are
discovered after initial release could be assigned numbers from 10000
and up, as Adam suggested; older vulnerabilities that were known
before initial release can be back-filled starting from 1.  This rough
"encoding" within the CVE numbers could accomplish the following:

- it cleanly divides "post-CVE" and "pre-CVE" vulnerabilities 

- numbers after 10,000 ("new vulnerabilities") would have a relatively
accurate chronological order implied, close to the creation date as
recorded in CMEX, although there cannot be a guarantee (consider the
discovery of a "controversial" vulnerability that requires some
discussion before inclusion into the CVE).

- numbers before 10,000 would have no implicit chronology, but all
would be known to have existed "before CVE"


- Steve
Page Last Updated or Reviewed: May 22, 2007