使用了很多開源軟體，但你知道怎麼處理對應的漏洞嗎？

作者｜Rami Sass

編輯｜姚佳靈

儘管在 2017 年 9 月的 Equifax 遭受黑客攻擊後引發了衝擊波，但是業界在保護產品方面仍然有很長的路要走。一個需要關注的關鍵領域是佔據現代應用程序整個代碼庫 60%-80% 的開源組件。讓我們來了解一下如何檢測易受攻擊的開源組件並確保產品的安全性。

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

從表面上看，該公司沒有意識到其 web 應用程序中正在使用易受攻擊的開源組件，並且沒有及時打上補丁以避免受到攻擊。

儘管像 Heartbleed 這樣的黑客攻擊在短時間內吸引了大眾的注意力，但是在本次攻擊中被竊取信息的數量和質量範圍引起了公眾更多的關注。

這也給組織敲響了一次警鐘，他們有更大的責任來保護那些用於保衛其用戶數據的代碼，即使這些代碼不是他們編寫的也應如此。這些代碼通常以開源組件的形式出現，可以免費試用，並被開發者出於及時向市場交付產品的目而廣泛採用。開發人員依賴開源組件提供的有用功能，如果不使用開源組件的話，他們就得自己編寫。據報道，開源組件的使用在不斷增長，Gartner 預計，在我們知道並喜愛的大多數產品中開源代碼佔據了 80%。

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

缺乏關注的主要原因之一似乎是，這些組織無視開源漏洞是什麼、它們是如何被發現的以及他們應該怎樣保護自己和客戶。

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

開源中的漏洞和專有產品中的漏洞類似。這些代碼要麼是編寫出錯導致黑客可以加以利用的，要麼是允許黑客以開發人員不希望的方式執行有害的操作。

在某些情況下，可以利用開源漏洞發起拒絕服務攻擊（denial of service，簡稱 DoS）並使服務下線，而其他更嚴重的漏洞則可能允許黑客進行遠程訪問，讓他們擁有進入系統的「鑰匙」。

然而，開源代碼和專有代碼之間的相似之處僅此而已。內部代碼是由一組開發人員遵循其組織集中指導編寫出來的，而開源代碼高度分散於編寫、修復和維護項目的社區成員中。

集中控制系統和分散式系統常常被稱為大教堂（Cathedral）和集市（Bazaar）。開源代碼沒有一個獨立組織的中心設計來規劃其邏輯，並且缺乏標準化的系統來解決新特性的添加和修復事宜，它們遵循的是一個不同的、通常更鬆散的規則集，使得它們更加難以管理。

對於組織來說，涉足這個混亂的領域是很複雜的且難以掌控的，但是對於黑客們來說，開源代碼缺乏集中控制則是個福音。很多時候，開發人員會從像 GitHub 等網站上的眾多存儲庫中獲取源代碼，而不會去檢查組件是否存在任何已知漏洞。更糟糕的是，很少有人會在其代碼庫或產品中跟蹤開源代碼的解決方案。

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

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

靜態應用程序安全測試（Static Application Security Testing，簡稱 SAST）或動態應用程序安全測試（Dynamic Application Security Testing，簡稱 DAST）這樣的安全工具知道如何與專有代碼良好協作。它們採用組織內編寫代碼的邏輯，使用一組像白名單（Whitelist）這樣的規則來查找代碼中可能被攻擊者入侵的潛在缺陷。

然而，由於開源組件是按照不同的方式搭建的，因此這些工具對於查找漏洞來說用處不大。相反，我們要依靠大量的研究人員和社區成員，他們會花費時間在整個代碼中查找漏洞。他們沉浸於代碼之中，對代碼進行細緻檢查、嘗試各種可能會使程序出錯的理論、編寫攻擊代碼，目的就是讓應用程序失去保護自己的能力。

儘管他們確實會利用一些自動化工具去找出代碼中那些容易找到的漏洞，但是，這個測試過程是一項漫長而艱巨的任務。據估計，研究人員可能平均要花 3 個月的時間才能找到一個漏洞。

