在此前的多篇文章中，我們已經詳細地介紹了軟件物料清單（SBOM）對于保障軟件供應鏈安全的重要性以及一些注意事項。在本文中，我們將會更深入地介紹SBOM，包括最低要求元素、格式、使用場景以及如何對其進行管理等。

SBOM所包含的元素

2021年年中，NTIA發布了軟件物料清單（SBOM）的最少必需元素。這些元素包含以下三類：

• 數據字段：每個軟件組件的基本信息
• 自動化支持：能夠自動生成機器可讀格式的SBOM
• 實踐和流程：SBOM 應該如何及何時生成和分發

所需元素的目的是為 SBOM 使用者提供他們所需的信息，以管理漏洞、清點軟件組件，并監管許可證合規性。

數據字段

根據NTIA的說法，這一字段是為了“充分識別這些組件以在整個軟件供應鏈中跟蹤它們，并將它們映射到其他相關的數據來源，如漏洞數據庫或許可證數據庫”。

7個必要的數據字段如下：

• 供應商名稱： 開發該軟件組件的個人或組織
• 組件名稱： 給一組軟件命名，通常由供應商決定
• 組件版本： 一個標識符，指定軟件與以前版本的變化。同樣，這是由供應商決定的
• 其他獨特標識符： 像Software Identification （SWID）標簽、Package Uniform Resource Locators （PURL）、Common Platform Enumeration（CPE）或類似的標識符，可以幫助SBOM 消費者在關鍵數據庫中找到組件
• 依賴項關系： 表示軟件組件是如何結合在一起的，如，某個上游組件包含在某個軟件中
• SBOM數據的作者： 生成SBOM元數據的實體，可能是軟件供應商或其他個人、團體
• 時間戳： SBOM 生成的日期和時間

自動化支持

下一組最低要求元素是指 SBOM 數據在整個軟件生態系統內部以及跨組織通信的方式。這一要求的目標是為了確保 SBOM 數據真正可用——不僅僅是機器可讀，還能夠讓人直接閱讀，而且它的傳輸格式是可互操作的。

要達到這一目標，NTIA 認證了3個交付格式來生成和消費 SBOM。至關重要的是，向聯邦政府銷售軟件的組織必須以這三種格式之一傳送 SBOM，以符合網絡安全行政命令的要求。

這3個格式是：

• Software Package Data Exchange (SPDX)
• Software Identification (SWID) Tags
• CycloneDX

在后面一節，我們將會對這3個格式進行詳細介紹。

實踐和流程

最后一組SBOM最低要求元素涉及生成和申請SBOM的具體操作。具體而言，實踐和流程部分包括以下6個方面的要求：

• 頻率（Frequency）： NTIA規定，“如果軟件組件隨著新的構建或發布而更新”，企業應該生成新的SBOM。此外，供應商在以下情況下也需要生成新的SBOM：
  1）需要糾正原始版本中的錯誤
  2）了解有關軟件組件的新細節
• 深度（Depth）： 合規的SBOM需要包含：
  1）所有頂層組件
  2）所有間接依賴關系。如果SBOM作者不能包含所有間接依賴關系，則需要囊括足夠的信息，使消費者可以遞歸地找到他們。
• 已知的未知因素（Known Unknowns）： 在SBOM作者沒有提供完整的依賴關系圖的情況下，他們需要說明這是因為：
  1）該組件沒有進一步的依賴關系，或者
  2）不知道是否存在其他的依賴關系。
• 分發和交付： 這一部分分為幾個環節，都是關于確保SBOM以可消化的格式快速交付。首先，SBOM被要求以“及時”的方式提供（盡管沒有設定天數或周數）。其次，他們必須有“適當的”角色和訪問權限。最后，SBOM可以與產品的每個實例一起分發或者以其他可訪問的方式提供，如公開的網站。
• 訪問控制： 如果供應商想將SBOM數據的訪問限制在某些客戶或用戶，他們需要提供這種訪問控制的條款。此外，供應商需要提供 “具體的允許和便利”，以便SBOM消費者能夠將數據納入其安全工具。
• 容錯程度： 網絡安全行政命令和指導SBOM創建的法規目前尚不成熟，因此，各組織被指示要對（無意的）錯誤或遺漏給予理解。

SBOM交付格式及規范

