[VIM] CVE published vs unpublished

Steven M. Christey coley at linus.mitre.org
Wed Jan 23 21:12:51 UTC 2008


> Can someone from CVE administrator give me an estimate how many given CVEs
> have not materialized into "anything" (never been disclosed - remained under
> review)?

I can only give estimates, because I don't have any visibility into the
status of CVE pools that were given to CNAs (Candidate Numbering
Authorities).

Also, I don't ping the people who reserved CVEs in order to check on their
status.  Some might have turned out to be false and the requester never
notified us; in other cases, maybe a decision was made not to publish;
some might still be in the middle of the resolution process.

Also, we are inconsistent about handling vague vulnerability reports from
auction / non-disclosure firms like WabiSabiLabi and Immunity, but
generally don't include them.  This includes the hash publications we're
starting to see more of.

Finally, sometimes somebody publishes a CVE to a source that's not
monitored by Refined Vulnerability Information sources, and we don't
notice that it's been published - but this is 5% at most, and probably
more like 1 to 2%.

I generated some stats based on how many CVE's still have the "** RESERVED
**" text in the descriptions:


=============================
Active Reserved
=============================

2001 28
2002 57
2003 79
2004 102
2005 203
2006 213
2007 337
2008 163


So, this is a maximum number.

However, many of these are associated with CNA pools, and many of them
might be lying around, not assigned to any specific issue.

The following two tables are for CVE's that are definitely associated with
CNA pools (findable from an inconsistently-used convention I have), plus
"likely CNAs" - individuals who almost always reserve issues because
they're CNAs:


=============================
Definite CNA
=============================

2002 --> 9
2003 --> 40
2004 --> 51
2005 --> 61
2006 --> 68
2007 --> 72
2008 --> 46


=============================
Likely CNA
=============================

2001 --> 10
2002 --> 15
2003 --> 3
2004 --> 3
2005 --> 32
2006 --> 11
2007 --> 87
2008 --> 49


I could try to infer pools to clean up the likely CNA stats, but these
stats are cheap, and unfortunately I don't have a lot of time for this.

With definite and likely CNA pools, there's no way of knowing how many of
those CVEs remain unassociated with any issue, versus those that were
assigned to an issue, but never published.  It's probably reasonably safe
to assume that most of the CNA CVE's from 2006 and earlier are unassigned;
I don't think that I've had more than 2 or 3 interactions in which it
became clear that the CNA was going to intentionally keep an issue
private, even after a CVE had been assigned.


Then we have CVEs reserved by people who are definitely not CNAs (or very,
very rarely have that role).  These are likely to have been reserved for
specific issues:

=============================
Non-CNA
=============================

2001 18
2002 33
2003 36
2004 48
2005 110
2006 134
2007 178
2008 68


For each year, we have:

  Active Reserved = Non-CNA + Likely CNA + Definite CNA


We can treat the Non-CNA values as a minimum estimate (which might still
be higher than the real number), Active Reserved as a maximum estimate
(probably also higher than the real number).

I think I can safely estimate that 50% of reserved CVEs from definite
CNAs, and 20% from likely CNAs, remain unsassigned (let's ignore the
higher likelihood for 2006 and earlier).

So, a more reasonable max. estimate would be:

  Non-CNA + (20% of Likely CNA) + (50% of Definite CNA)


which leaves us with the final estimate:

=============================
Estimated Min/Max
=============================

2001  min=18  ; max=20
2002  min=33  ; max=40
2003  min=36  ; max=56
2004  min=48  ; max=74
2005  min=110  ; max=146
2006  min=134  ; max=170
2007  min=178  ; max=231
2008  min=68  ; max=100


Note - these figures feel high, but on the other hand, CVE reservation is
a daily task so I might not be conscious of how much remains unpublished.

- Steve


More information about the VIM mailing list