什麼是軟體物料清單（SBOM）？

大約在去年的這個時候，也就是 2023 年，美國證券交易委員會發布了一則關於起訴一家總部位於德州奧斯汀的軟體公司的新聞稿。這起訴訟呼應了一項讓全球各地軟體公司困惑不已的問題——軟體供應鏈安全。網路 threat actors 一段時間以來一直在鎖定軟體供應鏈，利用如 Log4j 框架中的漏洞來安裝惡意軟體。

對供應鏈安全日益增加的關注，是 Software Bill Of Materials (SBOM) 在官方網路安全行政法規中逐漸占有一席之地的主要原因。軟體供應鏈通常相當複雜，且涉及多個流程。SBOM 透過列出這些流程直接互動的不同元件與相依性，協助提升供應鏈的可視性。因此，若要有效制定軟體供應鏈風險管理策略，我們必須了解 SBOM 及其涵蓋範圍。

SBOM（軟體物料清單）簡介

軟體物料清單（SBOM）是軟體各種組成部分的詳細清單，包括其開源元件、程式庫及其相互關係。其理念是讓利害關係人能夠徹底了解軟體所包含的一切，從而在網路安全情境中確保透明度。隨著軟體開發與交付方式的轉變，已出現各種複雜性，使網路攻擊者得以想出具創意的行動方式。因此，SBOM 是一項不可或缺的安全防護機制，能讓我們對應用程式具備一定程度的可視性。

為什麼 SBOM 對網路安全至關重要？

當拜登總統在其關於改善網路安全的行政命令中強調 SBOM 時，這是基於對惡意活動所鎖定之供應鏈漏洞的認知。像 SBOM 這樣的巢狀清單，本質上會將軟體拆解為其組成要素，並協助識別這些漏洞。以下是使 SBOM 對網路安全至關重要的三種方式：

• 軟體透明度： SBOM 可協助利害關係人識別軟體中是否存在任何過時或高風險元件。例如，如果存在過時的加密程式庫，或像 Log4j 這樣的記錄框架，安全專家便能輕鬆識別相關風險。
• 追蹤開源元件： 許多現代軟體解決方案都鼓勵整合開源元件與程式庫。這些元件未必總是經過安全性檢查，因此 SBOM 可協助追蹤其潛在風險。
• 相依性評估： 雖然某些元件表面上可能不會構成任何網路安全威脅，但它們對其他元件或程式庫的相依性可能會。因此，SBOM 也能協助安全專家檢視這些相依關係，並識別任何安全缺口。
• 供應鏈安全： 在 supply chain 中，針對各種軟體元件安全態勢的透明度，有助於確保能主動制定安全策略，以防範潛在利用。SBOM 為買方提供所有必要資訊，使其能夠制定這些供應鏈安全策略。
• 合規管理： SBOM 也可協助利害關係人評估軟體解決方案及其元件是否符合法規要求。隨著醫療保健、金融科技、國防等各產業法規日益嚴格，任何軟體元件的合規失敗都能被輕易偵測。

SBOM（軟體物料清單）的關鍵組成要素

NTIA’s report，依據總統的行政命令，提出了 SBOM 中三個彼此相關的組成部分，這些部分被認為可提供軟體所需的透明度。這些「最低要素」可提供軟體技術與功能藍圖的詳細視圖，使其可供進行全面的安全評估。

• 資料欄位： 此要素可在正式的 SBOM 結構中確認軟體元件的詳細資訊。資料欄位包括供應商名稱、元件版本以及相依關係等，有助於追蹤潛在的安全漏洞。

• 自動化支援： 自動化支援提供所需的資料格式，使 SBOM 資料可被輕鬆瀏覽，並讓軟體元件具備機器可讀性。這是確保更快速且自主進行軟體稽核的必要要素。根據該報告，CycloneDX,  SPDX, and SWID tags 是三種可接受的格式。

• 流程： 這些是必要的實務做法，可協助將 SBOM 的產生與管理納入軟體的安全開發生命週期中。這些做法規範了 SBOM 的各個面向，包括其產生頻率、所納入元件與相依性的深度，以及已知／未知相依性等。

實作 SBOM（軟體物料清單）的好處