企業可以通過各種不同的格式創建和發布軟件物料清單（SBOM）。對于一個想要在其網站發布 SBOM 的企業來說，HTML 是一個合理的選擇。如果 SBOM 中包含了文檔或者源代碼，那么純文本也許是更佳選項。此外，還有 Markdown、PDF、CSV等格式可供使用。

除了這些常見的格式外，還有幾種專門為交付SBOM而設計的格式，如 SPDX（軟件包數據交換），SWID Tags（軟件識別）以及Cyclone DX。

SPDX

SPDX是由 Linux 基金會運營的項目，旨在標準化企業共享和使用SBOM中信息的方式。SPDX 捕捉與provenance、許可證和安全相關的數據，下圖展示了 SPDX 文檔中所包含的數據：

該格式支持以下文件類型：

• YAML
• JSON（你可以在 GitHub 上找到SPDX的JSON schema：https://github.com/spdx/spdx-spec/tree/development/v2.2.1/schemas）
• RDF/XML
• tag:value flat text file
• .xls 電子表格

Seal 軟件供應鏈防火墻可以直接生成SPDX格式的SBOM文件，歡迎訪問下方鏈接申請產品試用：seal.io/trail

SWID Tags

SWID 是一個標準化的 XML 格式，可以識別軟件產品的組成部分并將其與上下文結合。4種類型的 SWID Tags 在軟件開發生命周期中：

• Corpus Tags： 識別和描述在安裝前階段的軟件成分。根據 NIST 給出的定義，corpus tags 是指“軟件安裝工具和流程的輸入”
• Primary Tags： 在軟件產品安裝后對其進行識別和關聯
• Patch Tags： 顧名思義，patch tags 可以識別和描述補?。ǘ皇?span id="jpd55j5" class="candidate-entity-word" data-gid="15027706">核心產品本身）。此外，patch tags 包含了補丁和其他產品或補丁之間的上下文關系信息。
• Supplemental Tags： SWID 格式僅允許 tag 創建者修改 corpus、primary和patch tags。但是 Supplemental Tags 可以讓軟件用戶及軟件管理工具在本地添加有益的上下文信息，如許可證密鑰以及相關方的聯系信息。

在決定將哪些標簽和具體的數據元素納入其產品時，各企業有一定程度的靈活性。在SWID規范中，除了幾個必須的字段外，其他的元素和屬性都是可選的。

最終，一個最低限度的有效和符合要求的標簽只需要描述軟件產品（如名稱和標簽ID）和創建它的實體的少數元素。關于SWID標簽數據元素的最全面和最新的信息，建議查看ISO/IEC 19770-2:2015標準全文：
https://www.iso.org/standard/65666.html

Cyclone DX

Cyclone DX 是一個輕量級軟件物料清單標準，旨在用于應用安全上下文和供應鏈組件分析。換言之，它旨在實現與SPDX、SWID以及其他所有SBOM交付格式類似的目標——提供構成一個應用程序的軟件組件的關鍵信息。

Cyclone DX 支持以下4種類型的數據：

• 物料清單元數據： 關于應用/產品本身的信息——供應商、制造商、SBOM所面熟的組件以及用于匯編SBOM的任意工具
• 組件： 完整的專利清單及開源組件清單，包含許可信息
• 服務信息： 軟件可能調用的外部API、終端URI、身份認證要求和信任名單
• 依賴項： 包含直接依賴項和間接依賴項

誰是SBOM的目標受眾？

歷史上，SBOM主要由合規團隊用來審計、監控許可證以及遵守行業特定規范，但隨著軟件供應鏈攻擊的上升，包括 SolarWinds 黑客事件和去年年末的 Log4Shell 漏洞，SBOM 的使用擴展到了安全和開發團隊。

安全團隊

對于安全團隊來說，SBOM扮演著十分重要的角色，特別是需要進行漏洞掃描的時候。因為掃描SBOM庫比從頭開始掃描整個基礎設施更簡單也更快，在發生零日事件時，每一分鐘都很重要。此外，安全團隊也會利用 SBOM 所提供的信息（如風險所在位置）來確定問題修復的優先級，并針對特定組件創建策略，如供應商的選型、可引入的版本或者軟件包類型等。

開發團隊

開發團隊可以使用 SBOM 來跟蹤他們所開發、管理和運維的各個軟件中的組件，包括開源組件、商業組件和自研組件。并且 SBOM 還能協助開發團隊管理依賴項、識別安全問題以減少其重復的工作，還能確保開發人員使用的都是經過審批的代碼和可信任的源。

