開源意味著不問責，我們準備好應對比 Log4Shell 更大的安全危機了嗎？

開源安全正在經歷一個加速變革的時期。

Log4Shell 爆發后，負責 Log4j 的三位沒有酬勞的維護人員一邊忍受抨擊，一邊不眠不休地工作了一個多星期，為這份影響世界的代碼打上了補丁。

Log4Shell 再次凸顯了在 SolarWinds 攻擊后備受關注的供應鏈安全問題。2022 年本應是“供應鏈安全元年”，不幸的是，一年后的現在這個漏洞仍然普遍存在，修復版本采用率沒有想象中的高，而且數據顯示，軟件供應鏈攻擊頻次反而呈現出急劇上升趨勢。

在過去的二十年里，開源軟件使得企業軟件創新爆炸式增長，對于一個越來越依賴開源軟件運行的世界來說，供應鏈安全是一個巨大的、關乎生存的問題。Log4Shell  成為頭條新聞，讓大家認識到，“資源相對匱乏、以志愿者為基礎的開源社區也存在著安全風險”，那么是否有更嚴重的“爆發”正在路上？

對 Log4Shell 漏洞的披露也成了開源安全治理的一個好時機，開源和安全社區、企業和 Linux 基金會的 OpenSSF 在這一年里更進一步地聯合了起來，出現了多項改善關鍵開源軟件安全狀況的舉措。在 2022 年結束之際，我們采訪了 OpenSSF 總經理 Brian Behlendorf 以及就職于奇安信代碼安全實驗室的董國偉博士，他們從國際和國內兩個視角講解了開源安全的現狀和應對措施。

會不會有下一場更嚴重的“暴雷”？

Linus 法則斷言，“只要有足夠的眼睛，所有的錯誤都是淺薄的。” 換句話說，只要有足夠多的開發人員，幾乎每個編程缺陷都會被快速識別和修復。這觀點放在 90 年代，或許是正確的，畢竟 Linux 作為最可靠和最安全的操作系統之一，它的成功可以歸功于 Linus 定律的應用。

近年來，隨著軟件系統的蓬勃發展，開源協作模式使得軟件供應鏈的供應關系愈加龐大復雜, 供應鏈的管理也愈加困難。然后，Log4j 漏洞爆發了。

Log4Shell 只是一個警鐘

作為一個開源日志庫，Apache Log4j2 是 Java 應用最廣泛的開源日志組件，廣泛應用于政府、企業和公共服務機構的平臺、應用和業務系統中，該漏洞覆蓋范圍廣而且利用門檻低，對大量系統和機構造成了嚴重影響。Log4j 漏洞也被稱為 Log4Shell，其 CVSSv3 得分為 10.0。用更容易理解的方式來說明就是，嚴重度評分是從 0.1 到 10.0，Log4Shell 得了個最高分。

對于普及度高的漏洞，其實很難完全修復。漏洞爆發后一年后，大多數組織仍易受到 Log4Shell 漏洞的攻擊，在全面修復之后，還有近三分之一軟件中再次出現 Log4Shell 漏洞。簡單來說，原本的代碼確實修復了，但之后有人引入了“新代碼”，而新代碼里又包含舊的 Log4j 版本。然后，漏洞就不斷被復活，就像一場“森林火災”，花一年的時間還撲不滅。

Log4Shell 的例子也告訴我們，如果一段開源代碼在全球范圍內被大量采用，要緩解開源軟件引入的安全威脅，可能要花費大量成本、修復容易出現錯誤、甚至可能引入新的安全隱患等。

Log4Shell 僅僅是開源庫中被發現和利用的系列漏洞之一。

開源無處不在：Synopsys 公司發布的商業代碼庫報告發現，商業代碼庫中 78% 的代碼來自開源項目。這些產品被應用于各種環境，從民用手機到互聯網、再到國家安全及國防系統。出于這個原因，一旦這些被廣泛應用的開源庫中出現漏洞，則可能影響到大量已部署代碼并造成嚴重后果。