從本質上講，開源軟體是個活生生的、有生命力的實體，由一群開發人員維護，他們貢獻自己的時間以構建更好的項目。為了使項目更加健壯，很多社區成員自己花時間來尋找漏洞，當他們發現可能被對社會不滿者、罪犯甚至在有些情況下是國家行為者利用的代碼時，會提醒項目管理人員。很多這樣的研究人員出於對開源代碼的熱愛和尊敬，為了幫助代碼更安全做出了自己的貢獻。

然後，那些賞金獵人（用了最好聽的方式來稱呼他們）為了那些冷冰冰的現金獎勵而尋找漏洞。最近幾年，一個迷你行業正在興起，幫助黑客們改邪歸正，允許他們利用自己邪惡的本領來做好事。很多像微軟這樣的大型組織已經為白帽黑客設立了漏洞賞金計劃，以用於報告漏洞並獲得報酬。

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

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

暴露開源漏洞之後的響應

當研究人員最終在項目中發現漏洞時，會通知相關各方以啟動一系列操作。

研究人員首先要做的是，把他們的發現發送給受美國政府支持的非營利 MITRE 公司，該公司是維護通用漏洞披露平台（Common Vulnerabilities and Exposures，簡稱 CVE）漏洞註冊的機構。然後，MITRE 的工作人員將分析漏洞以確認，並提供關於漏洞的信息。這通常包括嚴重性評級，漏洞如何被利用的細節，最好還要有到修補程序的鏈接以便於修復該漏洞。在這個階段，漏洞會得到一個 ID。其中包括被報告的年份和唯一的 ID 號碼。比如，用於攻擊 Equifax 的 Apache Struts2 漏洞被標識為 CVE-2017-5638。

MITRE 維護的 CVE 系統的組織化程度還遠遠不夠，因此，漏洞信息會在國家漏洞資料庫（National Vulnerability Database，簡稱 NVD）上列出，該資料庫是一個很好的目錄。

與此同時，研究人員還將聯絡開源組件的項目管理人員，通知他們有問題要處理。在正常情況下，根據公平競爭原則，研究人員在把他們的發現公佈於眾之前，會給項目管理人員大概 60 到 90 天的時間以找出漏洞的修復方案。幸運的話，項目管理人員會在截止時間前提出解決方案。

在 CVE 公佈於眾後，所有人都能獲得該信息，其成為已知漏洞。這其中包括好人，他們會利用該信息為自己的應用程序打補丁，而那些得到免費信息的壞人，則能利用該信息攻擊那些打補丁很慢的公司。

正因為如此，已知漏洞是開源組件的主要威脅。既然大量漏洞的詳細信息在 NVD 上免費列出，黑客們為什麼還要浪費時間自己去找漏洞呢？

保護你的開源組件

正如我們在這裡看到的那樣，當涉及開源代碼時，安全團隊面臨的挑戰就不是自己在代碼裡面找出漏洞，而是在已知漏洞變得可用時，他們得做好準備。

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

第一件要解決的事情就是需要掌握在代碼庫和產品中所使用的開源組件是否包含現有漏洞。如果你的開發人員還沒有使用工具去跟蹤他們擁有的組件以及那些組件的安全狀態，那麼他們可能會發現自己跟 Equifax 一樣，處於缺乏關鍵可見性信息的境地。

除此之外，儘管我們可以修復脆弱的「必備」的組件中的問題，開發人員還是應該避免在構建新產品時，使用那些有已知漏洞的組件。這意味著，在把開源組件加入到你的代碼庫或產品中前，要利用可以檢測脆弱組件的解決方案，甚至可以利用自動化策略，如果開發人員試圖提交一段有風險的代碼時，該策略就讓構建失敗。

保證產品和產品中內含數據的安全，已經成為客戶的期望，因此需要應用正確的工具以在黑客們攻擊之前就能找到含有已知漏洞的組件。

由於大量的開源組件在業界廣泛使用，開發人員和安全團隊需要採用自動化的解決方案來跟蹤所有在他們的代碼庫和產品中用到的開源組件，同時監控像 NVD 這樣的漏洞資料庫以在研究人員發現新的漏洞時接收到警報。

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

最後，推薦我們精心打磨的 CI/CD 專欄，希望能幫你的團隊快速構建一個高效的持續交付體系。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！