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

Re: Regarding CVE assignments on oss-sec mailing list

So I think we have defined the problem from an external view (e.g. what CERT/RedHat are experiencing as symptoms), but we haven't heard anything from Mitre yet. Steven can you comment/can someone from Mitre comment on all this?

On Fri, Nov 27, 2015 at 4:29 AM, Scott Lawler <scott.lawler@lp3.com> wrote:
What do we as the board need to do in order to fully define the issue?

- Do we need to find a way to get more resources for MITRE?
- Is there a depth of research required issue as well?
- What process step are we stuck on the most often?
- Do we have any process metrics available so we can make informed inputs?

We could in parallel start thinking about potential solutions.  I do agree with Art that we need to understand the issue well before we jump to solutions.

I think MITRE really needs our help on this.   We need to solve this to help that team continue to succeed.


> On Nov 27, 2015, at 1:14 AM, Art Manion <amanion@cert.org> wrote:
>> On 2015-11-27 00:31, Kurt Seifried wrote:
>> On Thu, Nov 26, 2015 at 10:27 PM, Art Manion <amanion@cert.org
>> <mailto:amanion@cert.org>> wrote:
>>    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?
>> 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.
> So that's an item under current state/issues.
>> 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.
> I generally like the idea (a speed/quality tradeoff), but let me suggest
> some process -- figure out where CVE is and what problems it faces
> before trying to solve them:
> Regards,
> - Art


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