[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVEs listed incorrectly at MITRE as reserved



On 2014-05-14, 09:29, Christey, Steven M. wrote:

> 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.
...

> 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.
...

I just opened a discussion with Steve about different types of CVE ID 
request that CERT handles.  We generally assign IDs for vulnerability 
reports that we privately coordinate, however we've been getting 
requests from vendors and researchers for "just" a CVE ID, and not 
coordination.  Not a lot of requests (I can't measure easily, but ~3/40 
for vendor requests in the first part of 2014), but it's to the level 
we've asked for guidance on when to issue an ID.  Overall, our 
assignment rates have been growing for years.  (At times, we have acted 
as a CNA for other CSIRTs who are now also CNAs).

year	alloted	assigned
====	=======	========
2002	12	2
2003	25	18
2004	10	8
2005	30	22
2006	30	28
2007	85	84
2008	45	45
2009	40	40
2010	45	36
2011	125	125
2012	245	233
2013	155	155
2014	90	64 (to date)

> 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

I'd generally expect some degree of delay/slack/queue time as multiple 
CNAs are assigning IDs and the MITRE/CVE mothership CNA is processing 
assignments, and prioritizing according to the coverage policy.  213 RBP 
IDs doesn't *feel* like too large of a queue/backlog, especially if they 
are lower priority reports.

I do think this illustrates the pressure between maintaining a certain 
scope of coverage while the vulnerability disclosure forces of the world 
are trending towards wanting more coverage.

Regards,

  - Art


Page Last Updated or Reviewed: October 03, 2014