|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: The CVE-10K Problem
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
|
||||