盡管在 2017 年 9 月的 Equifax 遭受黑客攻擊后引發(fā)了沖擊波，但是業(yè)界在保護(hù)產(chǎn)品方面仍然有很長(zhǎng)的路要走。一個(gè)需要關(guān)注的關(guān)鍵領(lǐng)域是占據(jù)現(xiàn)代應(yīng)用程序整個(gè)代碼庫(kù) 60%-80% 的開源組件。讓我們來了解一下如何檢測(cè)易受攻擊的開源組件并確保產(chǎn)品的安全性。

去年 9 月，當(dāng)圍繞著信用評(píng)級(jí)機(jī)構(gòu) Equifax 被黑客攻擊的新聞流傳開來時(shí)，世界上大部分的人才突然知道開源漏洞這個(gè)概念。攻擊者利用了 Apache Struts2 開源組件的一個(gè)漏洞，竊取了大約 1.479 億人的身份信息，其中大部分是美國(guó)人。

從表面上看，該公司沒有意識(shí)到其 web 應(yīng)用程序中正在使用易受攻擊的開源組件，并且沒有及時(shí)打上補(bǔ)丁以避免受到攻擊。

盡管像 Heartbleed 這樣的黑客攻擊在短時(shí)間內(nèi)吸引了大眾的注意力，但是在本次攻擊中被竊取信息的數(shù)量和質(zhì)量范圍引起了公眾更多的關(guān)注。

這也給組織敲響了一次警鐘，他們有更大的責(zé)任來保護(hù)那些用于保衛(wèi)其用戶數(shù)據(jù)的代碼，即使這些代碼不是他們編寫的也應(yīng)如此。這些代碼通常以開源組件的形式出現(xiàn)，可以免費(fèi)試用，并被開發(fā)者出于及時(shí)向市場(chǎng)交付產(chǎn)品的目而廣泛采用。開發(fā)人員依賴開源組件提供的有用功能，如果不使用開源組件的話，他們就得自己編寫。據(jù)報(bào)道，開源組件的使用在不斷增長(zhǎng)，Gartner 預(yù)計(jì)，在我們知道并喜愛的大多數(shù)產(chǎn)品中開源代碼占據(jù)了 80%。

然而，盡管有這些漏洞，但是開源組件的安全性仍然被太多公司忽視，他們沒有意識(shí)到這種威脅的規(guī)模，甚至沒有意識(shí)到他們真正使用的開源組件的數(shù)量。

缺乏關(guān)注的主要原因之一似乎是，這些組織無視開源漏洞是什么、它們是如何被發(fā)現(xiàn)的以及他們應(yīng)該怎樣保護(hù)自己和客戶。

回到最基本的問題：什么是開源漏洞

開源中的漏洞和專有產(chǎn)品中的漏洞類似。這些代碼要么是編寫出錯(cuò)導(dǎo)致黑客可以加以利用的，要么是允許黑客以開發(fā)人員不希望的方式執(zhí)行有害的操作。

在某些情況下，可以利用開源漏洞發(fā)起拒絕服務(wù)攻擊（denial of service，簡(jiǎn)稱 DoS）并使服務(wù)下線，而其他更嚴(yán)重的漏洞則可能允許黑客進(jìn)行遠(yuǎn)程訪問，讓他們擁有進(jìn)入系統(tǒng)的“鑰匙”。

然而，開源代碼和專有代碼之間的相似之處僅此而已。內(nèi)部代碼是由一組開發(fā)人員遵循其組織集中指導(dǎo)編寫出來的，而開源代碼高度分散于編寫、修復(fù)和維護(hù)項(xiàng)目的社區(qū)成員中。

集中控制系統(tǒng)和分布式系統(tǒng)常常被稱為大教堂（Cathedral）和集市（Bazaar）。開源代碼沒有一個(gè)獨(dú)立組織的中心設(shè)計(jì)來規(guī)劃其邏輯，并且缺乏標(biāo)準(zhǔn)化的系統(tǒng)來解決新特性的添加和修復(fù)事宜，它們遵循的是一個(gè)不同的、通常更松散的規(guī)則集，使得它們更加難以管理。

對(duì)于組織來說，涉足這個(gè)混亂的領(lǐng)域是很復(fù)雜的且難以掌控的，但是對(duì)于黑客們來說，開源代碼缺乏集中控制則是個(gè)福音。很多時(shí)候，開發(fā)人員會(huì)從像 GitHub 等網(wǎng)站上的眾多存儲(chǔ)庫(kù)中獲取源代碼，而不會(huì)去檢查組件是否存在任何已知漏洞。更糟糕的是，很少有人會(huì)在其代碼庫(kù)或產(chǎn)品中跟蹤開源代碼的解決方案。

