2

The last time such a question was asked, there weren't even an official solution. Now we are supposedly on 5 digit CVE numbers for a whole year now, I've never seen then in the wild (apart from on MITRE website).

Will the security industry crumble and fall when the number go over?

Community
  • 1
billc.cn
  • 3,936
  • 1
  • 18
  • 25
  • don't you think they will add another digit, if it comes to that? I'm not sure what you're asking. – schroeder Jan 21 '16 at 18:28
  • The accepted answer to the linked question seems like a good answer to (the non opinion parts of) this question. I'm voting to close as dup. – Mike Ounsworth Jan 21 '16 at 18:30
  • As to the opinion part of your question: standards sometimes change. Unmaintained software often breaks and becomes obsolete when standards get updated. Fact of life. This is not unique to the security field, or to the the CVE standard in particular. – Mike Ounsworth Jan 21 '16 at 18:33
  • This currently has 4 close votes because it's both too broad, and it already has an answer. Perhaps if you edit the question to address these issues, the close votes would be retracted? – Mark Buffalo Jan 21 '16 at 18:49
  • @schroeder I'm pretty sure they'll add another digit. Particularly since they said they would, and already have. – Iszi Jan 21 '16 at 19:23
  • So as of now we have larger CVEs (the DWF project https://distributedweaknessfiling.org/ has been assigned CVE-YEAR-1000000 through CVE-YEAR-1999999). I just assigned CVE-2016-1000000 to an issue found by Tenable (Ipswitch WhatsUp Gold 16.4.1 WrFreeFormText.asp sUniqueID Parameter Blind SQL Injection). So if you have not implemented https://cve.mitre.org/cve/identifiers/syntaxchange.html you're in for a bad time. – Kurt May 17 '16 at 19:57

2 Answers2

5

The industry will not fall apart, because such an outcome would mean that the industry at large minds CVE numbers and acknowledges their existence; the day this will become true will be a glorious day indeed.

Thomas Pornin
  • 326,555
  • 60
  • 792
  • 962
5

The solution for running out of space in the CVE numbering scheme was to change to a "new format" that allows for additional digits in the last part of the CVE ID as needed. A request for input into the new format selection was put out in January 2013, with a decision announced in July of the same year, and the policy went into effect at the start of 2014. A number of CVEs have already been published under the new numbering format. This was announced by MITRE in January of 2015.

Really, the new format is just the same as the old format. The only difference is that people writing tools that use CVE IDs now need to accommodate the possibility of an arbitrarily-long number (minimum length four digits, using leading zeroes to pad as needed, no maximum length) at the end instead of just four digits.

If you're interested in finding out more about the CVEs issued under the "new" numbering scheme, you can download a copy of the CVE database and search for such entries yourself. I just threw the list of CVE IDs into Excel, ran Text-To-Columns with dash as the delimiter, then searched for values in the last column which were greater than 9,999. This turned up a total of 92 CVE identifiers issued under the "new format".

How this will affect tools or websites that rely upon CVE data is entirely up to the developers of those applications to address. If an application is even affected by the change (given the possibility that the developers may never have assumed a four-digit restriction on the last part of the identifier to begin with), it's then up to the people who made it to release a patch or not. Covering all applications which may or may not be affected, and their patch status or plans for patching, is far beyond the scope of this site.

Iszi
  • 27,127
  • 18
  • 101
  • 163