Re: The CVE-10K Problem

[Adam Shostack <adam@homeport.org>]

On Fri, Jan 12, 2007 at 05:20:28PM -0500, Steven M. Christey wrote:
| All,
| 
| Well, it's that time.  For 2006 so far, we've nearly assigned 7000 CVE
| identifiers.  We don't have 100% completeness, but I'd say that for
| the usual sources (major vuln DBs, vendor advisories, Bugtraq etc.)
| there might be another 100 to 1000 CVE's for 2006.
| 
| Given the continued vulnerability growth trends, it's a real
| possibility that in 2007, we run the risk of assigning 9,999 CVE's for
| issues.  What to do with the 10,000'th entry is the CVE-10K Problem.
| 
| Here are some possible solutions.  Feedback appreciated.  We can cover
| this topic in an upcoming telecon, too.
| 
| 1) Keeping the year and moving to hex-based... CVE-2007-9999 would go
| 
| 2) Completely randomize the year portion.  We've considered this for a
|
| 3) Adding 1000 to the year.  Benefit: introduces predictability, and
| 
| 4) Keeping the year, and extending the numeric portion to 5 digits.
| 
| 
| Handling over, say, 20K issues in a year would likely require a
| paradigm shift within the entire vulnerability information management
| industry.  As Dave Mann has pointed out to me numerous times, the
| growth in the number of vulns is outpacing the growth in CVE funding,
| which has been mostly flat with respect to content generation itself,
| with increasing risks of our funding actually being reduced (I don't
| think most people understand why good vulnerability information isn't
| cheap.)  Anyway, I suspect that this growth problem is hurting other
| vuln databases/products, too.  We're already seeing some of that
| paradigm shift; the Board gave up voting a while ago due to the amount
| of effort, you're seeing more generic vulnerability database entries
| with more mistakes (probably being made by less experienced analysts
| with less editorial oversight), the percentage of verified issues is
| probably smaller, etc.

(Speaking for myself)

I don't think we should be tying a CVE shift to the possible need to
address huge changes in the vulnerability management space.  What
those changes will look like is hard to predict, and it may be that
having a large CVE namespace will make it easier.

I think 1 is the right direction, and would like to advocate for 1',
which is that the last 4 characters of the CVE be 0-9 and the
alphabet, perhaps case sensitive.  (I would urge that the first two to
be issued would be 2007-000a and 2007-000A to drive home the point,
and then work to avoid use of capitals, I, O, and S for readabbility
reasons.)  This gives us a large namespace without needing to redefine
data tables.

I think (3), adding to the year simply shifts the problem out 1000
years, and is thus shortsighted.

Adam