CVE ID Syntax Change – My Feedback

CVE ID Syntax Change – My Feedback

Today (Jan 22, 2013), I saw that Mitre had released a public call for feedback in regards to proposed CVE identifier syntax changes.

I took a few minutes after reviewing their proposed choices and sent a response. If you work heavily in vulnerability management or information security I would recommend you review the proposed changes at the link above and give your feedback.

The text from my feedback on the propose changes is below.


 I think Option B is the best option.. 

Reasons for Option B
– Option B provides the clearest path forward for programs that use or parse CVE numbers because it…

  • Allows backward compatibility (software shops can continue using current parsing logic & display formats) It only has to change if/when needed.
  •  Allows companies to update their CVE data field parsing algorithms to a best practice of taking any numbers found in the digits field without requiring them to expect the padded zero formats. Expecting and forcing a new format forces changes throughout any existing code.
  • Allows simpler algorithm for parsing new or old CVE format data. If you force padded zero’s, then programs will have to base their parsing logic for the number field based on the year field, or be based on the number of digits in the field. If you choose option B, the logic can be the same for the old and new format (just accept whatever is there), and not really care about the number of digits initially. This might allow for an easier adoption by code that currently parses CVE data. (option C would require even more changes)

– Yes, option B does not force the hand of every software developer to immediately update code and logic for your changes,  which might actually be your saving grace. This puts the responsibility on the software developers and companies to comply with the format changes, but does not force a change on them that breaks functionality and their product otherwise.

This takes the pressure off Mitre that will come from “breaking” money-making products for companies, and puts it back on the companies to make the changes.

Why Not A?
-Depending on a certain number of digits (6) with leading zero’s forces programs to immediately update algorithms and display fields before they are compatible. 1 year is not much time for applications heavily integrated into enterprises. I doubt you will get good adoption for your new format in the requested 1 year timeframe regardless.

Why Not C?
-Same reason as “why not” for reason A. And you are now adding yet another field to be parsed that adds very little effective value.

Why Not B?
– The reasons posted on Openwall as shortcomings for reason B are valid, except that I don’t really buy the whole “it’s not as forward compatible” logic. It actually could be the most forward compatible option if your guideline is that you must accept any number of digits given. – Data Based Security Site

I recently made a small contribution to

If you are in the IT  Security field and ever need to analyze CVE data or search for security issues on a certain product or Vendor, this is a great site to use. This is one of the few sites that are purely focused on security data and details that can be used to do objective security research.

I would encourage anyone else out there that finds this site useful to make a contribution. If your company could use their data or services I would encourage you to become a corporate sponsor.

We need more of these types of sites that are working to improve transparency and availability of IT Security related data.