RE: cf列出错误在斜方保留

肯特,因为仅仅存在一个CVE ID可用于协调即使没有密集的描述和引用,它可能是有用的其他董事会成员参与这个话题。我们一直在积极地充填采矿老保留cf,特别是最近几个月。谁密切监视CVE都知道,我们的整体效率是最高的。可能不太明显的是原始的cf保留通过CNAs近年来显著增加。保留cf * *三倍的数量从2009年到2013年(基于CVE-YYYY-nnnn id最初预定的数量)。这是因为增加的区域,采用oss-security的崛起,以及增加私人预订CNA的横切CNA因为我们建立团队和在2011年cve-assign@mitre地址。尽管如此急剧增加的预订,我们通常描述为90 - 95%的保留流传的cf,公众在任何时候。注意,当你的电子表格296行,许多cf出现在多个行。有224个独特的CVE电子表格中的id。这封电子邮件,213这224独特的cf仍然是我们所说的“reserved-but-public”(RBP):中引用的CVE被公共警告,但仍然显示保留CVE的描述。 The other 11 have already been updated with a description and references ("populated") since your spreadsheet was first generated (which must be pretty recent since CVE-2014-0196 is listed.) We make progress on the "RBP backlog" practically every week. This is why your list already has 11 populated CVEs. Also, for the list that was posted to oss-security in February, almost 300 CVEs have been populated. You mentioned that many of the entries in your spreadsheet are for Linux vendor patch advisories. Most of those advisories are for vendors that are "partial coverage" - not full coverage - according tohttp://cve.mitre.org/cve/data_sources_product_coverage.html。这反映了我们关注足额的来源,其中包括Debian, Ubuntu, Red Hat和SUSE。我们有更好的覆盖范围比其他Linux供应商的供应商,特别是在过去的一年。因此,许多老一辈的cve - 2011 - xxxx和cve - 2012 - xxxx来自那些足额的供应商。(注意,我们不考虑OpenSUSE的一部分)“Attachmate的:SUSE”一类,和Fedora是明确提及的部分即使它是由Red Hat)。我们处理RBP待办事项列表如下。日常,CVE内容团队专注于填充保留cf为当前活动引用和创建新的cf必备产品。每当工作完成(或等待耗时的深入分析),我们减少积压的老,reserved-but-public (RBP) cf -关注足额的来源,而且占的部分供应商。尽管vendor-originated警告可能优先,我们也回填其他RBP cf或创建新的non-must-have产品的培训和/或受到初级分析师的关注。澄清的一个点。 You said: > the chances of MITRE deleting these CVE's are less [for these vendor advisories] in our opinion We rarely delete (i.e., "** REJECT **") reserved-but-public CVEs, and in general, we focus much of our attention on issues associated with vendor advisories. I hope this sufficiently explains the situation and how we're handling it. - Steve