The following update was sent to the CVE ID syntax discussion list, with a couple typos fixed for posterity in the public Board archives.
Here’s a brief update on what’s been happening for the CVE ID syntax change.
We are continuing to receive feedback to our cve-id-change@mitre address, and we are also monitoring mailing list discussions and Twitter commentary. There is no clear front runner, although Option C (with the check digit) appears to be more controversial than other options.
We are receiving additional syntax suggestions that we had considered in the past, but did not pass review by the CVE Editorial Board. We plan to write up a general response to the public regarding the most common suggestions. For more background, note that the final three options have been selected from a list of eight different options that we had originally proposed to the CVE Editorial Board:
Of the public proposals for alternate options, there are some themes. Many people suggest that we preserve the CVE-YYYY-xxxx structure, but to use hex digits or alphanumeric characters. We had already considered these options (options 5 and 6 as listed in the above post). However, based on feedback from the Editorial Board, and an informal review of existing codebases that extract or manage CVE identifiers, it was clear that these options would cause too much user confusion and/or force a radical change for all CVE-processing software, whereas the three final selections are all more “usable” and user-friendly because they only use numbers and hyphens, and would not have the same implementation cost as the hex/alphanumeric approaches.
For reasons that are not entirely clear, the initial announcement did not receive any press attention, but yesterday, Brian Krebs (former Washington Post journalist) wrote up an entry on his blog:
“Flaw Flood Busts Bug Bank”
Krebs’ “angle” is about the increasing number of vulnerabilities being disclosed each year, as demonstrated by the fact that CVE will have to extend its syntax. It appears that Krebs’ post has spawned some additional articles, so we might see a renewed interest in the syntax change, and a greater awareness among casual security observers that the number of vulnerabilities is increasing.
Since the initial announcement on January 22, we have seen blog posts or other commentary written in multiple languages, including Japanese, Korean, French, Portuguese, and others. This indicates that our message is reaching the global community of CVE users.
We are also beginning to see some misconceptions that we will publicly address at a later time. For example, some people are under the impression that the new ID syntax would cover “up to 999,999 vulnerabilities” (to quote Krebs), but two of the three options actually allow for an infinite number of IDs per year. We only intend to change the ID syntax once in CVE’s lifetime, so we want as much flexibility as possible, while also balancing usability and minimizing disruption if possible.
Another common misconception is related to the large number of CVE IDs that have been assigned in 2013 (we are at CVE-2013-1617 as of this writing). Some people assume that this means that over 1,600 vulnerabilities have been disclosed so far, but that is not correct; that number is artificially high because Candidate Numbering Authorities (CNAs) pre-reserve large pools of identifiers in the beginning of every year, so many of these 1600+ identifiers are “RESERVED” for future disclosures. We cannot reliably predict how many vulnerabilities will be covered by CVE this year.
We will keep you informed on our progress, and as before, please feel free to reply to this list with any questions or feedback.
Steve and The CVE Team