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

Re: Regarding CVE assignments on oss-sec mailing list





On Thu, Nov 26, 2015 at 10:27 PM, Art Manion <amanion@cert.org> wrote:
On 2015-11-26 09:36, Kurt Seifried wrote:

> Just as an aside, secalert@redhat.com <mailto:secalert@redhat.com> has
> also seen a number of requests in the form "we asked Mitre and now we're
> asking you" which I was unable to fulfill because the risk of a
> duplicate is to high

Just to pile on (again), CERT regularly gets requests for CVE IDs in
which the requester has asked MITRE/CVE and has not received a response.
 Also some vendor CNAs are, not performing, as Brian has mentioned.

Having CERT, or Kurt/OSS-SEC, or some other CNA assign more IDs is only
part of the problem.  As best I understand it:

1. CVE assigned
2. Publication/disclosure
3. MITRE/CVE populates entry (based on #2)
4. NVD and other downstream activity

If we increase #1, that just pushes work further down the list.

The current assignment model/process is under stress and probably needs
to change for CVE to remain broadly useful and relevant.

Any thoughts on how to go about this?  Starting with an evaluation of
current state/issues?

Regards,

 - Art

So I know we have something like 1000+ assigned CVE's that are public and not in the database yet. So the backlog is real.

One thing I had suggested to Steve Christey ages ago was "lightweight CVEs", e.g. instead of a full write up, just at least give the url for the OSS-Security assignment, or the official vendor advisory/etc (for cases where I had privately assigned it for a project/etc.). At least this way people can track down some info on the CVE easily (you can Google, but you get a lot of "reserved CVE" hits you need to filter out). These lightweight entries could always be promoted to "full CVEs" later on if needed.

--

--
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: November 27, 2015