一項 survey in 2022 顯示，跨產業有 53% 的企業認為 SBOM 是有助於報告與合規的有效工具。對 SBOM 如此正面的接受度，只能歸因於這些清單本身所具備的細節關注。正是這種對細節的關注，進而帶來了 SBOM 的諸多好處：

• 供應鏈整體透明度： SBOM 所記錄的資料欄位與關係，有助於詳細掌握整個軟體供應鏈。軟體元件的不同版本、它們在軟體中的相依性與相容性，以及其安全風險，都能被輕鬆識別與分析。
• 一致的安全態勢： 即使是根據其 SBOM 顯示可能存在風險但仍被採購的軟體，安全管理員也能更充分地為任何漏洞做好準備。可根據 SBOM 採取主動措施，以降低任何安全風險。
• 合規管理： 雖然 SBOM 本身是一項法規要求，但它也能協助利害關係人遵循針對軟體特定元件所制定的嚴格法規。此外，透過定期稽核，SBOM 也能協助識別任何合規偏差。
• 第三方威脅： 軟體中由開源第三方元件帶來的任何安全風險，都能在 SBOM 的協助下輕鬆追蹤。即使供應商有意或無意忽略了某個安全漏洞，SBOM 也能協助將其追溯到肇因的第三方元件。

如何建立與管理 SBOM？

目前已有工具可用來建立包含所有必要要素的 SBOM。這類工具的核心功能，是將其對軟體元件的分析轉換為所需的任何 SBOM 標準，例如 SPDX、CycloneDX 等。這些 SBOM 產生工具也能協助利害關係人追蹤任何過時的相依項、授權，以及其他可能導致安全漏洞的相關面向。以下說明這些工具的運作方式：

• 步驟 1 – 將 SBOM 工具整合至 CI/CD 管線： 為了記錄軟體程式碼中的各種元件，SBOM 工具需要與 CI/CD 管線整合。這些工具可依便利性安裝於地端或雲端環境。
• 步驟 2 – 掃描程式碼儲存庫： 接著，工具會掃描程式碼，以識別軟體中的不同元件、程式庫、開源框架等。
• 步驟 3 – 轉換程式碼分析結果： 一旦掃描程式碼庫中的所有元件與相依性後，資料便會依需求轉換為其中一種標準 SBOM 格式。
• 步驟 4 – 產生 SBOM： 翻譯後的 SBOM 資料最終可匯出為 XML 或 JSON 格式，以供進一步審查。NTIA 報告要求每次軟體元件有更新時，都必須產生新的 SBOM。

SBOM 標準與指南

用於產生 SBOM 的標準與指南，有助於在涵蓋軟體元件、程式庫等巢狀清單所有面向的同時，維持 SBOM 結構的一致性。這些指南也有助於推動 SBOM 的自動化產生與處理。

• System Package Data Exchange (SPDX): 這項開放標準有助於建立可讀的語言，並可轉換為 XML、JSON、YAML 等檔案格式。此標準可透過蒐集建立資訊、檔案資訊、套件資訊等資料，在開發與部署期間有效描繪不同的軟體元件。
• CycloneDX: 此格式發布時即專注於安全性與 SBOM 的自動化產生。其輕量化規範可確保對軟體元件、其與外部服務的互動，以及彼此之間關係進行全面分析。這項開源標準也非常適合那些經常被修改與重新散布的動態開源元件。
• Software Identification Tags (SWID Tags): SWID 標籤由 ISO 於 2012 年制定，旨在於軟體元件的整個生命週期中進行追蹤。這些標籤—即主要、修補程式、語料庫與補充標籤—會在軟體安裝後加入，以提供安裝程式、安裝、修補程式及軟體元件其他面向的詳細資訊。

SBOM（軟體物料清單）挑戰

SBOM 的挑戰大多出現在其產生過程，因為它具有深度結構化且正式的特性。這些挑戰的表現如下：

