Re: Discussion of Well-Formed CVE Requests

[Kurt Seifried <kseifried@redhat.com>]

On Tue, May 10, 2016 at 9:41 AM, Common Vulnerabilities & Exposures <cve@mitre.org> wrote:

Greetings,

 

At the last Editorial Board meeting, there was a desire to include the entire Editorial Board in a discussion focused on reviewing the current set of expectations and guidelines describing a well-formed CVE request and CVE. This discussion started as part of the discussions happening within the DWF pilot.

 

The current guidelines are included in this document on Github:

 

<http://cveproject.github.io/docs/requester/reservation-guidelines.html>

 

What works well in this document?

 

What information is missing or problematic?

 

Is it too long? Is there a better format for the presentation that you think would work better?

 

Is it addressing the right audience?

 

Thanks for your assistance!

 

The CVE Team

 

So for the DWF handling of Open Source vulnerabilities my plan is currently for the general case:

Minimum required for CVE:

-Software name (and/or URL if it's a common name used more than once)

-Vulnerable version (one or more)

-Base flaw (CWE) or working reproducer that reliably triggers it or some decent description of the flaw (do X/Y/Z and this weird thing happens that has a security impact)

Strongly required for CVE (not mandatory, but there better be a good reason for not having these):

-Affected component (e.g. function name, URL in web app, etc.)

-Link or example of vulnerable code or a link or example of the code fix

-What the security impact is (AIC?) if you can't explain what exploitation accomplishes we have a problem

Requested for CVE (it'll speed things up):

-Fixed version/commit

-CVSSv2/3 scoring information

--
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