在刚刚过去的一月份，与往年相同，媒体们又在忙着报导过去一年的漏洞统计。同样，CVE Details的小伙伴们也精心准备了基于CVE（Common Vulnerabilities & Exposures，公共漏洞和暴露）统计的大把夸张数据。
根据汇总CVE数据的网站出具的2016年度CVE Details报告显示，Andriod系统以523个漏洞位居产品漏洞数量榜首，成为名符其实的第一名。而Adobe也持续作为头号种子，以1,383个漏洞继续位列软件供应商的第一名。
虽说只有上传到Mitre’s Common Vulnerabilities和Exposures (CVE)数据库的漏洞才会被记入这次统计，但从2016年上传漏洞总数高达10,098的情况来看，此次统计还是具有一定说服力的。Android系统惊人的523个漏洞差不多是榜单第四名Adobe Flash 266个漏洞的两倍。
媒体朋友们也照例频频赏光咬饵，发布的都是诸如“安卓当选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——尤其是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内核使用得非常广泛，一旦这两者存在漏洞，则波及的产品也将非常广泛——但实际情况是要将所有受影响的产品列举出来是不现实的。那么现实又是如何呢？目前的做法一般是把上报的漏洞跟最先发现存在此漏洞的产品关联起来。
忙不过来的MITRE
CVE的另一个问题在近几年尤为突出：MITRE有些处理不过来海量的漏洞提交——详情可回顾CVE命名申请遭大量延误（点击查看）和CVE-assign邮件地址的最终停用（点击查看）。而且要让CVE条目最终公布，必须满足某些条件，比如你得提交相关报告的URL或者发布关于此漏洞的博客文章。
针对不同漏洞报告，MITRE花费的反应时间也各不相同。有些几小时内就会处理好，有些则要花上几周甚至几个月——前提是MITRE理你的话。而且他们针对不同漏洞投入的时间，似乎与漏洞严重程度或软件流行程度也没什么关系。笔者曾在2015年末提交过一票CVE漏洞，但由于积卷如山，这些漏洞没有得到任何反馈。而且笔者提交的CVE条目，有上百个从未被MITRE公布——厂商还没有公开承认这些漏洞，笔者表示也没有时间把每一条漏洞都在博客里详细阐明。
这些因素加在一起构成了对处理安全问题认真负责的厂商的抽样偏差，也导致那些开源和有漏洞奖励计划的产品，在CVE-Details中的漏洞数量无端膨胀。
中枪的Android
开源就意味着运用数据分析和Fuzzing工具（如American Fuzzy Lop）审查安全漏洞变得格外简单。（这就要谈到选择偏见了，安全工作者更倾向于研究开源软件或具有金钱激励的产品）这使得开源软件天生就在安全问题上显得更加透明，因为更改代码通常是有据可查的，而且研究者也没有那么多的法律顾虑。
Bug赏金也扮演着重要角色，不仅是因为这使得研究者有仔细检查产品，挖掘更多漏洞的动机，也是因为通用平台上存在的漏洞往往会与第一个曝出此问题的产品关联起来。
这些因素加起来，使得大众可能对像Android这样一个开源，拥有bug赏金项目的系统产生了极度不靠谱的印象。此外，由于Android开源的本质，有许多手机厂商生产了各种定制程序来支持某些特定硬件或提供某些全新功能。这些程序甚至都不一定包含在安卓官方的开源计划中，但其中的漏洞却仍然被算到CVE Details里Android系统的统计数据中去。
举个例子，三星Galaxy系列智能手机曾被曝出自家代码的一系列漏洞，这些漏洞最终都被归结为Android系统的问题。但事实上它们除了Galaxy手机之外没有影响到任何安卓设备。与此类似，有些Android系统中同样可被利用的Linux内核漏洞（如CVE-2016-7917），也被CVE Details归类到Linux内核问题而不是Android或其他任何Linux问题。
思考
作者在文末列举了他认为更值得关注的问题：假设有两个相当复杂的软件包，有没有一种方法能够科学地比较两者哪个安全性更高？有没有一种方法能令人信服地衡量系统的安全程度？
作者认为，这个问题实际上相当复杂，他本人也没有答案——信息安全通常被看做是计算机科学的一个分支，但信息安全在实操中缺少基本的科学论证方法。
转载自：FreeBuf.COM
