Re: What is the future of CVE - Scope, Volume & Quality?
> 1. Can CVE effectively keep up in the face of an increasing volume of
> English-based disclosures?
It seems to me that the resource issue is a problem at the moment; for
example we are building up a steady backlog of CNA allocated issues that
are not yet in CVE (over 300 issues). Are there ways you can add staff
to deal with specific tasks without increasing the chance of CVE
> 2. What relationship should CVE have with any international effort (such
> as IVDA) to identify vulnerabilities disclosed in non-English based
It would be interesting to have a wider discussion with the bigger vendors
about non-English disclosures. All the work I've seen on disclosure
dates, days of risk, and so on have taken a public date from an english
dislosure, and not counted non-English disclosures. The problem probably
isn't non-english disclosures of issues that affect english software, but
rather non-english disclosures affecting non-english vendors. Could that
be solved by having a regional CNA and making CNA's do more work (at the
moment the work ends after allocating a name, there is no notification
aspect to Mitre as you mentioned).
> 1. Sources
So half of the issues we find out about after they are already public are
from the mailing lists "full disclosure" "bugtraq" and "oss-security"
only. Although another quarter are by us tracking other peer vendors and
upstream projects who monitor different subsets of lists.
I'd like to see something like this from Mitre; where did the majority of
your issues come from, how many were assigned by a CNA, etc.
> 2. Coverage
Maybe the rule could be that you will cover vendors that fix at least N
(100?) vulnerabilities a year by monitoring their lists, and for smaller
vendors you expect them to mail to one of the sources you define that you
> 3. Response Time
I'd be curious in usage stats from the web site (and perhaps NVD) which
you could compare to your response times to determine if you are choosing
the right subset of issues to be interested in. I suspect that 90% of the
vulnerabilities get little traffic, are those the ones you dealt with
Could you make a CNA give you some draft details of an issue prior to it
being analysed by your own staff? For example Red Hat would assign a CVE
to an issue on oss-security, enter a brief description and URL to the
Mitre site, and it would appear as a 'preliminary' description (either
automated like we used to do on NVD, or via some quick human analysis).
I could even see it being tied into your log analysis so that some spike
on a particular CVE would cause it to get bumped up your queue.
> 4. Quality
> a. What rate of duplicate CVE entries can be tolerated?
> b. How consistent does CVE "counting" need to be relative to past
> counting practices and content decisions? ("Counting" here means
> the relationship between a given vulnerability and the number of
> CVEs needed to correctly describe it and vice-versa. These may be
> one-to-one, one-to-many, many-to-one, or many-to many.). We believe
I believe that the duplicates tend to solve themselves over time and don't
cause particular harm. Even after nearly 10 years allocating CVE's I
still have difficulties with some corner cases and end up looking at the
old content decision pages or trying to get hold of Steve. Perhaps some
training for CNA's would help (or some yearly quiz/test/refresher).
Mark J Cox / Red Hat Security Response