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

Re: CVE program priorities

One major comment:

What is the purpose of CVE? My understanding was to provide an identifier for vulnerabilities. Essentially a serial number to make handling inventory easier. I don't care what's in most of those boxes, but I do need to be able to track them down as needed.

That we have an official database at cve.mitre.org/NVD is nice, but not needed as evidenced by the fact that something on the order of 11,000+ CVE's have been assigned and not written up and listed in the database (I know of at least 1000+ from myself personally). I even updated the Wikipedia entry to cover this because I kept getting people asking me why I had not updated the CVE database after assigning them a CVE privately/publicly. 

Personally for me the official CVE database at this point is the search engines. When I plug CVE-YEAR-FOOO in I expect to get something resembling a trusted site (e.g. bugzilla.redhat.com, bugs.debian.org, launchpad.net, upstream bug trackers, OSS-Security archives, etc.) with an entry that contains the CVE string I'm looking for. 

I think we should really split the problem into:

1) assigning CVEs

2) the CVE database

as #1 can happily exist with or without #2.

On Tue, Dec 22, 2015 at 10:55 AM, Boyle, Stephen V. <sboyle@mitre.org> wrote:

On Thu, Dec 17, 2015 at 11:17 AM, in the thread on “Upcoming changes for CVE,” Kurt Seifried wrote:

> Is there an ETA on any of this? Days/weeks/months?


It is clear at this point that CVE is not able to cover every known vulnerability. The simple fact is that the number of CVEs published every year has not kept pace with the rate or number of vulnerabilities disclosed. CVE has operated successfully for many years but fundamental changes are needed. Fifteen years ago, we could effectively focus on the U.S. IT sector and tell ourselves that we were essentially providing coverage for the world.  Given the international explosion of software development, that is no longer the case.


As stated on the CVE web site “CVE is sponsored by US-CERT in the office of Cybersecurity and Communications (CS&C) at the U.S. Department of Homeland Security.” DHS has identified a number of Critical Infrastructure Sectors and CS&C is the identified as the lead for the U.S. IT sector. As we consider how to increase the coverage of CVE, CVE must – as its highest priority – effectively provide full coverage of the software and devices used in the U.S. IT sector.


To achieve the fundamental changes required for CVE, we the Editorial Board must wrestle with a number of important topics while CVE continues to operate. We have been actively listening to and hearing the issues and concerns expressed on the Board list and on the outside. We have been working internally to understand the issues and interdependencies limiting CVE and to reflect those back to the Board for consideration.


To that end, we suggest the following list of tasks, in priority order:


0.       The operation of CVE

1.       The prioritized scope of coverage for CVE and the associated Sources and Products

2.       A re-examination and simplification of the way CVE counts vulnerabilities

3.       The required “quality” of final CVE entries

4.       Clear, redefined rules and guidelines for the operation and management of CNAs

5.       Clear, redefined and more inclusive rules for becoming a CNA

6.       Continuing revisions regarding Board membership and the process for adding members


We sincerely appreciate the Board’s continued efforts. You have always been a critical part of CVE, from back in the days of voting on CANs to today. We look forward to comments and discussions on this list to evolve CVE.


Best Regards,

Steve Boyle


Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com

Page Last Updated or Reviewed: December 28, 2015