在本系列的上一篇文章中，我分享了頂級軟體供應鏈攻擊的案例研究，並向您介紹了 SBOM 作為預防措施。在這篇文章中，我將重點放在 SBOM，並 論 SBOM 作為新的安全勢在必行的出現、其架構、標準以及對抗供應鏈 南非電話號碼數據 攻擊的幫助。缺乏 SBOM 策略的企業會落後於競爭對手；參與 SBOM 運動對於獲勝至關重要！如果您與軟體行業有任何關係，並且想獲得這些信息，那就跟我來吧！
底漆
軟體物料清單 (SBOM) 是組成軟體應用程式的所有元件、函式庫和其他依賴項的列表，以及與每個元件關聯的版本、許可證和漏洞的資訊。它們是正式的結構化文檔，詳細說明了軟體產品的組件及其供應鏈關係。最重要的是，SBOM 是軟體的成分清單或營養標籤。
隨著組織越來越依賴開 在杜拜出售二手車之前的十大技巧 源和第三方軟體元件來建立和維護其應用程序，SBOM 變得越來越重要。如果必須充分管理和更新這些元件，則可能會引入安全漏洞。它們為組織提供了一種了解其應用程式中使用了哪些開源和第三方元件並識別和解決任何安全漏洞的方法。
在特定情境下，為了遵守要 資料庫資料庫 求組織揭露其產品中開源和第三方軟體使用情況的法規和行業標準，必須產生和發布 SBOM。
美國行政命令：SBOM 授權
2021 年 5 月 12 日，拜登總統發布了《關於改善國家網路安全的行政命令 (14028 )》。由於這項立法， 任何向聯邦政府提供軟體的供應商 很快都將被要求提供 SBOM，以幫助保護軟體供應鏈並降低風險。
產生並向客戶和審核員提供 SBOM 作為組件透明度的一種手段已成為企業的當務之急。由於它不再是可選的，因此企業領導者、軟體生產商、消費者和營運商必須深入了解並徹底了解其含義。
SBOM標準
一些建議的標準如雨後春筍般湧現，包括 CycloneDX、SPDX、SWID 等。
SPDX（軟體包資料交換）是一種用於通訊軟體包元件、許可證和版權的標準格式。它通常用於記錄專有軟體產品中包含的開源元件。 SPDX 檔案可以被人類和機器輕鬆讀取和理解，從而可以輕鬆追蹤和管理軟體專案中的開源元件。 SPDX 格式由 Linux 基金會支持，您可以在此處了解更多資訊。
CycloneDX是用於建立軟體物料清單檔案的開源標準。它與 SPDX 類似，它記錄了與軟體包相關的組件和許可證，但它是專門為軟體供應鏈安全而設計的。與 SPDX 相比，CycloneDX 是一種更輕量級的格式，SPDX 旨在更詳細。 CycloneDX 格式受 OWASP 支持，您可以在此處了解更多資訊。
選擇標準
SPDX 和 CycloneDX 都用於記錄軟體包的組件和許可證。儘管如此，SPDX 更專注於管理軟體專案中的開源元件和許可視圖。另一方面，CycloneDx 更關注軟體供應鏈安全，並標記有豐富的安全元數據，因此它可以有益於並可擴展至許多高級安全洞察用例。由於其豐富的元數據，CycloneDX 格式可能會變得複雜和冗長，作為權衡。 CycloneDX 設計提供了 SBOM 結構的靈活性，以平衡冗長和簡單性，讓組織可以選擇所需的詳細程度。因此，CycloneDX 可以是基於用例和配置的輕量級且詳細的格式。
您必須根據組織的獨特需求選擇合適的格式。使用下面的圖 2 作為快速總結，我們可以看到這兩個標準的比較：
圖 2：比較 SPDX 和 CycloneDX 標準
SBOM架構
典型的 SBOM 架構可以佈置為具有以下關鍵元素的樹狀依賴圖：
- 元件清單： 有關軟體中使用的元件、庫和其他資產的信息，包括版本號、許可證和漏洞。
- 依賴關係映射：不同元件和庫之間的關係圖，顯示它們如何相互依賴以及對一個元件和庫的變更如何影響另一個元件和庫。
- 許可證管理：還應包括有關用於確保軟體遵守法律和道德義務的元件和庫的許可證的資訊。
下面的圖 3 顯示了 Acme 應用程式的概念 SBOM 樹
圖 3：SBOM 架構（圖片來源：NTIA）
SBOM 的架構應該是靈活且可擴展，使其能夠不斷更新以適應不同類型的軟體和詳細程度，從而滿足動態供應鏈的需求。
SBOM 生成器
典型的 SBOM 可以透過兩種方式產生 – 在建置過程中或使用軟體組合分析工具進行建置和部署後。Trivy和Syft是許多其他生成器（包括開源生成器和商業生成器）中兩個值得注意的開源生成器。兩者都使用 CycloneDX 格式。還要注意的是，並非所有 SBOM 都能同等產生。根據其實現，每個生成器可能會比其他生成器更好地選擇一些語言庫。可能需要多次運行幾種不同類型的生成器才能得出全面的見解。
多重 SBOM 確保準確性
當一個還不夠時，可以使用多個。若要建立軟體成分的全面視圖，請尋找用於合併多個 SBOM 結果的工具。使用多個生成器時，合併異質輸出和標準化是一項至關重要的任務，而這正是 KubeClarity 的 亮點。 KubeClarity 可以設定 SBOM 產生器並行運作並統一結果以產生更準確的文件。
KubeClarity 提供了多個 SBOMS 的包裝器，從多個開源分析器編譯合併的 SBOM，並提供全面的 SBOM 文件報告。儘管 KubeClarity 不產生 SBOM，但它與流行的生成器集成，以便組合文件可以提供放大的輸入，可以使用漏洞掃描器進一步分析這些輸入。利用多個 SBOM 文件可以提高軟體依賴性狀況的可見性。作為擴展，KubeClarity 可以合併來自 Grype 和 Trivy 等各種來源的漏洞掃描，以產生可靠的漏洞掃描報告。
在下面的圖 4 中，請注意右列，兩個分析器（Trivy 和 Syft）發現了相同的應用程式資源。在下一個處理階段，KubeClarity 會結合這兩個離散 SBOM 的分析，並格式化合併的 SBOM，以符合每個漏洞掃描程式的輸入要求，然後再啟動漏洞掃描。
圖 4：使用 KubeClarit 進行多重 SBOM分析
掃描 SBOM 文件中的漏洞
SBOM 是達到目的的手段。雖然它們可以揭露構成軟體的所有軟體元件並提高透明度，但SBOM 文件的實際用途是將它們提供給漏洞掃描程序，然後漏洞掃描程序將分析SBOM 並產生漏洞報告，詳細說明所有已知和已知的漏洞。一旦發現漏洞，組織就可以採取行動解決它們。我們將在下一篇部落格中了解有關 CVE 和漏洞管理的更多資訊。