回复：CVE ID语法投票 - 结果和下一步

------开始PGP签名消息----- Hash：2013-04-18 12:43，安全性Curmudgeon写道：> McAfee或任何因“未来>校对）投票为'B'的人``关注点，请解决有关如何荒谬的重复评论？>>如果您错过了史蒂夫·克里斯蒂（Steve Christey）的CVE投票电子邮件：>>应该指出的是，团队认为任何情况（S）>都需要（平均）（平均）超过2,700 CVE IDS>每天（999,999）（999,999）IDS每年）将反映CVE ID的含义和使用方面的基本变化。换句话说，要求发布2700多个ID的“ CVE”>不会是今天的CVE>。>>正如RBS的Carsten Eiram所指出的：>> 1）脆弱性报告和覆盖范围中纯粹的理论爆炸（请记住，MITER当前存在难以保持现有趋势，并且不保证所有漏洞>将分配所有漏洞CVE）。每年报告的8k-10k漏洞的变化到100万是不现实的。即使有人开始使用自动代码>扫描工具来审核大量项目，并且没有任何手动后续分析，只需转储>在某些邮件列表上的结果，我们还是很难>>耗尽6位数字。我们将长时间讨论资源问题>在击中这些数字之前，因为CVE和任何CVE处理器都无法跟上这样的负载。我没有预测CVE的范围和抽象水平的重大变化，这将直接导致每年100万ID。 My initial thought was therefore to vote for A. What caused me to reconsider was the idea of more and more active CNAs. Now, MITRE is careful to hand out modest allocations of IDs, generally sequentially, to dozens(?) of CNAs. I don't think there's much waste. What I wanted to future-proof is the world with more CNAs (100s?) with more assignment authority (like a modulo slice or big sequential block of the year's CVE ID space). In this world, there still may still not be more than 1M CVE IDs published per year, but there may be more than 1M CVE IDs allocated to CNAs. Allocation != publication. Now, I don't see any strong indicators of this particular new world. But it seemed reasonable enough to want to plan in advance for. Another future scale issue: Automated ways to find vulnerabilities could overwhelm the current 10K/year human-scale size of the problem. - Art -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird -http://www.enigmail.net/ieyearecaayfalfwqkuacgkqk/8fedbcakmquqcfapzsbyrzrzrzrgjhkefa6yy9dl1m r8aamgkw5yudqx4qcghgkzqdk+f9uwzv = lq+f-------------