什么是SBOM（软件物料清单）？
SBOM（软件物料清单） 是一份详细的清单，它列举了应用程序开发和交付过程中涉及的所有组件和软件依赖项。它已成为软件开发生命周期和DevSecOps流程中日益普遍且关键的部分，旨在帮助希望加强安全态势的组织识别和管理风险。
现代软件应用程序和服务通常由来自不同来源的多个组件和依赖项构建而成。它们可能包括开源软件项目、许可证、专有代码、应用程序编程接口、编程语言框架和软件库。构成现代软件的各种来源是软件供应链的一部分，它们是启用应用程序和服务的供应源。SBOM列出了所有这些组件，供组织用于改进安全和软件供应链风险管理流程。
SBOM非常类似于供应链和制造业中使用的物料清单（BOM）。BOM清点了产品中包含的所有项目，并有助于将缺陷追溯到特定部件或供应商。同样，SBOM提供了对软件内部构成的可视性，帮助组织及用户更好地了解正在使用的内容以及潜在风险可能存在于何处。
软件物料清单包含什么？
从根本上说，SBOM是构成软件应用程序或在线服务的所有组件的清单。这包括任何源代码组件和依赖项。源代码组件可以包括以下内容的列表：
- 共享对象，例如动态链接库。
- 用于不同功能的软件库。
- 应用程序中使用的开源代码。
- 应用程序运行所依赖的中间件、容器、云服务和编程框架。
SBOM与成分列表或简单清单的不同之处在于，它还应提供关于组件来源的谱系信息。现代软件开发通常遵循一个原则：一段应用程序代码依赖于另一段。因此，需要依赖关系树来帮助了解应用程序的核心基础组件。
2021年，美国国家电信和信息管理局（NTIA）在一份报告中发布了明确指南，详细说明了SBOM的最低要求要素，包括以下三个基础领域：
- 数据字段。SBOM的数据字段部分是资产清单组件，它勾勒出应用程序的依赖关系树。字段应包括组件名称、版本、许可证信息、供应商名称、作者身份以及生成SBOM数据的时间戳。
- 自动化支持。鉴于现代软件开发流程的复杂性，不建议手动创建SBOM。因此，NTIA建议SBOM的生成和数据传输至少应达到一定的自动化水平，以便其他系统能够理解和使用SBOM数据。
- 实践和流程。SBOM需要适当的流程来支持数据的持续收集。还需要定义如何生成和访问SBOM。
2024年，网络安全和基础设施安全局（CISA）发布了一份题为“构建软件组件透明度：建立通用软件物料清单（SBOM）”的报告。该报告扩展了NTIA的基础领域。CISA的报告定义了SBOM的要素和属性，并包含了如何实施SBOM的详细信息。
SBOM的类型
根据其深度、所需细节或使用场景，SBOM可以通过几种不同的方式进行分类。根据CISA的说法，SBOM可以分为以下六种类型：
- 设计型。此类SBOM在开发开始前通过列出计划的组件来创建。通常根据设计规范和预期组件创建。
- 源代码型。此类SBOM通过直接从开发环境、源文件和依赖关系中列出组件来创建。
- 构建型。此类SBOM在构建过程中创建，反映了实际编译并放入最终软件的组件。
- 分析型。此类SBOM基于观察到的组件创建。通常在软件构建后，使用第三方工具扫描可执行文件、容器和虚拟机等部分。
- 部署型。此类SBOM通过记录部署环境中的软件组件和配置信息来创建。目的是清点可用的和实际安装的内容。
- 运行时型。此类SBOM旨在仅记录在应用程序执行期间主动加载和使用的组件。
使用SBOM的好处
随着组织越来越依赖软件来运行业务关键型操作，出于以下原因，拥有SBOM势在必行：
- 改善安全态势。SBOM帮助组织识别潜在的安全风险，并使它们能够更有效地处理这些风险。
- 帮助评估依赖项和供应链风险。当发现软件漏洞时，它们通常存在于其他软件应用程序所依赖的组件中。了解组织是否面临来自第三方组件的风险是一个通常被称为供应链风险的挑战。
- 增强透明度。许多组织难以了解自己是否面临特定软件漏洞的风险。SBOM增加了对软件或服务中使用的确切组件的透明度和可视性。
- 辅助开源许可证合规。除了帮助应对供应链风险外，SBOM还可以协助组织处理开源软件许可证合规问题。不同的开源许可证可能有使用限制或要求组织共享对源代码所做的任何更改。一个结构良好的SBOM不仅揭示了底层的开源软件依赖项，还揭示了已有的许可证限制。
- 支持法规和政策合规。在2020年和2021年发生一系列供应链攻击（包括2020年3月的SolarWinds漏洞和2021年7月的Colonial Pipeline黑客攻击）之后，美国政府发布了第14028号行政命令，该命令主张美国政府机构仅与提供SBOM的软件供应商打交道（以及其他指令）。该行政命令还指示NTIA定义SBOM的最低要求，该机构在2021年7月发布的一份综合报告中定义了这些要求。
使用SBOM的挑战
尽管SBOM可以通过提供更高的可视性和更好的安全态势使组织受益，但它们也带来以下挑战：
- 与现有工作流程的整合不一致。SBOM的实施应在团队和软件供应链中涉及的各方之间保持一致。它还应该与现有的开发、合规和安全流程保持一致。
- 维护SBOM的准确性。保持SBOM的更新可能很困难，因为它需要随着软件的任何变化而维护、扩展和更新。
- 缺乏供应商支持。第三方供应商可能无法提供组织可在其SBOM中使用的关于其组件的详细信息。
如何选择SBOM工具
在选择创建SBOM的工具时，组织应确保该工具满足以下要求：
- 提供可扩展性。SBOM工具应能扩展到不同规模的项目，从小型应用到大型企业级系统。
- 与现有工作流程和系统集成。正确的工具必须能够与组织的开发和运营系统正确集成。如果该工具将用于增强安全性，则应与现有的安全工具集成。
- 满足组织的需求。所选工具必须符合组织创建SBOM的计划。
- 提供自动化能力。一些SBOM工具具有自动化SBOM生成和更新的功能。
- 提供合规特性。该工具应支持相关标准，例如软件包数据交换（SPDX）或CycloneDX，并有助于满足任何法规性的SBOM要求。
- 符合预算。SBOM工具可以是免费的、基于使用量的或基于订阅的。
如何创建软件物料清单
有多种工具可以与持续集成/持续交付技术集成，以作为开发流水线的一部分构建SBOM。可以在软件应用程序开发过程之前、期间或之后使用以下步骤生成SBOM：
- 定义SBOM范围。组织必须确定其为哪个软件创建SBOM，以及它是否依赖任何内部、外部或第三方依赖项。
- 选择格式。对于希望或需要了解供应链风险的开发人员和最终用户组织而言，使用行业标准格式进行SBOM数据交换至关重要。无论组织是在开发过程中（使用软件成分分析工具或其他方式）生成SBOM，SBOM数据都必须采用可移植且易于理解的格式，以便在其他应用程序中使用。SBOM的行业标准之一是国际标准化组织（ISO）/国际电工委员会5962:2021（关于SPDX规范）。按照此规范编写的SBOM可以在软件漏洞、风险和补丁管理技术中使用，以帮助了解组织使用的底层软件组件。ISO开发了软件标识标签来帮助提供SBOM的数据字段部分。由开放Web应用程序安全项目开发的CycloneDX是另一个帮助组织开发SBOM清单的常见标准。
- 选择SBOM工具。组织应选择其想要使用的SBOM工具，例如CycloneDX命令行界面、Grype、Syft或Tern。它需要符合组织想要实施的SBOM类型。
- 生成SBOM。例如，如果在构建过程中生成SBOM，SBOM工具可能会使用SCA软件来识别每个应用程序的组件。SCA扫描可以在应用程序完成后或在应用程序开发过程中进行。
- 维护。每当软件更新或添加新依赖项时，都应重新运行SBOM工具。