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

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



2013年4月18日,星期四,安全库司登(Curmudgeon)写道:>这是一个公平的观点。除了整体过程外,我对CNA的运行方式不太了解。我当然希望没有获得大型池>,除非他们证明自己需要它。这样的演示仅在实际发布许多有效的CVE时才有效,并在同年>同年请求更多。就是这样。为每个CNA提供一个大小的池,该池与它们发布的CVE数量成正比。在此阶段,我们可能有4或5个CNA,一次可以一次要求100多个CVE,而不会引起太多关注。其他CNA可能只能获得5或10。没有人在一年内没有大量披露而成为CNA。在我看来,尽管我没有统计数据,但CNA池的平均大小正在上升。>在14年内,我们有一个非频率CNA发出大量标识符的示例,而Redhat则是kurt seif。 > Even with the *incredible* amount of hours he spends on it, he too has > said "I can't keep up in some situations". This is no insult to him by any > means, it is a basic truth. > I do not blame either one, but it illustrates the current model of CVE, > and illustrates the problem with manpower and identifier assignment. Accordingly, in the future, there may be a need to change that model. The sources-and-products discussion of last year started to at least define a starting point. We have deferred other discussions (e.g. quality vs. quantity). >: Another future scale issue: Automated ways to find vulnerabilities >: could overwhelm the current 10K/year human-scale size of the problem. > >That is the primary example Carsten Eiram and I offer. A system where an >automated code analysis tool can essentially auto-assign a CVE for each >one found. We know the current state of this would mean an incredible >number of false positives, so I can't see anyone arguing that CVE should >ever move away from some level of manual review for assignment. Even ignoring automated assignment, consider efforts like what j00ru and Gynvael Coldwind are doing with ffmpeg, or Adam Gowdiak with Java, what r0t did in 2005/2006, or what Dimitry Oboukhov person did in 2008 when he grepped for /tmp vulns in all the Debian packages about 5 years ago. These days, individual researchers can produce many more valid vuln reports than 10 years ago, and we have many more researchers today. - Steve

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