買家手冊：企業在選擇 SBOM 供應商時需要注意什麼？

Apache Log4j 和 Log4Shell 兩大事件的發生，将軟體物料清單（Software Bill of Materials, SBOM）推向安全防護前沿，成為企業保護其軟體供應鍊的方式之一。今年5月，美國總統拜登釋出行政指令，要求 IT 供應商必須提供 SBOM 才能夠與美國政府進行合作。受此影響，越來越多的企業也開始将 SBOM 內建到其 DevSecOps 流程中。

那麼 SBOM 是什麼呢？我們通常将 SBOM 籠統地描述為成分清單，就好比食物成分表會羅列使用到的材料，我們可以通過 SBOM 去了解應用程式、服務、包等。嚴格來說，SBOM 并不是解決軟體供應鍊安全問題的完整解決方案，但它是保護軟體供應鍊的關鍵部分。

SBOM 在未來将作為軟體開發架構（Software Development Framework, SDF）的主要元件。SBOM 通過包含軟體元件和依賴項清單來增加軟體傳遞的透明度，如果沒有 SBOM，軟體依賴項、開源或商業許可問題、已知漏洞或其他潛在惡意成分的可見性就會降低。如果企業使用不含 SBOM 的軟體，且不進行額外的軟體盡調分析，可能需要承擔一定的安全風險。

雖然采用 SBOM 對提高安全性産生積極作用，但在 SBOM 真正發揮作用前，企業需要進行大量準備工作。這樣看來，雖然 SBOM 能夠在一定程度上保障企業的軟體供應鍊安全，但實踐起來還是存在一定的阻礙和困難。

選擇 SBOM 提供商需要注意什麼？

企業在選擇 SBOM 提供商時要注意的主要事項包括：

• 理想情況下，供應商應當提供其傳遞的每一個軟體的 SBOM。而軟體使用者将使用軟體成分分析（SCA）生成新的 SBOM 以用于提供給客戶。軟體供應鍊中最終傳遞時的 SBOM 應當包含一份全面、準确的清單，并列出所涉及的元件和版本。這就意味着供應鍊中每個環節的軟體供應商都需要提供全面的 SBOM，否則最終的 SBOM 将會不準确或不完整。
• SBOM 存在多個标準，包括 CycloneDx、SPDX 和 SWID Tag。大多數企業都希望 SBOM 包含依賴關系、清單、已知漏洞（CVE-ID）和軟體許可證資訊，但不同的 SBOM 标準對應的格式也不同，其包含的資訊也會有所差異，這也使得 SBOM 不容易成為一個通用的解決方案。
• DevSecOps 團隊需要認識到 SBOM 本身也是一個需要保護的數字文檔。SBOM 和 組織都需要確定 SBOM 不會受到損害。企業需要通過內建檢查和數字簽名來防止篡改，確定 SBOM 的完整性和真實性。許多企業在收集或維護 SBOM 方面僅僅停留在表面而未進行深入研究。雖然 SBOM 可以增加軟體供應鍊的可見性和透明度，但與此同時也給企業帶來額外挑戰，因為企業需要使用新的工具和實施新的流程。

考慮到這些注意事項後，如果企業沒實施适當的 DevSecOps 流程，即使是最好的 SBOM 提供商也無濟于事。通過 SBOM 來發現軟體供應鍊中的新漏洞對企業來說十分有價值，但如果企業并沒有制定和執行相應的 SBOM 使用流程，那 SBOM 中的資訊就隻是目錄中的檔案毫無意義。

SLSA 與 SBOM 的關聯