而根據奇安信的分析統計，開源系統中，漏洞的增長速度、安全缺陷和高危安全缺陷的密度，以及典型缺陷的檢出率均呈現出增長的趨勢；國內企業開發的軟件項目中，100% 使用了開源軟件，存在已知開源軟件漏洞的項目占比 86.4%，平均每個項目存在 69 個已知開源軟件漏洞，十幾年前的古老開源軟件漏洞依然存在于多個項目中。并且通過實例分析，也證實了“老漏洞”攻破最新主流產品的情況。同時版本長時間不更新和更新非常頻繁的開源項目，比例都在增加；企業開發的軟件項目中仍然在使用 20 年前老舊版本的開源軟件。此外，在開源生態系統中，更是存在非常多的被大量依賴的開源項目，比 Log4j2 組件依賴數多的項目也不在少數（Log4j2 甚至排不到前 50 名），這些作為“底座”的組件一旦爆發嚴重漏洞，其波及的范圍可能比 Log4Shell 更大，完全有可能造成比它更嚴重的后果。

供應鏈攻擊越來越多

根據安全報告顯示，Log4Shell 漏洞披露后的 72 小時，全球出現了超過 80 萬次利用漏洞的嘗試。

Log4Shell 漏洞的出現，像給“黑客”們豎起了一個靶子，告訴他們開源代碼中存在著一些無意間嵌入的、可用于進一步攻擊的“秘密”，這讓更多的惡意攻擊者將注意力轉向了軟件供應鏈。

過去這一年里，軟件供應鏈攻擊呈急劇上升趨勢，自 2019 年以來平均每年增長 742%。

自 2019 年以來，軟件供應鏈攻擊有所增加。

根據奇安信的跟蹤統計，過去這一年多，幾乎每個月都會發生有關開源安全的典型事件，涉及開源軟件安全漏洞、開源生態系統安全等方面，例如：

2021 年 11 月，熱門 NPM 包 coa 和 rc 連續遭劫持，并被植入惡意代碼，影響全球 React 管道。coa 庫每周下載量約 900 萬，用于 GitHub 上近 500 萬個開源庫中，rc 庫每周下載量達 1400 萬。

2021 年 12 月，Apache Log4j2 曝出 Log4Shell 漏洞 (CVE-2021-44228)。

2022 年 3 月，俄烏沖突中，NPM 開源包 Node-ipc 的作者 RIAEvangelist 作為反戰人士，在代碼倉庫中進行了“供應鏈投毒”，添加的惡意 js 文件能夠在包使用者的桌面創建反戰標語。Node-ipc 使用非常廣泛，每周下載量超過 100 萬次。

2022 年 4 月，以色列安全公司發現高通和聯發科芯片的音頻解碼器存在三個漏洞（CVSS 評分為 9.8、7.8 和 5.5），來源于 11 年前蘋果公司開發的開源無損音頻編解碼器 Apple Lossless。利用這些漏洞進行攻擊，可獲取受影響移動設備媒體、音頻會話的訪問權限及攝像頭數據流等，漏洞影響范圍包括數百萬安卓設備。

2022 年 7 月公開（可追溯至去年 12 月），攻擊者通過在 NPM 上發布包時繞過雙因子認證（2FA），創建了 1000 多個用戶賬號，攻擊者利用這些賬號自動投放 1283 個包含挖礦腳本 eazyminer 的惡意模塊，利用數據庫、Web 等所在服務器的機器閑置資源進行挖礦。如果開發者安裝了這些包，則會在被調用時挖掘門羅幣。

惡意攻擊者繼續瞄準開源項目生態系統，沒有理由相信 2023 年這些攻擊者的表現會有所不同。

對于開源軟件漏洞，應不應該問責？

開源軟件和自研軟件在代碼層面并沒有本質區別，因此開源軟件帶來的安全威脅并不會比自研軟件少。而當同一段代碼被全球范圍廣泛使用時，一個項目中的一個漏洞可能導致無數關鍵系統離線。