• SBOM 工具的成熟度: 雖然這些工具持續演進，以符合標準化的 SBOM 格式與結構，但仍存在一些落差。此外，由於缺乏良好的介面、介面與互通性等因素，不同利害關係人在操作這些工具時也會感到相當棘手。
• 採用與整合緩慢: 仍有第三方供應商未遵循 SBOM 要求，因此導致 SBOM 資源的採用與整合出現延遲，尤其是在開源軟體方面。
• SBOM 產生的持續性: 企業仍未能將 SBOM 產生變成持續性流程，使其在 SDLC 的不同階段發生。雖然這是大多數處理 SBOM 的企業所追求的目標，但其中許多企業尚未達成。
• 其他安全疑慮: 也有安全專家聲稱，全面性的 弱點管理 無法保護數位生態系免受外部威脅。組織需要優先排序想要處理的弱點，並據此制定策略。由於額外的複雜性，在使用 SBOM 時要做到這一點相當困難。

確保有效使用 SBOM 的最佳實務

產生 SBOM 本身已是一項良好實務。最佳作法是持續且貫穿整個 SDLC 地產生它。以下還有一些可促成此目標並最大化 SBOM 在供應鏈安全中效用的實務：

• 及早產生並定期更新: 務必在 SDLC 中盡可能早的階段產生 SBOM，如此一來，每個新增的相依性都能從一開始就被記錄。定期更新 SBOM 可確保各種軟體元件的所有建置與發行版本都被妥善記錄在清單中。
• SBOM 自動化產生: 由於自動化支援是 SBOM 的重要組成部分，因此使用自動化資源來產生它是合理的。自動化也能確保在整個 SDLC 中定期產生清單。
• 標準化格式: SPDX 或 CycloneDX 等格式具備所需的深度，能真正擷取對安全敏感的 SBOM 資料。使用這類標準化格式可確保該清單的互通性與機器可讀性。
• 版本控制: SBOM 中的版本控制可確保軟體元件中任何新建置或新發行的變更，都能輕鬆追蹤以進行安全評估。這也讓 SBOM 在管理相依性時更具可追責性。

SBOM 使用案例

雖然其主要用途是提供對軟體弱點的關鍵洞察，但 SBOM 也可支援許多使用案例，其中包括：

• 軟體安全: SBOM 可協助安全團隊精確識別軟體程式碼中的脆弱部分。團隊可利用它找出並處理軟體中任何容易遭網路攻擊者利用的部分。

• 供應鏈安全: 包括美國及部分歐洲國家政府在內的許多政府機構，已要求在軟體供應鏈中納入 SBOM。專家預測，不久後終端客戶也可能取得這些資訊。

• 採購便利性: 由於各產業企業都對網路安全事故感到憂心，SBOM 能為尋找軟體解決方案的採購團隊帶來信心。所提供的透明度有助於在雙方之間建立信任。

• 開發便利性: 由於 SBOM 包含相依性以及軟體元件之間關係的詳細拆解，開發人員更容易在不干擾既有功能的情況下開發新元件。

SBOM 與 SCA 的差異

毫無疑問，Software Bill of Materials (SBOM) 與 Software Composition Analysis (SCA) 具有重疊的功能，可協助理解軟體的不同組成要素。因此，兩者之間的明智選擇取決於您希望將其用於軟體生命週期哪個範圍。

以下是企業領導者為做出該選擇需要了解的內容：

BOM 與 SBOM 之間的差異

BOM 和 SBOM 在性質上聽起來非常相似，因此人們經常會將兩者混淆。然而，它們分屬非常不同的領域。BOM 是與製造領域較相關的清單，而 SBOM 則在軟體工程中扮演非常明確的角色。以下說明決策者如何區分兩者：

AI-Powered Cybersecurity

Elevate your security posture with real-time detection, machine-speed response, and total visibility of your entire digital environment.

Get a Demo

結論

作為網路安全行政法規的一部分，SBOM 已在軟體生命週期中占有關鍵地位。軟體供應鏈安全是其可支援的多種使用案例之一。隨著分散式架構、程式碼化基礎架構以及廣泛網路的發展，軟體解決方案如今正支援比以往更複雜的業務使用案例。SBOM 的關鍵元件與標準格式，使其成為抑制如 Uber 和 Solarwinds 這類事件的強大助力。

根據我們在這篇部落格中的討論，企業領導者與安全專家可以遵循最佳實務來自動化產生 SBOM，並將其用於供應鏈安全。

SentinelOne 可協助您運用 SBOM 等功能來保護您的軟體供應鏈。進一步了解我們的專業能力，請見 此處。