Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Feb 2017 16:40:29 +0000
From: "Priedhorsky, Reid" <>
To: "" <>
CC: "" <>
Subject: Re: MITRE is adding data intake to its CVE ID process

On Feb 10, 2017, at 8:59 PM,<> wrote:

C5. I want MITRE to send the<> form data, and
the CVE ID, to the oss-security list at the same time that these are
sent to the requester.

R5. We have had internal discussions within MITRE about this. We are
able to implement this easily if the community requires this approach.
At the moment, we are expecting the requester to resend this
information to oss-security once they accept their CVE ID assignment.
Please see
for an example.

C6. I want MITRE to send the<> form data to
the oss-security list as soon as that data is entered (i.e., before a
CVE ID exists).

R6. We have had internal discussions within MITRE about this. We are
not yet able to implement this easily. We may work on this if the
community requires this approach. However, our understanding of CVE
consumers is that they look to MITRE as a source of vulnerability
information after a CVE ID number exists, not before.

I’m glad to see the feedback taken seriously as well.

Recall that my oss-security use case was to maintain a reasonably comprehensive list of vulnerabilities for specific products. This workflow looked like:

1. See a notification (whether CVE request or not) on oss-security regarding products I’m interested in.
2. Add the vulnerability to my list.
3. Monitor the thread for additional information (patch, CVE assignment, etc.)

Like others, timely notification is more important for me than the CVE itself, but the CVE does help because it means list entries eventually get a unique ID.

I would like to see both C5 and C6 implemented as soon as practical.

As for whether it’s appropriate to send form data to oss-security immediately, I believe the right approach is to simply add the send/not send choice to the web form, required, with no default, so people must make a deliberate choice.

The alternatives I’ve seen raised would not be adequate for me. Specifically, depending on people to forward their stuff to the list is too brittle (people won’t do it reliably), and watching an XML feed requires setting up and maintaining software for a new data feed.


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