什么是SBOM（软件物料清单）？
SBOM（软件物料清单）是应用程序开发与交付过程中所有组件和软件依赖项的详细清单。它已成为软件开发生命周期和DevSecOps流程中日益常见且关键的部分，帮助希望加强安全态势的组织识别和管理风险。
现代软件应用程序和服务通常由多个来自不同来源的组件和依赖项构建而成。这些可能包括开源软件项目、许可证、专有代码、应用程序编程接口、编程语言框架和软件库。构成现代软件的各种来源是软件供应链的一部分，作为启用应用程序和服务的供应源。SBOM列出了所有这些组件，供组织用于改进安全和软件供应链风险管理流程。
SBOM包含的内容
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——使用软件组成分析（SCA）工具或其他方式——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工具。