引言：在資訊保安界，近期爆出的最大的“雷”便是 2021 年 12 月發生的 Log4Shell 漏洞（CVE-2021-44228）。我們相信，類似 Log4Shell 的漏洞絕不是最後一次出現，那麼下一次面臨類似的問題的時候我們該怎樣及早發現、及早修復呢？
在數字時代，軟體安全已經成為政府、企業、組織等各個層面關注的重要問題。雖然軟體是一種無形資產，但是由於忽視軟體安全所帶來的國家安全、企業安全、個人隱私等各個方面的嚴重問題卻是“有形”的。CISQ(Consortium for Information & Software Quality) 釋出的一個數字表明美國 2020 年由於軟體質量付出的代價達到了 2.08 萬億美元。
更進一步，混源開發模式已成為常態，開源軟體的使用比例越來越高。OSSRA 報告中顯示，該機構調研的分佈於各行業的組織中的 2409 個程式碼庫中，有 97%的程式碼庫包含開源元件。開原始碼的使用對企業和開源社群甚至整個 IT 行業的發展都具有非常積極的意義，但是制定混源策略、管理這些日益增長的第三方程式碼、保證程式碼不受安全漏洞的威脅成為了一個迫切需要關注的問題。
在資訊保安界，近期爆出的最大的“雷”便是 2021 年 12 月發生的 Log4Shell 漏洞（CVE-2021-44228）。該漏洞被廣泛認為是史上最嚴重的資訊保安漏洞。美國網路安全和基礎設施安全域性局長 Jen Easterly 把這個漏洞視為她職業生涯所經歷的最嚴重的漏洞。接下來，我們就以該事件為例，與大家討論如何在企業的軟體供應鏈管理中及早發現、及早處理此類安全漏洞。
》》》什麼是 Log4Shell 漏洞
Log4Shell 是一個 Log4j 產生的零日漏洞，主要涉及任意程式碼執行，允許攻擊者在伺服器或其他計算機上執行任意 Java 程式碼，或洩露敏感資訊。Log4j 是 Apache 基金會貢獻的開源專案，於 2001 年首次釋出，它是一個基於 Java 的日誌框架，受影響的 Log4j 版本包含 JNDI 功能（如訊息查詢替換），這些功能無法防止對手控制的 LDAP 和其他與 JNDI 相關的端點。
》》》Log4Shell 發現的時間線
- 2021 年 11 月 24 日 阿里雲安全團隊的陳兆軍首先發現問題並報告給 Apache 基金會
- 2021 年 12 月 1 日 CloudFlare 報告了首次對該漏洞的利用
- 2021 年 12 月 10 日 CVE-2021-44228 編號分配，全世界範圍內開始意識到問題的嚴重性
之後的一個月之內，圍繞 CVE-2021-44228，Apache Log4j 總計爆發 8 個漏洞，其中 7 個高危以上漏洞。
》》》Log4Shell 漏洞波及範圍
Apache 給 Log4Shell 確定的 CVSS 分數為 10，這是嚴重性的最高等級，被譽為“接近於世界末日”的安全漏洞。
- 地理範圍：此次影響的範圍為全世界數億臺裝置。
- 國家安全層面：加拿大、比利時等國因此關閉了政府的部分網路和線上服務。
- 企業層面：93%的企業雲環境受到了影響。
- 版本層面：僅僅是 CVE-2021-44228，就影響了從 Log4j 2.0-beta9 到 2.14.1 的所有版本。
》》》怎樣及早發現及早處理這一型別的漏洞
我們相信，類似 Log4Shell 的漏洞絕不是最後一次出現，那麼下一次面臨類似的問題的時候我們該怎樣及早發現、及早修復呢？
首先，在很多企業和組織中，建立起“開源有益，但需要加以管理和治理”的思維模式是非常重要的。我們要意識到使用開源是一把雙刃劍，開源社群和基金會貢獻了大量的開源專案，但其使用的安全性需要被重視。如果一味奉行拿來主義，那麼再次出現 Log4Shell 這類的重大安全事件，會毫無招架之力，最終給企業造成很嚴重的經濟和商譽的損失。
其次，企業需要對自身使用的開源元件有一個清晰的瞭解，隨著開源元件使用的比例越來越高，我們很難透過維護 Excel 表格的形式去做統一的管理，不僅會浪費大量的人力，這種方式的準確性、有效性也值得商榷。那麼一個更為有效的方式是透過建立標準化格式的軟體物料清單（SBOM）來進行開源元件的管理。我們稍後會跟大家詳細探討這一話題。
接下來，掌握了企業和組織自身的軟體物料清單後，就需要一個實效性和準確性並存的漏洞資訊來源，將諸如 Log4Shell 這類的 0-day 漏洞準確地匹配到內部使用的開源元件中並及時告警、給出修復建議。
更重要的是，建立整個流程並保證其順暢執行實施才是處理此類問題的核心。國內網際網路企業大多已經採用 DevOps 的研發流程，那麼把開源漏洞掃描融入到 DevOps 的工具鏈中，才能實現漏洞的早發現、早跟蹤、早處理。在流程中的 SCA、SAST、DAST、IAST 等等測試就組成了 DevSecOps。當然，根據企業行業、規模和迭代週期等因素，DevOps 未必是針對部分企業的最佳實踐，那麼企業可以週期性的進行掃描程式碼中的開源漏洞。
綜上，我們涉及了人（開發者，測試人員、安全團隊）、工具（開源或商業化的 SBOM 生成和管理工具、漏洞庫等等）和流程。這些要素有任何的斷點，都會造成企業和組織對於重大安全漏洞的管理失能。
》》》SBOM 是什麼？怎樣透過 SBOM 來建立企業的軟體物料清單
首先，SBOM 的全稱是 Software Bill of Materials，中文譯為軟體物料清單，它不是一種特定的檔案格式。BOM 這個定義廣泛存在於傳統制造業，用以跟蹤和記錄產品的部件，當部件產生缺陷的時候，可以準確清晰快速地定位到缺陷影響的部件。那麼同理，在軟體領域，它的作用是能夠實時跟蹤軟體中使用的第三方元件來管理整個軟體供應鏈。
SBOM 有不同的格式，但是其實質都是對於元件、依賴、漏洞、許可證、版權等資訊的展示。
SBOM 常見的格式有：
- 工具本身生成的檔案，其特點是需要藉助於工具本身，進行不同工具之間的資料交換會需要二次處理；但是優點是可以根據工具的特點和功能進行資訊內容的定製，進而展示到前端頁面，可讀性更強。如下是某工具生成的 JSON 檔案擷取，我們可以看到 Log4j 這個漏洞是如何在 Vulnerabilities 欄位中展示出來的。
圖 1：掃描工具生成的的 SBOM JSON 檔案
透過工具的處理和渲染，該漏洞的資訊會展示在客戶端頁面
圖 2：掃描工具展示的前端頁面
圖 3：掃描工具漏洞資訊的展示
我們可以看到其中展示了該漏洞各種相關的資訊，包括嚴重程度、影響版本和修復建議等資訊。
- SPDX（Software Package Data Exchange）格式，SPDX 是由 Linux 基金會發起的，由 Intel, Google, Microsoft 等組織支援的格式，它包括了專案使用元件的資訊、許可證資訊、版權資訊、安全性資料等其他後設資料以提供軟體供應鏈的透明度和安全性。SPDX 最初是作為元件許可證資訊管理的需求而應運而生的。
- CyclonDX 格式，CyclonDX 是由 OWASP 社群發起的，由 Sonatype, Lockheed Martin, Contrast 等組織支援的格式，CyclonDX 是一種輕量級的 SBOM 格式，最初是作為元件漏洞管理的需求而產生的。
SPDX 和 CyclonDX 可以作為一種跨工具跨平臺使用的報告格式，而且他們的版本均在不斷地更新迭代中。
- SWID 格式也是一種，但是因其比較小眾，暫不做過多討論。
其實，無論使用哪種格式，無論是在每次程式碼更改時候進行增量掃描還是上線前的集中式掃描，只要我們建立適合企業自身的 SBOM 資訊展示能力，就達到了開源元件漏洞管理目標第一步。
》》》那麼精準地掌握企業 SBOM 進而進行高效的漏洞掃描需要哪些能力？
快速：無論是使用開源還是商業的掃描工具，要求我們必須要快速實現掃描，特別是對於大型公司或者大型專案。比如 openEuler 社群，包含 200 個自研專案和 8000 個映象，如此規模的社群需要一個快速的掃描工具，來滿足單個檔案的掃描速度快和增量掃描這些特點。
準確：SBOM 的準確性也體現在工具對各種顆粒度掃描的支援，比如程式碼片段掃描，那麼一個準確並及時更新的資料庫是至關重要的，一款領先的 SCA 工具可以做到在 0-day 漏洞暴露出來數小時之內推送到資料庫中。準確這一特點也包括掃描引擎內部匹配演算法的準確識別能力。
全面：全面與準確也是息息相關的，縱向來說，開源專案無時無刻都在更新，漏洞資訊也是如此，那麼需要資料庫背後的資料探勘機制足夠強大來把源源不斷的資料更新到資料庫中。橫向來說，支援例如 NVD、CNNVD、CNVD 等各種漏洞資料來源也是體現全面性的一部分。
開原始碼的大量使用所帶來的問題不僅僅與安全相關，對於涉及智慧財產權的許可證合規方面的風險管理能力也是企業亟須建立或不斷提高的，安勢資訊後續會與大家分享這方面的內容。我們下篇文章見！
參考資料：
[1]https://www.it-cisq.org/cost-...
[2]https://www.synopsys.com/blog...
關於「勢說新語」
安勢資訊推出全新欄目「勢說新語」，旨在為開源軟體供應鏈安全行業人士提供一個互相交流、互相學習的平臺。歡迎各位大咖加入，共同探討開源軟體供應鏈安全行業現狀及未來發展趨勢、行業熱點等話題，分享觀點，碰撞思想火花。
歡迎大家踴躍投稿，可以談談你對開源軟體供應鏈安全與行業發展趨勢的見解，投稿請傳送至郵箱：marketing@sectrend.com.cn
