CNAs using CVE IDs for Internal Bug Tracking

["Coffin, Chris" <ccoffin@mitre.org>]

As part of the Feb 22 CVE Board call, the Board discussed CNAs using CVE IDs as part of their internal bug tracking. Specifically, when assigning CVE IDs early in the vulnerability management process by the CNA, CVE IDs may be assigned to issues where the details are not fully understood yet (e.g., the issue is later found to not be a vulnerability, multiple vulnerabilities turn out to be one, etc.) or for which there is never an intention to make them public. We know there are software maintainers that would like to function in this way. CVE would like to reach out to the Board as a whole and CNAs to better inform any decision made regarding whether this should be allowed.

 

Some CNAs currently assign CVE IDs as a final step before publication, and we are in no way stating that this is wrong or attempting to guide these CNAs away from continuing this practice. Instead, the question is if CNAs should be given the flexibility to assign CVE IDs in whatever way works best for their them. In order to support this flexibility, the current CNA Rules would need to be changed.

 

The main benefit pointed out by the proponents of this idea claim that using CVE IDs early in the process allows the CNAs to more easily track their vulnerabilities throughout their lifecycle. For example, attaching a CVE ID as a first step in the process avoids the need for assigning an internal ID (e.g., internal bug id) and then having to later map that internal ID to a CVE ID. One additional point brought up in the Board call discussion was the fact that allowing this flexibility in assignment could promote additional use of CVE IDs in the future.

 

One downside of this flexibility would be that downstream CVE users will not be able to determine if a CVE ID is in use.  We already have this problem with number of RESERVED CVE IDs in the list, but MITRE is making an effort to reduce the number RESERVED CVE IDs.  However, the proposed change would make this problem worse.

 

One suggestion was made on the Board call that might help mitigate some of the problems associated with allowing this flexibility to CNAs. The suggestion was to create a new CVE ID status to cover CNA block reservations. Instead of RESERVED, we might refer to them as CNA-ASSIGNED or some other tag that differentiates them from other currently RESERVED CVE IDs. This could help CVE end-users differentiate between CVE IDs assigned as blocks to CNAs versus CVE IDs assigned to researchers for public or non-public but already identified vulnerabilities.

 

In addition to the above, another mitigation might be to recommend that the CNAs repurpose CVE IDs whenever possible. If the bug is later found NOT to be a vulnerability, they could release the CVE ID for use in a later issue. We could also enforce that CNAs report their unused CVE IDs (i.e., those CVE IDs that were NOT made public) on at least a yearly basis so that the CVE IDs can be REJECTED as unused. The CVE IDs may effectively live on within the CNA, but it would be considered unused and REJECTED by MITRE if it was not reported to an upstream CNA and made public.

 

We are considering starting a discussion on the CNA-list to get feedback from other CNAs, but figured we would run it by the Board first since not everyone was on the call. Do others on the Board object to allowing CNAs the flexibility to assign CVE IDs as has been proposed here?

 

The CVE Team