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

我们CNA的类似于许多供应商我认为自己的产品问题。我们最初配合提交者是否他们打算或者要求CVE之前提交通知他们,我们将分配一个CVE决议/报告过程中是必需的。我们尽量保持初始CVE阻止请求横切尽可能低和请求更多块应该是必要的。这有助于消除尽可能多的衣架我们可以从“保留但不分配”的类别。我们宁愿把从自己的保留CVE块对于任何问题我们在我们的产品而不是CERT协调或斜接他们的“燃烧”,把空保留IDs我们已经分配。在我的脑海里,一个提交者/仪应该检查与供应商或协调员他们最初使用确定会有一个CVE之前直接分配给横切和请求一个他们自己的。明白并不是所有的供应商都必须,也不是想要,而是一个初始检查至少确认实际需要保留CVE通过横切或CERT艺术是指示。迈克在2014-05-14,09:29 Christey, Steven m .写道:>因为仅仅存在一个CVE ID可以用于协调>即使没有密集的描述和引用,它可能是>用于其他董事会成员参与这个话题……>可能不太明显的是原始的cf数量>保留通过CNAs近年来显著增加>。保留cf * *三倍的数量从2009年到2013年(>基于CVE-YYYY-nnnn id最初预定的数量)。 > This is because of the increased adoption by CNAs, the rise of > oss-security, as well as the increase in private reservations to the > MITRE CNA because of our establishment of the CNA team and the > cve-assign@mitre address in back in 2011. ... I just opened a discussion with Steve about different types of CVE ID request that CERT handles. We generally assign IDs for vulnerability reports that we privately coordinate, however we've been getting requests from vendors and researchers for "just" a CVE ID, and not coordination. Not a lot of requests (I can't measure easily, but ~3/40 for vendor requests in the first part of 2014), but it's to the level we've asked for guidance on when to issue an ID. Overall, our assignment rates have been growing for years. (At times, we have acted as a CNA for other CSIRTs who are now also CNAs). year alloted assigned ==== ======= ======== 2002 12 2 2003 25 18 2004 10 8 2005 30 22 2006 30 28 2007 85 84 2008 45 45 2009 40 40 2010 45 36 2011 125 125 2012 245 233 2013 155 155 2014 90 64 (to date) > Most of those advisories are for vendors that are "partial coverage" > - not full coverage - according to >http://cve.mitre.org/cve/data_sources_product_coverage.html我通常期待一定程度的延迟/松弛/队列时间分配多个CNAs id和斜接/ CVE母舰CNA处理作业,并根据覆盖优先政策。213 RBP IDs *感觉*不像队列/积压太大,特别是如果他们是低优先级的报告。我认为这说明了压力之间保持一定范围的覆盖而漏洞的披露世界的力量正倾向于想要更多的报道。认为,艺术