因此，就像我們?cè)?Equifax 的案例中看到的那樣，他們并不知道他們正在依賴易受攻擊的代碼，而且根本不知道這些漏洞的存在，因此也無法為其打補(bǔ)丁。跟很多開發(fā)代碼的組織一樣，Equifax 可能一直在用某個(gè)工具測(cè)試他們應(yīng)用程序中的代碼，但是，很明顯，他們沒有一個(gè)為分析開源組件而構(gòu)建的工具。

開源代碼的漏洞是怎么找到的？誰在尋找這些漏洞？

靜態(tài)應(yīng)用程序安全測(cè)試（Static Application Security Testing，簡(jiǎn)稱 SAST）或動(dòng)態(tài)應(yīng)用程序安全測(cè)試（Dynamic Application Security Testing，簡(jiǎn)稱 DAST）這樣的安全工具知道如何與專有代碼良好協(xié)作。它們采用組織內(nèi)編寫代碼的邏輯，使用一組像白名單（Whitelist）這樣的規(guī)則來查找代碼中可能被攻擊者入侵的潛在缺陷。

然而，由于開源組件是按照不同的方式搭建的，因此這些工具對(duì)于查找漏洞來說用處不大。相反，我們要依靠大量的研究人員和社區(qū)成員，他們會(huì)花費(fèi)時(shí)間在整個(gè)代碼中查找漏洞。他們沉浸于代碼之中，對(duì)代碼進(jìn)行細(xì)致檢查、嘗試各種可能會(huì)使程序出錯(cuò)的理論、編寫攻擊代碼，目的就是讓應(yīng)用程序失去保護(hù)自己的能力。

盡管他們確實(shí)會(huì)利用一些自動(dòng)化工具去找出代碼中那些容易找到的漏洞，但是，這個(gè)測(cè)試過程是一項(xiàng)漫長(zhǎng)而艱巨的任務(wù)。據(jù)估計(jì)，研究人員可能平均要花 3 個(gè)月的時(shí)間才能找到一個(gè)漏洞。

從本質(zhì)上講，開源軟件是個(gè)活生生的、有生命力的實(shí)體，由一群開發(fā)人員維護(hù)，他們貢獻(xiàn)自己的時(shí)間以構(gòu)建更好的項(xiàng)目。為了使項(xiàng)目更加健壯，很多社區(qū)成員自己花時(shí)間來尋找漏洞，當(dāng)他們發(fā)現(xiàn)可能被對(duì)社會(huì)不滿者、罪犯甚至在有些情況下是國(guó)家行為者利用的代碼時(shí)，會(huì)提醒項(xiàng)目管理人員。很多這樣的研究人員出于對(duì)開源代碼的熱愛和尊敬，為了幫助代碼更安全做出了自己的貢獻(xiàn)。

然后，那些賞金獵人（用了最好聽的方式來稱呼他們）為了那些冷冰冰的現(xiàn)金獎(jiǎng)勵(lì)而尋找漏洞。最近幾年，一個(gè)迷你行業(yè)正在興起，幫助黑客們改邪歸正，允許他們利用自己邪惡的本領(lǐng)來做好事。很多像微軟這樣的大型組織已經(jīng)為白帽黑客設(shè)立了漏洞賞金計(jì)劃，以用于報(bào)告漏洞并獲得報(bào)酬。

HackerOne 和 Bugcrowd 是為各家公司甚至美國(guó)政府運(yùn)營(yíng)這些漏洞賞金計(jì)劃的兩大巨頭。為了避免錯(cuò)失其中的樂趣，在開源社區(qū)里也有一些 bug 賞金倡議，它們得到了一些主要參與者的支持。

早在 2014 年，Linux 基金會(huì)（Linux Foundation）為了應(yīng)對(duì) Heartbleed 漏洞而建立核心基礎(chǔ)架構(gòu)聯(lián)盟（Core Infrastructure Initiative）計(jì)劃。他們成功地引進(jìn)了微軟、英特爾、谷歌、IBM、亞馬遜、VMware 和許多其他的行業(yè)領(lǐng)導(dǎo)者，募集了 3 百多萬美元賞金。另一個(gè)眾所周知的開源計(jì)劃是非營(yíng)利性 bug 懸賞項(xiàng)目（Internet Bug Bounty，簡(jiǎn)稱 IBB）倡議，獲得了臉書、福特基金會(huì)（Ford Foundation）以及最重要的 GitHub 的支持，每一家都提供了 10 萬美元以支付研究人員。

暴露開源漏洞之后的響應(yīng)

當(dāng)研究人員最終在項(xiàng)目中發(fā)現(xiàn)漏洞時(shí)，會(huì)通知相關(guān)各方以啟動(dòng)一系列操作。

