在刚刚过去的一月份，与往年相同，媒体们又在忙着报导过去一年的漏洞统计。同样，CVE Details的小伙伴们也精心准备了基于CVE（Common Vulnerabilities & Exposures，公共漏洞和暴露）统计的大把夸张数据。媒体朋友们也照例频频赏光咬饵，发布的都是诸如“安卓当选2016漏洞之王”一类吸引眼球的头条。
尽管这些头条可能每年都会让热衷此类话题的人觉得有趣，但安全研究者Craig Young却认为，在这种表象之下很少被提及的一点是：
这些统计数字几乎毫无意义，也没能就不同产品间的安全性做出任何比较。
下面这篇文章将解释他这样说的原因。同时，作者也鼓励有兴趣了解更多的人去观看Steve Cristey和Brian Martin在2013年Black Hat大会上的讲话“Buying into the Bias: Why Vulnerability Statistics Suck”（点击观看）
数据来源有限的CVE统计我们可以这样认为：漏洞统计为产品安全提供了最直观的指示。但同时我们也应该意识到：从来就没有，将来也不会存在一个真正意义上既综合又完整的安全漏洞索引。CVE或其他漏洞数据库只能记录他们所知的漏洞，通常这些资料来自于厂商报告或由安全研究者提交。
遗憾的是，许多安全研究者往往并不会把他们发现的漏洞一个不剩地提交；厂商对于将漏洞公之于众这种事也是习惯能躲就躲。（这种做法在学界有个称呼：Publicatioin Bias——发表偏倚）。而那些未被发现的漏洞，和已确认但易受黑客恶意攻击的漏洞，在公布之前都不会被列入任何漏洞统计。这导致了某些厂商和软件的漏洞统计数量虚高，这些厂商通常更愿意披露软件的漏洞细节——比如说谷歌和Android。
同时，当一个漏洞影响产品数量众多时，CVE——尤其是CVE Details——对于漏洞的统计实际上不够科学。之所以这么说，与一条CVE究竟如何命名，以及MITRE和CVE Details所掌握的有限资源是相关的。比如，不同产品可能会共享组件或代码库，但是CVE Details却并不总是能把一个漏洞关联到使用了问题代码的全部产品上。
就拿WebKit来说，我们经常会发现在审查Chrome时发现的漏洞（当Chrome还在使用Webkit时）也会影响到Safari浏览器，CVE Details很少会把这样的漏洞条目也关联到Safari上。比如说CVE-2013-0912（点击查看）——苹果提供的报告已经关联到该CVE条目，但CVE Details却并没有把这个CVE绑定到任何版本的Safari上。这样一来，2013年Chrome漏洞统计数上去了一个， Safari漏洞统计数却差了一个。
再举个例子：有些东西，像OpenSSL和Linux内核使用得非常广泛，一旦这两者存在漏洞，则波及的产品也将非常广泛——但实际情况是要将所有受影响的产品列举出来是不现实的。那么现实又是如何呢？目前的做法一般是把上报的漏洞跟最先发现存在此漏洞的产品关联起来。
忙不过来的MITRECVE的另一个问题在近几年尤为突出：MITRE有些处理不过来海量的漏洞提交——详情可回顾CVE命名申请遭大量延误（点击查看）和CVE-assign邮件地址的最终停用（）。而且要让CVE条目最终公布，必须满足某些条件，比如你得提交相关报告的URL或者发布关于此漏洞的博客文章。
针对不同漏洞报告，MITRE花费的反应时间也各不相同。有些几小时内就会处理好，有些则要花上几周甚至几个月——前提是MITRE理你的话。而且他们针对不同漏洞投入的时间，似乎与漏洞严重程度或软件流行程度也没什么关系。笔者曾在2015年末提交过一票CVE漏洞，但由于积卷如山，这些漏洞没有得到任何反馈。而且笔者提交的CVE条目，有上百个从未被MITRE公布——厂商还没有公开承认这些漏洞，笔者表示也没有时间把每一条漏洞都在博客里详细阐明。
这些因素加在一起构成了对处理安全问题认真负责的厂商的抽样偏差，也导致那些开源和有漏洞奖励计划的产品，在CVE-Details中的漏洞数量无端膨胀。
中枪的Android