SBOM 的應用場景

顯然，有許多令人信服的理由推動企業創建SBOM，并且企業可以為所有產品創建SBOM，每個新版本都可以更新一版SBOM。此外，在一些特定場景中SBOM會最大限度地發揮其作用。

• 融資、并購和IPO： 軟件物料清單是收購、IPO或融資過程中技術盡調的重要一環。相關利益方會要求獲取文檔以更好地了解產品中的軟件成分以及許可證合規性、安全性或代碼質量風險。
• 客戶要求： 由于全球范圍內的企業都將防止軟件供應鏈風險的優先級提高了，因此未來會有越來越多的企業要求采購環節中需要提供SBOM。
• 向下兼容： 維護大量舊軟件的公司經常需要進行OSS包的更新和升級。當然，如果對這些舊產品中的開放源碼軟件有一個完整的清單，做起來就容易多了。

全面管理 SBOM 的最佳實踐

隨著SBOM被迅速接受，行業領導者已經開始開發創建、管理和使用SBOM 的方法。這些實踐跨越了軟件生命周期的各個關鍵階段：

1、在統一的存儲庫中存儲和管理 SBOM
雖然單個開發或應用團隊可以將SBOM與他們的代碼構件一起存儲在存儲庫中，但安全團隊必須在所有應用和開發團隊中維護一個統一的SBOM存儲庫。當新的漏洞或安全事件出現時，安全團隊和CISO需要快速查詢所有軟件的SBOM并即時評估影響，而不是分別從每個團隊中獲得單獨的評估報告，或者不得不浪費事件從頭開始查找和重新掃描他們所有的應用程序。此外，滿足監管要求或合規標準也需要一個集中的存儲庫，用于生成報告和其他的合規活動。

2、要求所有進入供應鏈的軟件提供SBOM
企業如果需要對所使用的軟件保有可見性，那么收集 SBOM 信息以分析軟件成分或應用是十分重要的。如果是第三方商業軟件，那么軟件供應商應該提供必要的 SBOM，并將其納入你的 SBOM 資源庫。

當使用的是開源組件來構建自定義軟件時，在將其引入開發流程前企業應該直接掃描開源構件（如容器鏡像）或者開源代碼倉庫。在某些情況下，開源項目可能會提供一個簽名的 SBOM，這可以讓企業將他們生成的 SBOM 與社區提供的 SBOM 進行比較來進行驗證。

3、為每個開發環節和構建生成SBOM
各行各業的企業正在定制軟件以迎合其獨特的市場需求。大部分軟件都由大量的開源代碼組成（根據不同的應用程序，開源代碼的占比在50—90%之間）以及內部開發的代碼和第三方庫。由于在構建階段開源代碼常常會引入額外的依賴項，因此在開發流程中的每一步及每一次構建軟件時都掃描您的軟件是至關重要的。這可以讓您檢測出意料之外的SBOM變更，這些變更可能由新依賴項或代碼修改導致的。這些 SBOM 需要標記為特殊組件或他們所代表的應用程序。

4、為你所部署或交付的每個軟件版本創建綜合的SBOM
無論您是將軟件交付給客戶，還是幫助客戶、員工、合作伙伴進行部署，您應該創建一個綜合的SBOM，并標記為該版本軟件的變更。這提供了一個追蹤機制，可以讓企業快速評他們生產的應用或組件的安全狀況，同時評估新漏洞對此前開發的影響。對于將軟件售賣或提供給外部用戶的企業，您也可以提供必要的可見性和“信任報告”給軟件的下游用戶。

5、 將自動化應用于策略執行和告警

借助中心化的SBOM倉庫和有效的SBOM管理能力，企業可以利用一個自動的策略引擎來應用策略規則，如同步特殊的監管要求或合規標準。同時，還可以應用任意內部要求。自動告警可以提醒您新漏洞或違反策略的行為，如此，受影響的團隊可以快速修正重要問題并阻止受影響的鏡像被部署。

借助工具生成SBOM

可以肯定的是，軟件物料清單將在業務開展方式中發揮越來越重要的作用。但是，考慮到制作SBOM所需的數據量，僅通過人工將這些碎片組合在一起是相當具有挑戰性的。Seal 軟件供應鏈防火墻可以生成SBOM數據，并可以跟蹤SBOM的變化以進行漏洞匹配，及時發現軟件供應鏈中的安全風險。