研究人員首先要做的是，把他們的發(fā)現(xiàn)發(fā)送給受美國(guó)政府支持的非營(yíng)利 MITRE 公司，該公司是維護(hù)通用漏洞披露平臺(tái)（Common Vulnerabilities and Exposures，簡(jiǎn)稱 CVE）漏洞注冊(cè)的機(jī)構(gòu)。然后，MITRE 的工作人員將分析漏洞以確認(rèn)，并提供關(guān)于漏洞的信息。這通常包括嚴(yán)重性評(píng)級(jí)，漏洞如何被利用的細(xì)節(jié)，最好還要有到修補(bǔ)程序的鏈接以便于修復(fù)該漏洞。在這個(gè)階段，漏洞會(huì)得到一個(gè) ID。其中包括被報(bào)告的年份和唯一的 ID 號(hào)碼。比如，用于攻擊 Equifax 的 Apache Struts2 漏洞被標(biāo)識(shí)為 CVE-2017-5638。

MITRE 維護(hù)的 CVE 系統(tǒng)的組織化程度還遠(yuǎn)遠(yuǎn)不夠，因此，漏洞信息會(huì)在國(guó)家漏洞數(shù)據(jù)庫(kù)（National Vulnerability Database，簡(jiǎn)稱 NVD）上列出，該數(shù)據(jù)庫(kù)是一個(gè)很好的目錄。

與此同時(shí)，研究人員還將聯(lián)絡(luò)開源組件的項(xiàng)目管理人員，通知他們有問題要處理。在正常情況下，根據(jù)公平競(jìng)爭(zhēng)原則，研究人員在把他們的發(fā)現(xiàn)公布于眾之前，會(huì)給項(xiàng)目管理人員大概 60 到 90 天的時(shí)間以找出漏洞的修復(fù)方案。幸運(yùn)的話，項(xiàng)目管理人員會(huì)在截止時(shí)間前提出解決方案。

在 CVE 公布于眾后，所有人都能獲得該信息，其成為已知漏洞。這其中包括好人，他們會(huì)利用該信息為自己的應(yīng)用程序打補(bǔ)丁，而那些得到免費(fèi)信息的壞人，則能利用該信息攻擊那些打補(bǔ)丁很慢的公司。

正因?yàn)槿绱?，已知漏洞是開源組件的主要威脅。既然大量漏洞的詳細(xì)信息在 NVD 上免費(fèi)列出，黑客們?yōu)槭裁催€要浪費(fèi)時(shí)間自己去找漏洞呢？

保護(hù)你的開源組件

正如我們?cè)谶@里看到的那樣，當(dāng)涉及開源代碼時(shí)，安全團(tuán)隊(duì)面臨的挑戰(zhàn)就不是自己在代碼里面找出漏洞，而是在已知漏洞變得可用時(shí)，他們得做好準(zhǔn)備。

要保持這些開源組件的安全，有兩件事需要解決。

第一件要解決的事情就是需要掌握在代碼庫(kù)和產(chǎn)品中所使用的開源組件是否包含現(xiàn)有漏洞。如果你的開發(fā)人員還沒有使用工具去跟蹤他們擁有的組件以及那些組件的安全狀態(tài)，那么他們可能會(huì)發(fā)現(xiàn)自己跟 Equifax 一樣，處于缺乏關(guān)鍵可見性信息的境地。

除此之外，盡管我們可以修復(fù)脆弱的“必備”的組件中的問題，開發(fā)人員還是應(yīng)該避免在構(gòu)建新產(chǎn)品時(shí)，使用那些有已知漏洞的組件。這意味著，在把開源組件加入到你的代碼庫(kù)或產(chǎn)品中前，要利用可以檢測(cè)脆弱組件的解決方案，甚至可以利用自動(dòng)化策略，如果開發(fā)人員試圖提交一段有風(fēng)險(xiǎn)的代碼時(shí)，該策略就讓構(gòu)建失敗。

保證產(chǎn)品和產(chǎn)品中內(nèi)含數(shù)據(jù)的安全，已經(jīng)成為客戶的期望，因此需要應(yīng)用正確的工具以在黑客們攻擊之前就能找到含有已知漏洞的組件。

由于大量的開源組件在業(yè)界廣泛使用，開發(fā)人員和安全團(tuán)隊(duì)需要采用自動(dòng)化的解決方案來跟蹤所有在他們的代碼庫(kù)和產(chǎn)品中用到的開源組件，同時(shí)監(jiān)控像 NVD 這樣的漏洞數(shù)據(jù)庫(kù)以在研究人員發(fā)現(xiàn)新的漏洞時(shí)接收到警報(bào)。

像 WhiteSource 和 Flexera 這樣的軟件組件分析（Software Composition Analysis，簡(jiǎn)稱 SCA）工具正是為此目的而設(shè)計(jì)的，也是應(yīng)用程序安全策略的重要組成部分，通過這種方式，我們就能趕在黑客的前面，這樣的話才能維護(hù)客戶信任同時(shí)保持產(chǎn)品的安全。未能實(shí)施 SCA 工具會(huì)讓組織面臨攻擊，老實(shí)說，沒人想成為下一個(gè) Equifax。