Re: CVE Issues

[Kurt Seifried <kseifried@redhat.com>]

On Mon, Nov 30, 2015 at 10:38 AM, Boyle, Stephen V. <sboyle@mitre.org> wrote:

It seems that we have collectively come up with a way to energize the Board in ways that it hasn’t been for some time.

 

We apologize for the delays in responding, and we intend this post to be the first step in opening discussions and making needed changes to CVE.

 

In recent days, some posters have noted ideas or suggestions they have raised in the past. We appreciate the reminders, and suggest that everyone should feel free to repeat or reprise prior comments so that they can be included in current conversations.

 

In the last few weeks, we have been working to change several things about CVE. Obviously, we can no longer operate cve-assign as we have in the past, and revamping cve-assign will create or cause several changes that we expect to ripple through CVE.

 

In the upcoming days, we will be publishing the following to this list:

• A clarifying statement of the scope of CVE.
• Discussion item for the Board  with regard to clarification/notification that CVE cannot (in fact) and will no longer (by design) cover all publicly known vulnerabilities, as defined by the scope of CVE.

It seems to me that we can have our cake and eat it. One thing that keeps coming up in my mind is the Cathedral and the Bazaar (https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar). CVE is a problem that inherently lends itself to massive parallelization (especially when split along code bases, e.g. as already done to a degree with CNA's), and I have some ideas how we can prevent/deal with the problems that are likely to occur with certain solutions but haven't spoken about them since they're rather radical/game changing.

I feel the lack of coverage for non English software, other software verticals (like SCADA/IoT) is already a problem, and will become more of a problem as everything in our lives essentially becomes a software driven platform (I already have software in my bathroom scale and fire alarms... to say nothing of cars/etc.). I hate to say it, but CVE's often make a security problem "real" in that many security platforms and processes heavily rely upon issues having a CVE so they can easily be tracked/addressed.

 

• Discussion item for the Board specifically regarding the topic of quality issues in the assignment of CVE IDs and the tradeoffs between performing more or less analysis of a request at the time of ID assignment and resultant downstream issues.

Ditto for my above comment.

 

 

We view the above as essential to moving forward by reducing the backlog and the response time for CVE ID requests. If we were to compare CVE to a house, scope would be the footings for the foundation of the house, and counting (abstraction) decisions would be that foundation.

 

We appreciate your patience as we have worked through a number of standing issues. We expect that these discussion and others in the near future will enable us to significantly improve the operation of CVE.

 

We greatly appreciate the Board’s attention, involvement, insights and opinions, and we look forward to working with the Board members on the upcoming discussions and decisions.

 

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