[VIM] 267 Missing CVE in Jan, 2013 - please assign

[Christey, Steven M.]

Brian,

We are not able to handle your request for CVEs for all of the issues that OSVDB has published.  Unfortunately, CVE can no longer guarantee full coverage of all public vulnerabilities.

As some people on this list know, we are not well-prepared to handle the full volume of CVEs for all publicly-disclosed vulnerabilities, so we worked with the CVE Editorial Board to define the highest-priority items - information sources to monitor, and vendors/products to cover - and we are modifying our processes to ensure that we have full coverage of those items.  That work is still in progress.  We will guarantee CVE coverage for these issues, and other issues as resources allow, but at this time we will not be able to provide full coverage for any sources or products that have not been advocated by the CVE Editorial Board.  Consumers who want full coverage for all vulnerability reports, regardless of quality or importance, can look to other sources of vulnerability data.  CVE is for coordination of vulnerability information for products and sources that are the most important to the most people.

The presence of Kurt and the Red Hat CNA on oss-security definitely helps a lot, but as we just saw on oss-security in the past couple of days, duplicates can arise simply out of the complexities of having multiple CNAs, and this problem would become worse with more than 2 CNAs without well-defined roles to minimize overlap.

This year, we are concentrating on (1) the CVE ID syntax change, (2) updating our analytical infrastructure and processes, and (3) training our new analysts.  We do not know what our productivity will look like later this year, once all of these things are in place, but it will be an improvement.

Because of our focus in those areas, we have consciously tabled questions such as (1) how to prioritize the public CVE assignments for non-essential products, (2) how to effectively populate CVEs that have been used in the public, (3) how (and whether) to support external contributions for CVE descriptions, and (4) what reductions in description quality, if any, would be suitable to allow CVE to produce more content at the expense of its usability.  None of these decisions are to be handled casually or without sufficient discussion and debate in the proper forums, of which the VIM list is one of many.

Unlike vulnerability databases, CVE has a responsibility to many different consumers and needs to balance their different needs and perspectives.  We have also learned over the course of a decade that having a small group of critical individuals work for 50+ hour weeks is unsustainable and fragile; at this stage, CVE is now at a point where the departure of any single person - including myself - would not be fatal to the project.  Getting CVE to that point has been a long process.

We have also learned from projects such as OSVDB that distributing content production to the general public makes it very difficult to control quality and keep people motivated, and appropriate funding models are hard to come by.  As I said at RSA, "information is free, but nobody wants to pay for it."  For CVE, we are very lucky to have had a long-running sponsor in the Dept. of Homeland Security, but of course all funding has limits.  And, ironically, there are downstream consequences to increased productivity - we have already been privately told that our increase in productivity last year was stretching the analytical limits of one of our downstream CVE consumers, and they were not happy to hear of our upcoming productivity increase when our new analysts are ready to create new CVE entries.  Of course that should not be a driver for keeping productivity low, but this is one example of how CVE has a different set of considerations that others do not.

- Steve