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

Re: CVEs with no REF URL (or a REF URL that is self referential)

I think making the URL optional is ok.  But, what is the definition of "all the needed data"?    


How can we quantify that sufficiently to quickly reject the items without sufficient information?


Can we provide sufficiently detailed guidance to cover most use cases?  


Scott

From: owner-cve-editorial-board-list@lists.mitre.org <owner-cve-editorial-board-list@lists.mitre.org> on behalf of Kurt Seifried <kurt@seifried.org>
Sent: Wednesday, October 4, 2017 12:48:03 PM
To: cve-editorial-board-list
Subject: CVEs with no REF URL (or a REF URL that is self referential)
 
So currently CVE assignments require a URL.

My proposal is that, simply put, if the CVE itself can contain all the needed data why not remove the requirement for the URL. The advantage of this is that for embargoed issues we can immediately submit the CVE to the database without having to wait for REF URL's to be created. The other advantage is that the REF URL can't disappear, the data is embedded directly in the CVE entry. 

The common case is that in the OpenSource world we often have all the information needed for a CVE assignment, specifically in the form of a patch with notes, but that patch has not yet been committed, and it may not be a deterministic URL once committed (if we knew the URL in advance we would simply put it into the REF URL). This is especially true for Linux kernel commits and many other projects that use git. Often times as well these entities do not publish a security advisory or anything beyond "here's the patch commit with a note" (which is sufficient information in almost all cases). 

So I think simply put if the rules are changed to include a statement such as:

The REF URL may be omitted, or set to reference the CVE itself (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-XXXXXX) if the description contains sufficient detail to fully explain the CVE (e.g. code patch information). 



--
Kurt Seifried
kurt@seifried.org
Page Last Updated or Reviewed: October 04, 2017