軟體物料清單 (SBOM) 被譽為解決軟體供應鏈安全問題的關鍵工具，但軟體生態系統的快速變化，以及創建端到端驗證程式碼鏈的複雜性繼續阻礙其廣泛應用。

例如，Docker 已在其 Docker 加固映像中全面採用了軟體元件清單，這些鏡像採用極簡、安全導向的方案，用於建構安全的軟體容器。它們從底層構建，旨在最大限度地減少不必要的軟體組件（也稱為工件），並配備完整的軟體物料清單 (SBOM) 和溯源證明，採用軟體工件供應鏈級別 (SLSA) 的第三級標準，以數位化方式確保構建完整性並驗證軟體來源。

Docker產品管理副總裁 Michael Donovan 表示：我們認為每個工件都應該有 SBOM，尤其是容器映像，因為它們通常包含數十個軟體包，其中許多是開源軟體元件。Michael Donovan指出，企業很難為每個軟體創建軟體物料清單（SBOM）。即使是擁有成熟軟體開發實踐的企業，也常常會產生不完整的SBOM，因為許多開源專案並沒有為其軟體產生相應的供應鏈文件。

今年早些時候，美國網路安全和基礎設施安全局 (CISA)更新了軟體工程物料清單 (SBOM) 指南，要求清單必須使用機器可讀格式，例如軟體包資料交換 (SPDX) 或 CycloneDX，以協助在軟體開發流程中實現 SBOM 的自動生成和使用。然而，網路安全專家對於 SBOM 實際應用的可行性仍存在分歧。

RunSafe Security創辦人兼執行長Joseph Saunders表示，結果是關注點發生了變化。 RunSafe Security是一家為嵌入式系統提供網路安全解決方案的公司。他說，需要SBOM（軟體物料清單）的公司不再問供應商能否提供SBOM，而是問所提供的SBOM是否準確且可操作。

Saunders表示：如今許多軟體物料清單（SBOM）生成得太晚，缺乏關於組件實際使用方式的背景訊息，或者未能反映嵌入式和編譯軟體中實際交付的內容。SBOM本身並不能降低風險，準確的SBOM是漏洞識別、優先排序以及最終軟體供應鏈安全的基礎。

了解你的軟體

就像受監管行業有「了解你的客戶」（KYC）條款一樣，軟體採購手冊（SBOM）正是類似概念的體現：了解你的軟體。 2021年，即將卸任的拜登政府發布了第14028號行政命令，要求向關鍵軟體的購買者提供SBOM。兩年過去了，SBOM與其說是提升軟體供應鏈安全性的良方，不如說更像是強制性規定。

此後，歐盟通過了《網路彈性法案》（CRA），該法案要求軟體開發商以標準化的機器可讀格式創建和維護軟體物料清單（SBOM）。許多開源生態系統也開始爭取更多支持，並提供了將SBOM建置到專案和程式碼庫中的工具和流程。

CleanStart 的共同創辦人兼技術長 Biswajit De 表示，結果是，企業正被迫進入一個需要提供軟體物料清單的未來。 CleanStart 是一家提供強化軟體鏡像的公司。

Biswajit De說：物料清單（SBOM）不再是紙上談兵，在大多數受監管的企業採購週期中，它們已成為標配。雖然並非總是明確強制要求，但在實踐中卻非常普遍。容器是這一趨勢最先體現的地方，因為在構建時，物料清單很容易生成和附加。

一個有問題的網路安全解決方案

然而，問題依然存在。軟體供應鏈安全公司Chainguard的共同創辦人兼執行長丹‧洛倫茨表示，大多數被要求提供軟體物料清單（SBOM）的公司都是在建構流程的最後一步才產生SBOM，為了滿足合規要求而產生不準確的SBOM。他指出，隨著各公司在未來一年尋求提升軟體安全性，SBOM可能並非最有效的解決方案。

丹‧洛倫茨表示：如果你是美國政府，有機會在一些真正能提升安全性的領域施加影響，那麼（推廣安全營運手冊）對我來說始終是個謎。在某些情況下，它們或許有一定道理，但它們被廣泛採用和推廣的方式只會造成更多混亂，讓人們更關注‘走過場’，而不是‘真正整合這些系統，實現真正的安全’。

缺乏知識或專業技能是未能採用軟體業務物料清單 (SBOM) 的首要原因 (69%)，所有軟體開發人員 (DEV) 都提到了這個問題。
他表示，在某些方面，使用軟體成分分析系統（儘管可能會遺漏一些組件）可能會更好，因為它是一個獨立的系統。

丹‧洛倫茨認為：SBOM可能會給人一種虛假的安全感，[假設]建置系統遭到攻擊，而SBOM正是在建置系統中生成的。在某種程度上，最後掃描SBOM的黑盒軟體……只是在盡力猜測：但至少這是一個獨立的系統在進行猜測，而不是由可能已被攻破的同一個系統進行猜測。

此外，對於某些類型的軟體，軟體物料清單 (SBOM) 可能無法完整反映系統上軟體的實際狀態。 RunSafe Security 的 Saunders 指出，對於通常大量依賴開源元件的嵌入式設備，清單資訊可能不準確。

Saunders認為：產生準確的軟體物料清單（SBOM）仍然很棘手，尤其是對於編譯型軟體和嵌入式軟體而言。許多組織仍然依賴手動流程，因為現有工具無法全面涵蓋開源、第三方和專有組件的組合，而複雜的構建系統只會加劇這一挑戰。

不僅僅是 SBOM

隨著供應鏈攻擊的增加，企業開始懷疑他們使用的開源軟體元件是否安全，軟體物料清單將不再是唯一可能。在未來一年獲得更多關注的主要軟體供應鏈安全舉措：SLSA（發音為「salsa」）將成為關注安全的開發團隊的另一個重點。

Docker 的 Donovan 表示：我們看到市場對 SBOM 的需求遠不止於此，尤其需要 SLSA 框架來確保構建系統的安全性與生產環境一樣高。對於企業而言，確保構建管道的安全至關重要，而 SLSA 框架為行業樹立了很高的標準，我們聽到越來越多的企業提出這樣的需求。

11月底，Linux基金會發布了其供應鏈安全標準SLSA 1.2的最新重大更新。此次更新定義了更細粒度的建置追蹤和原始程式碼跟踪，分別用於追蹤建置過程中二進位元件的來源和原始程式碼開發過程中的來源。

當然，成分清單的概念也正在應用於人工智慧領域。隨著人工智慧日益成為軟體、服務和開發流程中不可或缺的一部分，企業開始產生人工智慧物料清單（AI BOM）。

一份有效的AI物料清單（AI BOM）應包含用於訓練和構建AI產品的數據集信息，包括數據來源、敏感級別和格式；AI模型信息，包括名稱、版本、算法、訓練參數和方法；以及指向原始訓練集的鏈接。根據雲端安全供應商Wiz發布的描述， AI BOM還應包含依賴關係、安全性、治理以及管理該流程的人員和流程方面的資訊。

該公司表示：人工智慧系統不斷發展演進，導致依賴項和基礎設施快速變化。即使是微小的變化——例如未經批准更換數據集、使用不同的參數重新訓練模型，或將依賴項更新到存在漏洞的版本——都可能打開攻擊途徑，並破壞治理和合規工作。

資料來源：https://www.darkreading.com/application-security/sboms-in-2026-some-love-some-hate-much-ambivalence