在剛剛過去的一月份，與往年相同，媒體們又在忙著報導過去一年的漏洞統(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ù)量無端膨脹。

開源就意味著運用數(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è)有兩個相當復(fù)雜的軟件包，有沒有一種方法能夠科學地比較兩者哪個安全性更高？有沒有一種方法能令人信服地衡量系統(tǒng)的安全程度？

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

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。