如何更好地構建與利用SBOM - 網安 - 專業的網絡安全產業、社區、知識平臺

軟件物料清單（SBOMs）的有效性在于它能否幫助企業在合規方面發揮作用，解釋整個代碼庫，并實現企業規模上的互操作性。然而，目前行業中缺乏一種統一的規范來實現這些目標。

簡單地生成一個SBOM相對容易。但要生成符合規范標準、允許企業大規模互操作的SBOM往往困難重重。這就是"fullMonty SBOM"的意義所在，它描述了一個全面的SBOM解決方案，為其未來的實用工具提供了安全、法律以及操作用途等方面所需的內容和互操作性。要想實現有效的安全性或操作假設，這種全面性的SBOM往往是不可或缺的。

美國總統拜登于2021年5月發布的行政命令14028中強調了聯邦政府需要購買包含SBOM的軟件的要求。同時該命令也強調了“了解軟件供應鏈，獲取并利用SBOM來分析已知漏洞，在風險管理中至關重要。”這對于安全領域來說是一個重要的推動因素。它引發了用戶對所用軟件的內部運作方式的更多疑問。人們開始對常用軟件的內部結構和工作原理提出更多問題，以確保其安全性和可靠性，特別是在涉及政府以及與政府相關的業務時。

如今市場上越來越多的安全廠商開始主動生成SBOM作為其產品的一部分。盡管每個工具在具體功能上有所不同，但這無疑是該領域的一項重大進步，為用戶提供了對現代云基礎架構中復雜代碼部署的可見性。

在該領域中，許多安全廠商和一些開源框架都可以掃描依賴關系樹。然而，目前主要問題就是SBOM的生成缺乏統一的標準。如果能夠成功實施統一標準，那么SBOM就可以順利應用于風險管理和漏洞影響評估等環節。但如果數據無法在多個平臺上進行標準化，那么構建全面的風險模型將會變得困難。

一個有效的SBOM文件需要滿足以下三項要求：

格式符合標準規范

為了實現SBOM的廣泛交換以及自動讀取功能，它們的交換格式必須符合標準規范。

目前業界認可度最高的兩個標準為SPDX和CycloneDX。這些標準旨在確保SBOM輸出的一致性。也就是說，當使用不同的SBOM生成工具來生成同一軟件的SBOM時，它們會產生相同的結果。這些統一的格式可以根據不同的使用案例和行業垂直領域來進行定制，企業可以選擇“包含”、“排除”或“鏈接到”特定的信息（例如許可證、版權和漏洞等）。這樣的靈活性可以在滿足不同需求的同時，促進標準化的應用和交流。

需要注意的是，SPDX和CycloneDX僅描述了SBOM文件結構的標準，而沒有涉及到SBOM文件的全面性和準確性等方面。生成SBOM文件的過程或工具只是按照標準來對所輸入文件中的信息進行組織和呈現，而無法保證輸入文件本身的質量或準確性。也就是說，如果使用的SBOM生成過程或工具接受了錯誤或不完整的輸入文件，那么即使它能夠按照規定的結構生成SBOM文件，但所產生的SBOM文件仍然可能是錯誤或不完整的。

全面性

對于幾乎所有的應用軟件來說，開源組件都是其攻擊面的最大構成部分。這些開源組件出自世界各地的開發者之手，平均占據軟件應用的76%。Log4j就是一個典型的例子，它向人們展現了單個開源組件中的單個漏洞所能夠在全球范圍內產生的巨大影響。對于大多數組織來說，要想確保軟件供應鏈以及信息基礎設施的安全性，就必須要把對開源軟件漏洞的迅速識別及修復列入優先級最高的安全事項行列。

其實，很多人都對SBOM有一種偏見，認為它只是一個開源軟件（ open source software， OSS)）的物料清單。但實際上，大多數軟件成分分析（software composition analysis ，SCA）供應商所生成的不同類型SBOM中，除了會列出OSS組件，同時還會將不同級別的傳遞依賴關系展現出來。對于那些僅包含OSS的SBOM，它可能會使組織忽略掉軟件供應鏈中其他類型代碼所攜帶的漏洞。

一個全面的SBOM會對應用程序中的所有組成部分進行揭示，包括自定義代碼、開源組件以及第三方的非開源組件。這是因為并非只有開源代碼會存在漏洞，其他不同類型的代碼中也同樣具有攜載漏洞的可能，這一點至關重要。

互操作性

SBOM本質上是一種靜態文檔。但如果從軟件供應商那里獲取的SBOM文件只能幫助組織進行軟件成分的檢查，那么其價值就顯得十分有限。SBOM的真正價值在于對其的利用，即互操作性。組織要能夠將其納入諸如補丁管理以及部署風險評估等其他生命周期風險管理的流程之中，同時還要能夠在企業規模上對其進行操作。