開源提供了很多益處，降低壁壘、增加創新，讓大家將有限資源投入到其他有價值的工作中。這種資源是免費的，任何人都可以使用它。然而，漏洞也是不可避免的，如果你在使用供應商提供的商業軟件的過程中發現安全問題，你可以去找供應商并要求他們修復和承擔責任，但開源軟件跟商業軟件的責任模式不同，自打開源概念誕生以來，開源軟件就一直強調“使用者風險自負”。

開源生態之所以像今天這么繁榮，是因為開源軟件采用的自由許可協議和一系列免責條款，包括學生、初創公司員工、志愿者乃至大企業技術專家在內的各類開發人員，都會在無需共享代碼的情況下針對風險或缺陷開展協作和快速迭代。

有追求的開源軟件維護者也有動力修復 bug、編寫說明文檔并為新用戶提供其他形式的輔助，借此增加項目的用戶數量，最終吸引到更多技術貢獻者。但最終用戶要想獲得商業級別的支持或安全保障，還是需要跟供應商簽訂付費協議。既想不花一分錢，又想讓免費下載和使用的軟件安全可靠，這確實不太現實。

這就是開源軟件當前的問責模型（當然，主動引入后門、植入惡意代碼的行為除外）。即使面對日益增加的網絡安全問題，這套問責模型也仍然發揮著效力。那些打包并支持開源代碼的軟件供應商需要對客戶負責，由他們來保證提供安全可靠的軟件使用體驗。在購買軟件支付合同或軟件即服務時，我們有權要求供應商提供相應的安全保證。但我們絕不能通過放慢開源軟件的迭代速度來追求更高的安全性，這樣只會增加開源貢獻者的負擔，最終提高準入門檻、反而削弱所有參與者的安全信心。

開源社區該如何應對？

自由許可和“免責條款”造就了開源的繁榮，但這種“免責機制”，也使得像針對其他軟件開發商那樣，對開源社區和開源貢獻者進行強約束較為困難。為了保持開源免費的核心精神，開源社區不能對其項目強加條件要求。

去年，開源社區也不斷進行嘗試，尋找大家可接受的解決辦法，還有軟件供應商試圖通過大量調查問卷征求安全實踐認證，但這明顯有將安全責任轉移給開源維護者的嫌疑，當然會遭到拒絕。

還有比如，在發生多起開源維護者賬戶被劫持的事件后，為了提高生態系統的總體安全性，最受歡迎的開源項目集合之一 Python Package Index （PyPI）宣布將對“關鍵”項目（下載項目的前 1%）實施最低安全措施，要求這些項目的維護者使用雙因素身份驗證來保護他們的帳戶，涉及約 3,500 個項目。這引起了社區的強烈抗議，有的威脅要放棄他們的“流行”項目，其中一位說道：“免費的不值得做這些，只有在我真正得到報酬時才擔心供應鏈安全”。對比 2016 年 left-pad 事件，一名開發人員從 npm 注冊表中撤回了他的關鍵 JavaScript 項目，雖然只有 11 行代碼，但是后果卻嚴重到出乎意料，幾乎破壞了當時的互聯網。

而且開源社區中，維護人手匱乏的問題不在少數，大約 30% 的開源項目（包括一些最流行的項目）只有一個維護者（負責審查代碼貢獻、掃描漏洞和解決報告的錯誤的開發人員）。2014 年的 Heartbleed 攻擊——影響了近五分之一的互聯網——利用了一個開源庫中的漏洞，該庫由兩名全職開發人員維護，他們單獨負責超過 500,000 行代碼。也因此，雖然研發作為軟件代碼安全性的第一責任人，開源安全“左移”是必要的，但開源作為一種開發者的自愿協作活動，一味地提高開源安全的底線必然會遭到抵制，并影響開源社區的正常發展。

更重要的是，開源的其他受益者也應該參與進來，因為開源安全中的關鍵問題不僅僅包括供應鏈安全問題，這要求其中的開源代碼用戶審查自己的依賴項并保持更新；實際還有漏洞披露問題，要求相關方負責任地上報并披露開源軟件漏洞，以將危害降至最低；最后就是投資問題，開源軟件的用戶需要回饋開源社區，以確保其依賴項具有可持續的生命力。

