Date: Mon, 7 Mar 2016 14:47:57 +1300 From: Amos Jeffries <squid3@...enet.co.nz> To: oss-security@...ts.openwall.com Subject: Re: Concerns about CVE coverage shrinking - direct impact to researchers/companies On 7/03/2016 9:39 a.m., Gsunde Orangen wrote: > I totally agree. > The concern addressed by Kurt initially is fully valid (for both > researchers and for companies that are not on Mitre's product/sources > list), so a new (better: additional) solution is required. > However, creating a new standard independently of CVE would be too > disruptive and be a disservice to the software industry. > I'd propose to work out a new solution together with Mitre, whilst > keeping the CVE IDs as today. > Since 2014, virtually unlimited number of CVE IDs can be assigned per > year , so a solution could be that > - Mitre continues to assign 4 and 5 digit IDs as today > - 6 digit IDs are reserved for the new process (hosted outside Mitre) > If more than one million vulnerabilities need to be addressed in one > year, we could follow the rule (odd digits -> Mitre, even digits -> > "other process") > From Mitre's POC, this "other process" would become a "CNA", just with > its own policy and process definition, not prescribed by Mitre. > It would soon become clear to everyone (and all tools and products that > rely on CVE) where to look at for the authoritative vulnerability > information. While reading this whole thread I have been thinking along very similar but slightly different lines. Right now as a vendor 'security desk' I/we have the situation where we have to allocate an internal reference ID anyway while awaiting Mitre assignment. These IDs are not spread so widely as CVE in the early stages, so we end up with other vendors and downstream distributions not quite in the same discussion loop allocating their own temporary numbers for the same issue. And some do anyway just because thats the way they operate. (Those aware of the history might recall this was the exact same situation which caused CVE to be created and centralized through Mitre in the first place.) Having an easily self-assigned OVI number does sound nice. At least for use as a temporary ID that can be publicly shared before the proper analysis can be completed by Mitre for a CVE, which can then sub-link. AYJ Download attachment "signature.asc" of type "application/pgp-signature" (835 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