軟體物料清單 (SBOM) 的價值
已發表: 2023-11-28如果您在過去的一年花了不少時間思考供應鏈安全，您可能熟悉術語「軟體物料清單」（縮寫為 SBOM）。 最簡單的形式是，SBOM 可以與軟體的成分清單進行比較。 然而，實際上，它要複雜得多。
在當今數位驅動的企業中，高度依賴軟體經銷商、開源工具和白標應用程序，擁有軟體物料清單的價值怎麼強調都不為過。
定義 SBOM：什麼是軟體物料清單 (SBOM)？
軟體物料清單是用於建立產品的基本組件（如程式碼資源）的清單。 它提供機器可讀的資訊和詳細信息，概述供應鏈中各個軟體元素之間的連接。
SBOM 本質上是關於人們所使用的數位「材料」的完整性，重點是信任和安全。 他們可以識別軟體的組成部分、這些文件的來源、它們的建構方式以及它們是否由受信任的個人安全簽署。
SBOM 是軟體開發人員和消費者可以用來增強軟體開發和分發生命週期的信心和可信度的工具。
Gartner 估計，到2025 年，為關鍵基礎設施開發或採購軟體的組織將有60% 必須使用SBOM，這一比例較2022 年的不到20% 大幅上升。讓我們來看看原因，以及軟體帳單的價值到底是什麼。材料。
SBOM 與網路安全：為什麼維護軟體物料清單至關重要
在公營和私營部門，網路攻擊現在都非常普遍。 2022 年下半年，針對政府部門的入侵數量與 2021 年同期相比激增 95%。
網路攻擊預計對全球經濟的影響將從 2022 年的 8.44 兆美元大幅上升至 2027 年的 23.84 兆美元。
這就是為什麼企業、網路安全倡導團體甚至政府都在推動 SBOM 作為數位基礎設施的重要組成部分，而不是錦上添花。
事實上，美國於 2021 年 5 月發布的題為「改善國家網路安全」的第 14028 號行政命令 (EO) 強制要求使用 SBOM 來增強美國聯邦資料庫的安全性。 它使任何與政府機構合作的軟體提供者都必須遵守軟體物料清單。
最終，如果公司不知道其軟體內部有什麼，他們就無法完全理解或評估它對公司或可能的下游客戶帶來的風險。
SBOM 的用例
除了讓您了解第三方軟體，從而更輕鬆地應對供應鏈攻擊之外，軟體物料清單還有助於：
加強買賣雙方關係
軟體開發人員及其使用者都需要對他們所使用的軟體有信心。 個人可以使用 SBOM 中包含的元資料來驗證軟體的完整性，並快速識別可能影響其係統和流程的故障或易受攻擊的元件。
同樣，SBOM 可以強調軟體開發人員創建安全、最先進的軟體所需採取的安全措施。
進行更全面的漏洞分析
公司可以檢查 SBOM 組件是否有漏洞。 如果有問題，他們也會注意要修正哪些依賴項。 漏洞是一種缺陷，惡意行為者可以利用該缺陷來破壞軟體或損害其運作的系統。
SBOM 可以確保正在使用的軟體定期更新並保持最新狀態。 如果沒有，您可以僅對過時的組件進行風險分析，而不是浪費資源來審查整個軟體。
提供更高品質的軟體
正如一句老話所說，「說你所做的，做你所說的」同樣，創建和評估 SBOM 的行為通常可以幫助開發人員確定軟體建置是否真正處於最佳狀態。
它是否一致且可重複？ 產生的 SBOM 是否反映了工程師認為軟體中包含的內容？ 或者說，是否存在鴻溝？ 大多數 SBOM 產生器至少會發現一些供應商不知道的軟體項目，這使他們能夠提高軟體品質並僅發布最佳版本。
改進採購決策
使用第三方軟體提供者提供的 SBOM 使採購經理能夠做出更明智的軟體採購決策。 透過軟體物料清單，IT 採購專家可以在購買前深入了解軟體的內部結構，了解其功能。
如果 SBOM 在購買前不可用，您可以在購買後的合理時間內（在供應商鎖定設定之前）利用此用例，並在必要時切換提供者。
建構可互通的企業系統
企業架構師負責建構公司的技術框架。 與建築建築師一樣，如果您掌握了手邊資源的每個元素，那麼建立技術堆疊就會簡單得多。 對於合併和收購尤其如此，架構師無法完全了解軟體的來源、功能和限制。
加強安全事件回應
SBOM 可以作為事件調查結果和建議的驗證——出錯的方向指標。 作為支持證據，SBOM 協助調查事件並評估其對並發系統或早期系統版本的影響。
在事件發生期間和之後，SBOM 還可以促進協作者、受影響群體和客戶之間的互動。
驗證 SBOM 枚舉的內容在傳播時相當準確，且不存在已識別或未解決的漏洞是 SBOM 在事件回應管理中的進一步應用。
這可以減少面臨資料外洩或同等嚴重事件的公司的法律風險和責任。
企業使用 SBOM 的注意事項：如何最大化其價值
供應商有責任組裝、格式化並提供完整的軟體物料清單以供您使用。 然而，獲得 SBOM 還不夠；還需要獲得 SBOM。 企業需要一種治理策略來將 SBOM 路由到最有價值的用例。
了解哪些供應商發送 SBOM 請求
由於資源通常具有固定的使用限制，因此您需要從業務影響分析開始，以確定最重要的服務提供者和商業現成或 COTS 軟體解決方案。
對於某些具有嚴格安全標準的企業，所有對組織資料有任何影響的供應商都需要提交 SBOM。 對於其他各方來說，也許只有關鍵服務提供者的子集需要參與此過程。
同樣重要的是要考慮供應商的專業水平。 與鬥志旺盛的新創公司相比，成熟的企業供應商將更願意滿足您的需求。
決定 SBOM 更新的節奏並使用自動化
您需要提交 SBOM 的規律性也需要考慮。 在某些行業中，每當軟體更新時，客戶可能會要求更新。
對於 SaaS 平台，這種情況可能會持續發生（每小時或每天），但這種頻率會使供應商承擔 SBOM 資料收集和交付職責的負擔過重。 通常，最好按計劃的時間間隔（每天、每個新版本等）請求產品的 SBOM「概覽或快照」。
驗證您的合約是否包含用於 SBOM 交付的正式服務等級協定 (SLA)。
建立 SBOM 交換和版本控制工作流程
充滿 JSON 和 XML 檔案的郵箱是一種無效的資料管理方式。 組織至少需要一種結構化方法來監視和監督每個 SBOM 的版本。
理想情況下，您需要一個能夠攝取、解碼和評估所包含資訊的系統。 SBOM 資料可以由 Anchore 和 Mend.io 等平台取得，以發送自動警報並執行自動安全分析等功能。
下一步
為了進一步加強組織的安全協議，請將 SBOM 與漏洞管理工具連接起來。 例如，應用程式或容器掃描程式可以使用 SBOM 資料來搜尋已識別的漏洞和風險。
隨著網路攻擊頻率的增加，供應鏈安全現已成為所有企業的重要考量。 軟體物料清單 (SBOM) 是一種非常有用的工具，可協助組織識別和監控軟體元件。 它還可以讓用戶充分了解潛在的安全或效率問題。
接下來，利用 Splunk 關於安全性超越合規性的最新見解來制定您的 SBOM 策略。 如果你喜歡閱讀本文，請點擊頂部的 Facebook、Twitter 或 LinkedIn 按鈕在社群媒體上分享！