Linux 基金會認為，要想真正破解這些挑戰，必須找到新的方法來衡量開源軟件包中存在的種種未被發現的缺陷和風險，還要想辦法衡量已經無法升級的依賴項中各已知缺陷可能造成的影響。事實上 Log4Shell 等重大安全事件讓包括行業主導方和政策制定者在內的各利益相關方意識到問題嚴重性。我們國家也于 2022 年 11 月初，立項了國家標準《軟件產品開源代碼安全評價方法》，著手規范應對此類問題。

如今開源已經成為社會的“高速公路和主要橋梁”，對開源進行的漏洞攻擊造成的影響會更大。因此，與其說開源安全是開源開發人員的個人義務，不如說必須有一個組織來聯合起個人及企業，共同推動開源安全治理，這也是 OpenSSF 誕生的初衷。

開源安全不能單打獨斗

OpenSSF 是一個圍繞開源安全建立的組織，聯合了行業內最重要的開源安全項目和相應的個人及企業貢獻者。

OpenSSF 與上游及現有社區合作，提供安全審計，或對下游提出“警報”，以幫助提高開源行業的整體安全性。其目標是在未來，讓開源生態系統中的每位參與者都能使用和分享更多高質量軟件，培養大家主動解決安全問題的主人翁心態，并將高質量和主動處理安全問題視為理所當然。

過去，人們曾做出各種努力來提高開源軟件安全性。這些努力包括 Linux 基金會的核心基礎設施倡議（CII），由 GitHub 安全實驗室建立的開源安全聯盟（OSSC），以及由谷歌等企業創立的聯合開源軟件倡議（JOSSI）。OpenSSF 的使命就是將這三大倡議合并為“跨行業協作項目，號召各方領導者齊聚一堂，共同提高開源軟件的安全性。”

2022 年，OpenSSF 成員范圍擴展到了全球一百多個組織，其中也包含了一些中國企業如信通院、阿里、騰訊等。經歷兩次美國白宮會議之后，OpenSSF 啟動了多項新舉措，包括 Alpha-Omega 項目以及開源軟件安全動員計劃，還提供了多種有助于提高開源軟件安全性的工具，包括 Sigstore、SLSA、Scorecards 計分卡，以及給開發人員的免費安全軟件開發基礎課程。

Alpha-Omega 是 OpenSSF 推動的一個核心項目，創立于 2022 年 2 月，其使命是通過直接吸引維護者和專業分析意見，顯著提高開源軟件的安全水平。“Alpha”代表開端，是指與開源項目的關鍵維護者合作，幫助他們發現并修復安全漏洞，借此改善安全狀況；“Omega”則代表末尾，強調確定至少 1 萬個已經廣泛部署的開源軟件項目，并把自動化安全分析、評分和補救指南等全面推廣至開源維護者社區。2022 年，該團隊資助并增強了五大關鍵開源項目的安全性，分別是 Node.js、Eclipse 基金會、Rust 基金會、jQuery 和 Python 軟件基金會。

SIgstore 于 2022 年 10 月全面推出，能幫助開發人員驗證自己正在使用的軟件，是否與聲稱的加密數字簽名及透明日志技術相符。它提供一整套技術組合，包括用于軟件工件簽名的 Cosgin、證書頒發機構 Fulcio、透明日志 Rekor 和用于 Git 提交簽名的 Gitsign。這些工具既可以獨立使用，也能作為單獨進程使用，由此建立起成體系的整體開源安全方案。

SLSA 的全稱是軟件工件供應鏈級別，這是一套安全框架或者說標準與控制清單，強調防止篡改、提高完整性，同時保護項目、業務或企業中的軟件包與基礎設施。在它的幫助下，用戶能在供應鏈的各個環節上保障理想的安全性和彈性。

