再保险:什么是未来的CVE -范围、体积和质量呢?

今天阅读邮件向后……曼,2011-09-19 14:46戴夫写道:>让我强调,我们同意这两个问题。资源的讨论和分析过程是至关重要的事情对我们讨论在我们考虑CVE的未来。> >但直到我们可以达成一致的必备物品,我们不能在这些方面取得进展。> >我们强烈建议这些2最重要的第一个问题:> > 1。来源>。它的脆弱性来源披露应考虑>“必备”,我们提供“参考完整”的报道吗?> b。来源应该被认为是“值得拥有”吗?> c。来源应该被认为是“可以安全地忽略”>(例如,他们只是导致噪音)?> > 2。覆盖>。这供应商和软件产品我们应该考虑“必备”>,我们将为他们提供覆盖所有可靠的脆弱性>报告吗? > b. Which products or vendors should be considered "nice-to-haves"? > c. Which ones should be considered "can be safely ignored" (e.g. php.golf)? These are the same question, or 1. depends on 2. IOW, if we know what vendors/products we want to cover, then we can figure out which sources to monitor. golf.php gets posted in bugtraq, as does a remote code execution bug in IIS. US-CERT Alerts, as of the last several years, are mostly republication of Microsoft, Oracle, Apple, and Adobe vulnerabilities. "Reference complete" would be great, but perhaps not worth the investment. OSVDB seems to be aiming for this. What about: 1. big/core vendors/apps 2. anything a CNA assigns an ID for 3. everything else Make 1 and 2 priorities (IOW, resource to meet 1 and 2). CNAs should be expected to pony up some resources to assign and de-duplicate IDs. Need to define 1, which is at least started in the list you sent out. Leave 3 for a slow week, or really just ignore it, unless somebody cares, in which case it should rise to the level of 2 when a CNA assigns and ID for it. And make it clear to CVE users that CVE is *not* reference complete, and not trying to be. Make it clear that the count of CVE IDs per year is at best a lower bound on the number of public vul reports that year. Maybe another way to look at this is to decouple most of the analysis from the assignment work. Yes, correct assignment requires at least enough analysis to distinguish separate or related vul reports. Make further analysis an add-on service, "CVE+analysis" or something. - Art