安全團隊可以通過具有互操作性的SBOM進行的三個常見的操作，即合并、查詢和監控。

? 合并:一個完整的汽車所包含的配件往往出自不同的供應商，不同的軟件供應商通常會使用不同的標準格式來生成各自的SBOM，而汽車制造商則需要將這些不同格式的SBOM聚合到一個系統級的SBOM之中。

? 查詢: 如果某個被廣泛應用的組件中存在新的零日漏洞，那么就需要查詢所有的SBOM來確定組織中的眾多軟件應用中哪些包含了這個具體的易受攻擊的組件。假設組織具有數千個應用需要檢查，那么平均每天就要處理大約60個新CVE，這在技術上是很難實現的。因此，對于互操作性以及有效的軟件風險管理來說，能夠通過單一的界面來對數千個SBOM進行查詢檢測是十分關鍵的要素。

? 監控: 安全團隊可以將旨在實現互操作性的SBOM與威脅情報和漏洞管理系統進行集成。這樣，當出現新的零日漏洞時，它們就可以對所有現存的SBOM進行自動檢測，以查找該漏洞的波及范圍，同向其產品生命周期管理系統通知風險。

從軟件物料清單（SBOM）中，我們可以了解到以下三個關鍵內容：

了解軟件的應用范圍

通常情況下，安全專業人員需要時刻搞清楚“組織擁有哪些軟件？以及這些軟件應用于何處？”如果將軟件依賴項納入到開發與生產級別的代碼中，那么這個問題將變得更加復雜。然而實際上，一些組織擁有多個產品或者多個具有不同風險配置文件的環境，這樣一來，為了做出合理的商業決策，需要處理的問題就更多了。因此，除了軟件物料清單（SBOM）之外，組織還需要更多的元數據和環境信息。所以說，了解軟件及其所應用的位置將有助于建立上下文，以便正確地進行風險決策。

了解使用的開源庫所面臨的法律風險

組織需要充分了解開源許可軟件，以確保其行為符合組織政策，這是經常被忽視的方面。許可證問題可能會引發法律糾紛，使組織面臨罰款的風險。組織可以通過研究過去的案例來了解這些風險。此外，額外的上下文數據和審查日期有助于確保合規性的基礎建設。另外還需要注意的是，工程使用案例往往會隨著時間的推移而變化。

了解下游庫

還記得那個名為“faker”的開源項目事件嗎？它幾乎徹底摧毀了整個下游的用戶。大部分組織在掃描過程中時常會忽略一些依賴項，而依賴關系卻往往存在在這些被忽視的依賴項中。需要注意的是，要遞歸地搜索組織中的代碼（尤其是在生產環境中），從而發現可能受影響的下游庫。

提前準備備選方案

檢測到開源庫中的漏洞之后，緊接著要做的就是進行漏洞修復。修復漏洞需要花費時間，短則幾天，多則數月。要想有效地采取應對措施，關鍵就是要及時地意識到自己的風險狀態。為了應對漏洞與風險，組織可能需要自行刪除庫中的代碼，或者將所涉及到的開源項目復制到獨立的代碼庫中，并在其內部進行維護和開發。當然，完全消除所有風險概率是不現實的，組織能做到是要提前制定針對該弱點的計劃，以在風險發生時，盡量減輕可能遭遇的沖擊與損失。

SBOM實踐還有很長一段路要走。人們正在努力將其格式標準化為機器可讀的標準，例如SPDX、CycloneDX等，這些標準遠遠超出了本文所提及的內容。如今，行業正朝著正確的方向前進。但與此同時，我們還需要努力將這些標準統一到一個共同的機器可讀格式中，從而避免不同標準的爆炸性增長。

隨著組織不斷構建規模更大、結構更為復雜的模塊化軟件，引入的外部依賴性也開始飛速增長，最終擴大了供應鏈攻擊的風險。盡管我們可以采取手動的模式來進行開發，但不可否認的，未來的方向是實現整個工作流程（從發現漏洞到修復）的自動化。

最后，同樣需要明確的是，SBOM并非萬能的解決方案。全面的SBOM固然重要，但它也只是軟件供應鏈風險管理中的一小部分。確保自研代碼和開源軟件中（OSS）不存在漏洞，軟件符合法規要求，以及開發流程安全防篡改同樣是其中重要的環節。類比于食物供應鏈，人們肯定不愿食用成分未知或者由衛生不達標的工廠生產的食物。同理，企業也需要確保其軟件供應鏈的安全性，才能贏得用戶等利益相關者的信任和支持。

無論是食物還是軟件，都必須要確保產品是安全可消費的，而這僅依靠SBOM是遠遠不夠的。在整個產品的制作過程中，其他類型的安全性流程以及定期的檢測同樣重要。