RE: CVEs listed incorrectly at MITRE as reserved

["Christey, Steven M." <coley@mitre.org>]

Kent,

Since the mere existence of a CVE ID can be useful for coordination even without a populated description and references, it might be useful for other Board members to weigh in on this topic.

We have been actively back-filling older reserved CVEs, especially in recent months.  As anybody who monitors CVE closely knows, our overall productivity is the highest it's been in years.

What might be less obvious is that the raw number of CVEs that are reserved through CNAs has increased significantly in recent years as well.  The number of reserved CVEs *tripled* from 2009 to 2013 (based on the number of CVE-YYYY-nnnn IDs that were originally reserved).  This is because of the increased adoption by CNAs, the rise of oss-security, as well as the increase in private reservations to the MITRE CNA because of our establishment of the CNA team and the cve-assign@mitre address in back in 2011.

Despite this sharp increase in reservations, we typically have descriptions for 90 to 95% of all the reserved CVEs that are being circulated in the public at any point in time. 

Notice that while your spreadsheet has 296 rows, many CVEs appear in more than one row.  There are 224 unique CVE IDs in the spreadsheet.

As of this e-mail, 213 of those 224 unique CVEs are still what we call "reserved-but-public" (RBP): the CVE is being referenced in public advisories, but the CVE's description still shows as RESERVED.  The other 11 have already been updated with a description and references ("populated") since your spreadsheet was first generated (which must be pretty recent since CVE-2014-0196 is listed.)

We make progress on the "RBP backlog" practically every week.  This is why your list already has 11 populated CVEs.  Also, for the list that was posted to oss-security in February, almost 300 CVEs have been populated.

You mentioned that many of the entries in your spreadsheet are for Linux vendor patch advisories.  
Most of those advisories are for vendors that are "partial coverage" - not full coverage - according to http://cve.mitre.org/cve/data_sources_product_coverage.html .  This reflects our focus on full-coverage sources, which includes Debian, Ubuntu, Red Hat, and SUSE.  We have much better coverage of those vendors than the other Linux vendors, especially in the past year.  So, many of the older CVE-2011-xxxx and CVE-2012-xxxx come from those full-coverage vendors.  (Note that we don't consider OpenSUSE to be part of the full-coverage "Attachmate: SUSE" category, and Fedora is explicitly mentioned as partial-coverage even though it's supported by Red Hat.)

We handle the RBP backlog as follows.  Day-to-day, the CVE content team focuses on populating reserved CVEs for currently-active references and creating new CVEs for must-have products.  Whenever that work is done (or pending time-consuming deep analysis), we reduce the backlog of older, reserved-but-public (RBP) CVEs - with a focus on full-coverage sources, but also accounting for partial-coverage vendors.  While vendor-originated advisories may be the priority, we also backfill other RBP CVEs or create new ones for non-must-have products as a result of training and/or focus for junior analysts.

One point of clarification.  You said:

> the chances of MITRE deleting these CVE's are less [for these vendor advisories] in our opinion

We rarely delete (i.e., "** REJECT **") reserved-but-public CVEs, and in general, we focus much of our attention on issues associated with vendor advisories.

I hope this sufficiently explains the situation and how we're handling it.

- Steve