摘要
本報告旨在深入探討軟體物料清單(SBOM)的各種面向,包括其定義、重要性、美國政府規定的最低要素、主要的SBOM格式以及其帶來的益處。SBOM已成為現代軟體供應鏈安全與合規不可或缺的工具,尤其是在應用程式日益複雜且多由開源及專有組件構成的背景下 。
什麼是軟體物料清單(SBOM)?
軟體物料清單(SBOM)是構成特定產品的所有軟體組件(包括專有和開源)、開源許可證和依賴關係的清單。它提供了軟體供應鏈的可見性,並揭示其中可能存在的任何許可證合規性、安全性及品質風險。
由於當今的應用程式通常由許多來自不同開源和專有來源的獨立軟體組件構建而成,這增加了軟體供應鏈的複雜性。在缺乏SBOM的情況下,組織和產品相關方(製造商、營運商、採購者)難以全面了解軟體供應鏈及其潛在風險。透過提供關鍵洞察,SBOM協助組織快速識別和修復潛在的安全漏洞、履行許可要求並應用版本控制的最佳實踐。
SBOM的重要性與法規要求
BOM的重要性日益凸顯。美國拜登政府於2021年發布的網路安全行政命令中,即包含一項強制要求(針對向聯邦政府銷售產品的組織)建立SBOM的條款,進一步提升了其重要性。這項要求雖然目前主要適用於與聯邦政府有業務往來的組織,但預計各類組織都將逐步採用這些準則。
SBOM的最低要素
美國聯邦政府於2021年7月12日公布了SBOM的最低要求要素,這些要素分為三個主要領域:
- 數據欄位 (Data Fields)
- 目的:這些欄位的目標是使組件能夠充分被識別,以便在軟體供應鏈中追蹤它們,並將其映射到其他有益的數據來源,例如漏洞資料庫或許可證資料庫。
- 具體要素包括:
- 供應商名稱
- 組件名稱
- 組件版本
- 其他唯一識別碼,例如軟體識別(SWID)標籤、套件統一資源定位符(PURL)、通用平台列舉(CPE)等。
- 依賴關係:指不同軟體組件如何以及在何處結合,並能表示從軟體到其組件及潛在子組件的傳遞性關係。
- SBOM數據作者
- 時間戳 (timestamp)
- 自動化支持 (Automation Support)
- 為了密切和持續追蹤SBOM組件數據,數據需要以一致且易於消化的格式呈現。
- 美國NTIA(國家電信和資訊管理局)確定了三種組織在跨組織邊界傳輸SBOM時必須選擇的報告格式:
- 軟體套件數據交換(SPDX)
- CycloneDX
- 軟體識別(SWID)標籤
- 這些格式被選中是因為它們是人類可讀、機器可讀,並且「對於核心數據欄位可互操作並使用共同的數據語法表示」。
- 實踐和流程 (Practices and Processes)
- 這部分包括六項關於SBOM應如何及何時更新和交付的要求:
- 頻率:如果軟體組件有新的建置或發布更新,必須創建新的SBOM。
- 深度:SBOM作者應包括頂層組件及其傳遞依賴關係。
- 已知未知:如果SBOM不包含完整的依賴圖,作者應說明原因(是沒有進一步依賴,還是依賴的存在未知且不完整)。
- 分發與交付:SBOM必須及時提供,並具備適當的訪問權限和角色。
- 訪問控制:希望保留SBOM某些元素為私有的組織,需要指定訪問控制條款,包括將SBOM數據整合到用戶安全工具中的特定許可和調整。
- 錯誤容忍:由於SBOM創建的規範相對較新,SBOM消費者應對非故意的錯誤或遺漏持寬容態度。
常用SBOM格式詳解
最受歡迎且同時具備人類可讀和機器可讀性的SBOM格式是SPDX和CycloneDX。SWID標籤也是行政命令中提及的格式,但其全面性不如SPDX和CycloneDX。
- SPDX(Software Package Data Exchange)
- 由Linux基金會運行,旨在標準化組織共享和使用SBOM資訊的方式。
- SPDX捕獲與出處、許可和安全相關的數據。
- SPDX v2.3文件必須包含「SPDX文件創建資訊」,並且可以包含包資訊、文件資訊、程式碼片段資訊、其他檢測到的許可資訊、SPDX元素之間的關係資訊、註釋資訊和審閱資訊。
- SPDX SBOM可以生成為.xml、.json和.yaml等檔案格式。
- CycloneDX
- 一個綜合性的SBOM格式,起源於應用程式安全,但具有廣泛的應用案例。
- 該標準包含六個要素:
- 物料清單元數據:關於應用程式/產品本身的資訊。
- 組件:專有和開源組件的完整清單,包括許可資訊。
- 服務:軟體可能調用的外部API,以及端點URI、身份驗證要求和信任邊界遍歷。
- 依賴關係:直接和傳遞關係。
- 漏洞:可以描述多種類型的漏洞數據,包括嚴重性分數和VEX(漏洞可利用性交換)。
- 組合物:用於表示BOM元素描述的完整性。
- CycloneDX可以生成為.xml、.json和Protocol Buffers格式。
- SWID標籤(Software Identification Tags)
- 一種標準化的XML格式,用於識別和語境化軟體產品的組件。
- 在軟體開發生命週期(SDLC)的不同階段,有四種類型的SWID標籤:
- Corpus Tags(語料庫標籤):識別和描述預安裝狀態的軟體組件,作為軟體安裝工具和流程的輸入。
- Primary Tags(主要標籤):用於識別和語境化安裝後的軟體產品。
- Patch Tags(補丁標籤):識別和描述補丁,並可包含補丁與其他產品或補丁之間關係的語境資訊。
- Supplemental Tags(補充標籤):允許軟體用戶和軟體管理工具添加有用的本地語境資訊,如許可證密鑰和相關方的聯繫資訊。
SBOM的益處
現代應用程式包含大量不同的軟體組件、依賴關係和許可證,使其管理相當困難。缺乏SBOM會使風險評估、開源許可合規性盡職調查以及漏洞修復等過程變得極其耗時和痛苦。反之,SBOM在管理軟體供應鏈風險方面大有助益,具體體現在:
- 符合政府法規:協助組織遵守政府法規。
- 加速漏洞識別與修復:加快識別和修復潛在漏洞的過程。
- 滿足歸屬要求:使製造商能夠滿足使用許多開源函式庫所帶來的歸屬要求。
- 減少不必要的工作:由於供應鏈模糊不清而可能給開發團隊帶來的不必要工作。
- 提供透明度並建立信任:提升與消費者之間的透明度並建立信任。
- 發布後識別和解決損壞組件:使製造商更容易在產品發布後識別和解決損壞的組件。
- 避免業務中斷:在審計事件中避免重大的業務中斷。
軟體物料清單(SBOM)已成為管理現代軟體供應鏈複雜性的關鍵工具。透過提供組件、依賴關係和許可證的透明視圖,SBOM幫助組織有效識別和緩解安全、合規和品質風險。隨著政府法規的推動和網路威脅的日益增加,SBOM的採用將繼續深化,成為軟體開發和部署不可或缺的一部分。
參考資料:FOSSA Editorial Team, FOSSA Inc., Software Bill Of Materials (SBOM) Formats, Use Cases, and Specifications, April 22, 2021