Scorecards 計分卡能幫助開源維護者改進其安全最佳實踐，并幫助開源消費者以自動化方式判斷自己使用的依賴項是否安全。該工具會對涉及軟件安全的一系列重要條目進行檢查和評估，并打出從 0 到 10 的具體評分。

SBOM 很有用

OpenSSF 另一個核心項目是 SBOM。

你也許想不到，在 Log4Shell 漏洞爆發后的今天，從 maven central 主動下載的 Log4j 版本中有約 30% 是易受攻擊的版本。那么為什么仍會有人在拉取這些易受攻擊的 Log4j 版本？很大一部分原因，是許多組織缺乏成熟的漏洞管理流程，以及缺乏對其軟件組件（軟件物料清單，稱為 SBOM）的可見性，導致大家在不知不覺中仍在使用依賴易受攻擊版本的 Log4j 的軟件。很多企業也無法快速判斷自己用的 Log4j 版本有沒有缺陷，因為沒有這樣的 SBOM 能確切告訴他們當前使用的是哪個版本。

SBOM 本質上就是構成軟件產品的“成分表”，即各個依賴項。有許多包括開源軟件在內的第三方來源的成分，我們并不知道其具體包括哪些內容，因此對其安全性的了解更無從談起。SBOM 能幫助企業或開發者更好地了解自己所使用的開源軟件到底包含哪些依賴項，從而輕松審查這些依賴項并隨時加以更新。

SBOM 很有用，沒有它們，即使是最大、最先進的技術公司也需要數周時間才能確定它們容易受到攻擊的位置，更不用說修補每個組件了。

奇安信建議將軟件物料清單（SBOM）作為軟件供應鏈安全的抓手首先推進落地，通過軟件物料清單（SBOM）的推廣應用，牽引軟件供應鏈上下游各個環節的協同，在此基礎之上再采取更多舉措逐步深化，實現軟件供應鏈安全保障的目標。同時，軟件安全企業的軟件成分分析（SCA）工具能夠方便的實現 SBOM 的自動生成功能，在目前軟件開發普遍集成開源軟件的情況下，對于提升軟件透明度、開展安全分析具有重要作用。

如今，已經有多種 SBOM 工具可供大家使用，其中最流行的兩種 SBOM 格式分別是 SPDX 和 CycloneDX。OpenSSF 正努力提高工具成熟度，并通過 SBOM Everywhere 特別興趣小組推廣這些工具。

寫在最后

2022 年，特別是在 Log4Shell 等開源軟件安全事件發生之后，我們可以看到從行業到政府的眾多利益相關方，都開始更好地理解到開源軟件的重要意義和重新投資開源生態系統的迫切性。

雖然 2023 年里開源軟件和軟件供應鏈依然是重要的被攻擊領域之一，攻擊事件仍然會保持持續高發態勢。但另一方面，各行業對開源安全的認知也在不斷提升，對這一領域的關注度在不斷提高。國家層面也開始積極資助和支持開源軟件安全工作，這一切都令人備受鼓舞。企業層面，也正在制定和完善內部的開源軟件安全管理規定，規范開源軟件的安全使用，減少其引入的風險，相信明年力度將更大。

正如 OpenSSF 對未來規劃中所說的那樣：“作為開源社區，我們的未來完全取決于做出貢獻的每一個人。過去一年來，我們看到了在 2022 年初時根本無法想象的新產品和新措施。我個人認為，AI 將全面進入開源軟件安全領域——既可以作為防御手段，也可能成為建設性工具。我們將繼續在 OpenSSF 的旗幟下擴大不同項目和計劃的組合，同時將眾多項目整合到統一的工具套件當中，讓各種安全開發方法和成果融入工具鏈條。這種融合工作當然難度極大，但在安全領域卻至關重要。畢竟在這類領域中，‘能用很多辦法解決同一個問題’并不一定是好事，強有力的標準和規范往往才是理想之道。”

開源為各個組織提供了巨大的價值，是我們今天所看到的創新步伐的核心驅動力，相信只要我們齊心協力，就不會讓它失控。