再保险:澄清/声明最近CVE抽象政策变化等等

布莱恩,你注意到所有的改变源于最近修改的CVE程序。大多数这些问题归结到变化实现为新的CNA规则的一部分,2016年10月生效。所有的这些变化以前与CVE委员会讨论。也注意这些的例子包括一个描述是由请求者通过CVE web表单并提交。使用requester-provided描述我们的整体战略的一部分规模CVE计划。>第一个问题就是奇怪,似乎有人匆忙,>但这是有问题的网站使用CVE数据生成统计数据,作为产品名称>之前可能不匹配条目虽然这些例子通常不是常态,斜方并没有试图标准化产品名称。我们一直期望那些基于CVE的数据,像NVD,提供这种类型的值增加。然而,这可能是一个很好的未来的董事会会议的主题。>我也注意到,谁让最近条目不包括>中引用的明显修复提交bug门票。横切的政策不需要包括修复提交,尽管我们在先前的情况下已经这么做了。同样,如果另一个引用可以很容易地通过一个已经包含我们可以跳过前。 > The use of arbitrary date-based "versions" that are not in line with > the vendor versions. As far as we can tell, this is an isolated case in which the product is not versioned. The requester chose to include the date of the fix, which we considered reasonable. > We usually see this with low-end researchers trying to pass off > site-specific issues as products and using a date as the version > (e.g. > CVE-2017-6479) We rarely see dates as versions, and when we do, it is usually because the vendor has chosen to use the date as a version (e.g. CVE-2016-7511). There is no question whether CVE-2017-6479 is site-specific because the reference the requester provided clearly links to a git repository where the code can be downloaded. > An apparent change in abstraction rule where five IDs were assigned > for XSS issues that previously would have received one ID (e.g. > CVE-2017-6487, CVE-2017-6488, CVE-2017-6489, CVE-2017-6490, and > CVE-2017-6491) In this case the requester provided separate reports that appeared to be independently fixable. The change to split by independently fixable vulnerabilities rather than vulnerability type was enacted with the new CNA Rules. The CVE Team -----Original Message----- From: owner-cve-editorial-board-list@lists.mitre.org [mailto: owner-cve-editorial-board-list@lists.mitre.org]代表耶利哥派:星期天,3月5日2017 6:42点:cve-editorial-board-list < cve-editorial-board-list@lists.mitre.org >主题:澄清/声明最近CVE抽象政策变化和更多的重要性:高斜接,你能给董事会一个更新最近的CVE条目的变化呢?最新一批上跳下三件事:1。缺乏一个合适的产品名称(例如cve - 2017 - 6478, cve - 2017 - 6479, cve - 2017 - 6480) 2。使用任意基于日期的“版本”不符合厂商的版本。我们通常认为这与低端研究人员试图通过特定场地问题产品和使用日期的版本(例如cve - 2017 - 6479) 3。一个明显的抽象规则的改变,五个ID分配XSS问题之前会收到一个ID(例如cve - 2017 - 6487, cve - 2017 - 6488, cve - 2017 - 6489, cve - 2017 - 6490,和cve - 2017 - 6491)。看来你的唯一原因是,不同的bug追踪门票打开,尽管相同版本的影响,相同的研究员,相同的日期,等。第一个问题是奇怪的,似乎有人匆忙,但这是有问题的网站使用CVE数据生成统计数据,作为产品名称前可能不匹配条目。我也注意到,谁让最近条目不包括明显的修复提交bug中引用的门票。基本上,只是草率的工作。第二个是很有关,因为是的。 I shouldn't have to elaborate on that one. The third one just seems to break a long-standing abstraction policy. I have a feeling the "different tickets" will be the justification as mentioned above, but also fairly certain that multiple mail list posts (e.g. Bugtraq or Full-Disclosure) from the same person on the same date affecting the same version of the same product didn't warrant splits before. Any clarity on policy changes regarding these issues would be appreciated. .b