在剛剛過去的一月份，與往年相同，媒體們又在忙著報導過去一年的漏洞統(tǒng)計。同樣，CVE Details的小伙伴們也精心準備了基于CVE(Common Vulnerabilities & Exposures，公共漏洞和暴露)統(tǒng)計的大把夸張數(shù)據(jù)。媒體朋友們也照例頻頻賞光咬餌，發(fā)布的都是諸如“安卓當選2016漏洞之王”一類吸引眼球的頭條。(看著眼熟?)

盡管這些頭條可能每年都會讓熱衷此類話題的人覺得有趣，但安全研究者Craig Young卻認為，在這種表象之下很少被提及的一點是：

這些統(tǒng)計數(shù)字幾乎毫無意義，也沒能就不同產(chǎn)品間的安全性做出任何比較。

下面這篇文章將解釋他這樣說的原因。同時，作者也鼓勵有興趣了解更多的人去觀看Steve Cristey和Brian Martin在2013年Black Hat大會上的講話“Buying into the Bias: Why Vulnerability Statistics Suck”(點擊觀看)

數(shù)據(jù)來源有限的CVE統(tǒng)計

我們可以這樣認為：漏洞統(tǒng)計為產(chǎn)品安全提供了最直觀的指示。但同時我們也應(yīng)該意識到：從來就沒有，將來也不會存在一個真正意義上既綜合又完整的安全漏洞索引。CVE或其他漏洞數(shù)據(jù)庫只能記錄他們所知的漏洞，通常這些資料來自于廠商報告或由安全研究者提交。

遺憾的是，許多安全研究者往往并不會把他們發(fā)現(xiàn)的漏洞一個不剩地提交;廠商對于將漏洞公之于眾這種事也是習慣能躲就躲。(這種做法在學界有個稱呼：Publicatioin Bias——發(fā)表偏倚)。而那些未被發(fā)現(xiàn)的漏洞，和已確認但易受黑客惡意攻擊的漏洞，在公布之前都不會被列入任何漏洞統(tǒng)計。這導致了某些廠商和軟件的漏洞統(tǒng)計數(shù)量虛高，這些廠商通常更愿意披露軟件的漏洞細節(jié)——比如說谷歌和Android。

當CVE涉及產(chǎn)品面過寬時

同時，當一個漏洞影響產(chǎn)品數(shù)量眾多時，CVE——尤其是CVE Details——對于漏洞的統(tǒng)計實際上不夠科學。之所以這么說，與一條CVE究竟如何命名，以及MITRE和CVE Details所掌握的有限資源是相關(guān)的。比如，不同產(chǎn)品可能會共享組件或代碼庫，但是CVE Details卻并不總是能把一個漏洞關(guān)聯(lián)到使用了問題代碼的全部產(chǎn)品上。

就拿WebKit來說，我們經(jīng)常會發(fā)現(xiàn)在審查Chrome時發(fā)現(xiàn)的漏洞(當Chrome還在使用Webkit時)也會影響到Safari瀏覽器，CVE Details很少會把這樣的漏洞條目也關(guān)聯(lián)到Safari上。比如說CVE-2013-0912(點擊查看)——蘋果提供的報告已經(jīng)關(guān)聯(lián)到該CVE條目，但CVE Details卻并沒有把這個CVE綁定到任何版本的Safari上。這樣一來，2013年Chrome漏洞統(tǒng)計數(shù)上去了一個， Safari漏洞統(tǒng)計數(shù)卻差了一個。

再舉個例子：有些東西，像OpenSSL和Linux內(nèi)核使用得非常廣泛，一旦這兩者存在漏洞，則波及的產(chǎn)品也將非常廣泛——但實際情況是要將所有受影響的產(chǎn)品列舉出來是不現(xiàn)實的。那么現(xiàn)實又是如何呢?目前的做法一般是把上報的漏洞跟最先發(fā)現(xiàn)存在此漏洞的產(chǎn)品關(guān)聯(lián)起來。

忙不過來的MITRE

CVE的另一個問題在近幾年尤為突出：MITRE有些處理不過來海量的漏洞提交——詳情可回顧CVE命名申請遭大量延誤(點擊查看)和CVE-assign郵件地址的最終停用(點擊查看)。而且要讓CVE條目最終公布，必須滿足某些條件，比如你得提交相關(guān)報告的URL或者發(fā)布關(guān)于此漏洞的博客文章。

針對不同漏洞報告，MITRE花費的反應(yīng)時間也各不相同。有些幾小時內(nèi)就會處理好，有些則要花上幾周甚至幾個月——前提是MITRE理你的話。而且他們針對不同漏洞投入的時間，似乎與漏洞嚴重程度或軟件流行程度也沒什么關(guān)系。筆者曾在2015年末提交過一票CVE漏洞，但由于積卷如山，這些漏洞沒有得到任何反饋。而且筆者提交的CVE條目，有上百個從未被MITRE公布——廠商還沒有公開承認這些漏洞，筆者表示也沒有時間把每一條漏洞都在博客里詳細闡明。

這些因素加在一起構(gòu)成了對處理安全問題認真負責的廠商的抽樣偏差，也導致那些開源和有漏洞獎勵計劃的產(chǎn)品，在CVE-Details中的漏洞數(shù)量無端膨脹。

中槍的Android

開源就意味著運用數(shù)據(jù)分析和Fuzzing工具(如American Fuzzy Lop)審查安全漏洞變得格外簡單。(這就要談到選擇偏見了，安全工作者更傾向于研究開源軟件或具有金錢激勵的產(chǎn)品)這使得開源軟件天生就在安全問題上顯得更加透明，因為更改代碼通常是有據(jù)可查的，而且研究者也沒有那么多的法律顧慮。

Bug賞金也扮演著重要角色，不僅是因為這使得研究者有仔細檢查產(chǎn)品，挖掘更多漏洞的動機，也是因為通用平臺上存在的漏洞往往會與第一個曝出此問題的產(chǎn)品關(guān)聯(lián)起來。

這些因素加起來，使得大眾可能對像Android這樣一個開源，擁有bug賞金項目的系統(tǒng)產(chǎn)生了極度不靠譜的印象。此外，由于Android開源的本質(zhì)，有許多手機廠商生產(chǎn)了各種定制程序來支持某些特定硬件或提供某些全新功能。這些程序甚至都不一定包含在安卓官方的開源計劃中，但其中的漏洞卻仍然被算到CVE Details里Android系統(tǒng)的統(tǒng)計數(shù)據(jù)中去。

舉個例子，三星Galaxy系列智能手機曾被曝出自家代碼的一系列漏洞，這些漏洞最終都被歸結(jié)為Android系統(tǒng)的問題。但事實上它們除了Galaxy手機之外沒有影響到任何安卓設(shè)備。與此類似，有些Android系統(tǒng)中同樣可被利用的Linux內(nèi)核漏洞(如CVE-2016-7917)，也被CVE Details歸類到Linux內(nèi)核問題而不是Android或其他任何Linux問題。

思考

作者在文末列舉了他認為更值得關(guān)注的問題：假設(shè)有兩個相當復雜的軟件包，有沒有一種方法能夠科學地比較兩者哪個安全性更高?有沒有一種方法能令人信服地衡量系統(tǒng)的安全程度?

作者認為，這個問題實際上相當復雜，他本人也沒有答案——信息安全通常被看做是計算機科學的一個分支，但信息安全在實操中缺少基本的科學論證方法。