RE: The CVE-10K Problem

["Kevin Ziese (ziese)" <ziese@cisco.com>]

Personally, I like the idea of using the raw number value, whatever it
is.  Although it's a bit disconcerting to see values in the ten
thousands place -- it's a very useful way of identifying the gross scale
of the vulnerability problem.

For all of the security technologies and tools -- you'd think we'd start
seeing fewer raw numbers instead of more, eventually.  I think raw
numbers help keep a sense of scale on the whole vulnerability problem.

Are we winning? It doesn't always sound like it; so, raw numbers seem
more useful to me.

Kevin 

-----Original Message-----
From: owner-cve-editorial-board-list@LISTS.MITRE.ORG
[mailto:owner-cve-editorial-board-list@LISTS.MITRE.ORG] On Behalf Of
Mark J Cox
Sent: Monday, January 15, 2007 9:03 AM
To: Steven M. Christey
Cc: cve-editorial-board-list@LISTS.MITRE.ORG
Subject: Re: The CVE-10K Problem

I like seeing CVE identifiers used in publications that go to
non-technical audiences, and I fear we'd frighten them away with hex.  I
find the year useful, even if it's slightly out by one or two years for
some issues.

I almost liked changing the initial identifier based on the type of
issue (why not put all those vulnerable webapps into CVF-2007) but I
think people would be confused because the CAN prefix mapped to CVE
directly, so
CVE-2004-2001 == CAN-2004-2001 but CVF-2007-0001 != CVE-2007-0001.

I'm pretty sure everyone implementing tools around CVE will have to make
tool changes no matter what, so I'd much prefer us rolling over to
CVE-2007-10000 which is a) what people will expect b) much less of a
hack and c) gives the tools at least half a year to prepare.  I also
prefer it since half the Red Hat tools will work just fine where we used
the regexp C\S\S-\d+-\d+ for validity.

Red Hat itself moved from 3 digit to 4 digit advisory identifiers at the
start of 2006 (we added several new products and we share identifiers
between security and non-security updates).  In the end we didn't need
the whole range in 2006, but because we started it at the start of the
year we were able to add the leading 0 to help fix the sorting issues.

Mark