[
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
