Define what year of CVE ID (e.g. CVE-2017) should be used during an assignment.

[EvansJonathan]

GOAL: Simplify assignment process
CHANGE: Just make CVE ID year the year it was assigned.
OUTCOME: Reduced overhead for getting a CVE ID with the correct year. Reduced confusion by CVE consumers.

[EvansJonathan]

The policy MITRE currently uses for our assignments can be found on our FAQ. http://cve.mitre.org/about/faqs.html#year_portion_of_cve_id

[kurtseifried]

I think there is some value in defining when this was known as a vuln, it's basic home work. also it's a good minimum bar fr transparency (e.g. stuff that is years old... why?).

[EvansJonathan]

It is not clear to me what value we get out of requiring the year in the ID match the year the vulnerability became public over having a data field that records the publication date. However, there are operational costs to implementing the requirement. Investigating when the vulnerability was first known is an obvious one, but there are also issues like what do you do when it is later shown that the vulnerability was first known in an earlier year. Using the year the ID was assigned negates all of these issues.

[dadinolfi]

The question is which meaning we want to give to the metadata that comes with the year in the CVE ID. Right now, per the FAQ referenced above, the year can have two implications. Either the meaning is "the year it was assigned" or it is "the year it was made public".

I suggest that the we should avoid adding metadata to the CVE ID number itself. Just as some consumers mistakenly draw meaning from the ordinal portion of the CVE ID (thinking that the number of the CVE implies importance, relevance, scope, size, etc.), consumers can mistakenly draw meaning from the year portion. If we flat out say "the date is the year this was assigned and that's the only metadata you can derive from it", that reduces ambiguity. More information can be included in the description or references, where metadata is more appropriate and more clearly stated (such as through the JSON schema).

The more information we try to load into CVE-YYYY-NNNNN, the less clear its meaning will be. It is intended to be a unique name for a specific vulnerability and nothing more.

[david-waltermire]

+1 for less meaning in the ID.

We have talked about sharding a Git repo based on CVE ID year ranges as a solution for file size limits, which do not exist for Bitbucket, but do exist for GitHub. The decision made here may affect sharding if and when we run into size issues. Not sure if that matters, but this is something to consider in light of this issue.

[attritionorg]

@EvansJonathan I provided examples of value of this on the Board or CNA list earlier this year. Further, if you see no value, what is the point of having a year-based identifier for the first quad of the ID? Why not just make them any four numbers. This is another 17+ year policy that MITRE has followed pretty closely, until the regime change a couple years ago.

[EvansJonathan]

I did not say that it did not have value. I said using the year the vulnerability became public has value, but so does using the year the ID was assigned. Both have value, but I believe the reduction of operating cost, CNA training, and other benefits of using the year assigned outweigh the arguments for using the year the vulnerability became public (which, I believe, is currently that people use the year in the ID for year-end vulnerability reports).

This is another 17+ year policy that MITRE has followed pretty closely, until the regime change a couple years ago.

While MITRE followed the policy, we did not enforce the policy on the other CNAs, and we are trying to significantly increase the number of CNAs. Additionally, while MITRE followed the policy closely, the end result was that the meaning of the year portion of the ID had one of two meanings (see http://cve.mitre.org/about/faqs.html#year_portion_of_cve_id). The proposed change would give it a consistent meaning.

[ghost]

Changing the 4 digit year to simply be the year the CVE was assigned would make it a very simple/clear rule (as opposed to right now where we have older issues and there's sometimes debate about which year to use). Adopting this would also mean that once we hit Dec 31st, midnight, we can simply stop using the block for that year (and by extension the previous years) so there's no need for CNAs to keep blocks of old CVEs around for use "just in case". So I would vote +1 for "the YEAR portion of the CVE ID is simply the year that CVE was assigned, either in RESERVED or PUBLIC state, the year no longer is attached to when the vuln was found, or reported or whatever".