Log4Shell風波后，為什么軟件物料清單（SBOM）至關重要

譯文

作者：趙青窕 2021-12-28 07:32:56

安全應用安全

在此次 Log4Shell 風波后，對于定位解決新出現的軟件供應鏈中的漏洞和攻擊來說，生成 SBOM 并快速地獲取其信息已經變得至關重要。

?[[442408]]??

【51CTO.com快譯】

作者丨Josh Bressers

譯者丨趙青窕

策劃丨孫淑娟

在此次 Log4Shell 風波后，對于定位解決新出現的軟件供應鏈中的漏洞和攻擊來說，生成 SBOM 并快速地獲取其信息已經變得至關重要。

同許多零日漏洞一樣，相關的組織或者機構正在全力地識別修復 Log4j 中 Log4Shell 漏洞的影響。這種漏洞是極其危險的，因為該漏洞存于一個極其常用的庫中，并且很容易被利用。目前的關鍵因素是，在具體的漏洞相關細節被公開之前，它已經被廣泛地利用，從而迫切地需要盡快修復。

在 24 小時的修復工作之后，安全和應用程序團隊喘了一口氣，接下來他們將進行回顧和審查的工作，以便為下一個零日漏洞的定位做準備。在這種新環境下，軟件物料清單 (SBOM) 正在成為一種至關重要的安全要求，它使軟件在整個供應鏈中具有可見性。因此我們必須立即行動起來建立一個關鍵的新功能：SBOM 管理。

創建一個綜合性的 SBOM

目前，行業領導者采用的最佳實踐是為每個交付或部署的應用程序版本生成一個軟件材料清單(SBOM)。事實上，最近美國關于國家網絡安全的行政命令將要求軟件供應商向聯邦機構提供他們銷售或交付的軟件的 SBOM。

如果我們從廣義的角度來看，生成 SBOM 只是第一步。正如 Log4Shell 向我們展示的那樣，當新的零日漏洞發生時，我們需要能夠輕松地利用和搜索 SBOM。生成 SBOM 很容易，但管理和跟蹤數百或數千個 SBOM 是一項艱巨的任務，而且對于處理不斷變化的威脅情況也是一項困難的任務。

雖然今天在交付應用程序之前掃描漏洞是很常見的，但這遠遠不夠。掃描應用程序以識別組件和相關漏洞應該是一個持續的過程，不應該只運行一次，而應該定期運行。每次掃描應用程序時，都必須記錄和分析結果。為了從一個點對點的系統轉移到一個連續的系統，工具和自動化是很重要的。

一個組織或機構在開發應用程序時，通常包括大量的開源代碼以及內部開發的代碼和第三方的商業庫。SBOM 生成工具可以檢查編寫的代碼，包括其中使用的開源代碼，但針對商業庫，根據其打包方式的不同，可能會無法掃描到。鑒于這種情況下，需要商業庫的供應商提供商業庫對應的 SBOM。有了所有組件的 SBOM 之后，就需要將它們組合起來，生成覆蓋整個應用程序的聚合 SBOM。

SBOM 管理所需的關鍵功能

使用 SBOM 作為確保軟件供應鏈安全的基礎，但隨著時間的推移，越來越多的 SBOM 將被生成和包含。因此需要工具和自動化來管理復雜的 SBOM。查找的功能包括:

一個集中的存儲庫，用來存儲跨產品團隊和應用程序的 SBOM。

具備快速查找有問題組件的應用程序的搜索能力。

具備生成或導入由軟件供應商或開源項目組提供的 SBOM 的能力。

可以整合所有組件級的 SBOM，從而為應用程序創建一個綜合性的 SBOM。

支持復雜的 SBOM 標準以及 SPDX 之類的輕量級 SBOM 標準。

可以針對一個應用程序的多個釋放的版本，多個構建版本，或者開發的不用階段，分別存儲其對應的 SBOM 的能力。

具備 SBOM 比較的能力，以便檢測到異常后，對可能發生的纂改給予警告。

SBOM 事件響應速度

一旦您為一個已發布應用程序版本獲得了一組明確而準確的 SBOM，您就需要將這些 SBOM 存儲在一個集中的存儲庫中，以便快速掃描和搜索 SBOM 的內容。集中式方法意味著安全團隊不必浪費時間來確定在他們的應用程序中部署了哪些組件。當下一個重大漏洞出現時，SBOM 管理工具應該立即返回結果。應用策略引擎和策略規則將會向所有受影響的應用程序團隊生成通知和警報。這樣應該在幾分鐘內就會知道哪些應用受到影響，以及如何進行補救，而不是花費幾周的時間去定位問題。