[[日期上一篇] [下一个日期] [线程] [线程接下来] [日期索引] [线程索引这是给予的

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



在2013年4月18日星期四,kent_landfield@mcafee.com写道::谢谢您的评论,因为我认为它是现实的。我也想更多:扩展的选项A是合理的选择。我之前已经说过:麦卡菲(McAfee)认为6位数字太短了未来的证明,如果延长到7或更多,我们可能会改变投票。我看到问题:对于选项B,但未来的证明确实是我们的决定的驱动因素。我想第二次Harold的请求重新考虑选项A:长度。McAfee或因“未来证明”的关注而投票赞成“ B”的任何人都可以解决有关如何荒谬的重复评论吗?如果您在史蒂夫·克里斯蒂(Steve Christey)的CVE投票电子邮件中错过了它,则应注意,团队认为,任何情况都需要(平均每天)发行2,700个CVE ID(每年999,999 IDS)(每年99999个IDS)CVE ID的含义和使用的根本变化。换句话说,要求发布2700多个ID的“ CVE”将不是当今的CVE。正如RBS的Carsten Eiram所指出的那样:1)脆弱性报告和覆盖范围中纯粹的理论爆炸(请记住,Miter当前难以跟上现有趋势,并且不保证所有漏洞将分配CVE)。 A change from 8K-10K vulnerabilities reported per year to > 1 million is simply unrealistic. Even if someone starts auditing a ton of projects with automated code scanning tools and without any manual follow-up analysis just dumps the results on some mailing list, we would be hard-pressed to exhaust 6 digits. We would be discussing resource problems long before hitting those numbers, as neither CVE nor any CVE processors will be able to keep up with such a load. So I politely request that anyone voting against 'A' and cited this concern please discuss it first. I can't understand how this is a real concern, especially in conjunction with several companies that basically said "option B is much easier on our current system, we will have to change less" which seems exceedingly selfish, and not in the interest of the community so much as the interest of your specific company. Thank you, Brian

页面最后更新或审查:2014年10月3日