什么是SBOM（软件物料清单）？

SBOM（软件物料清单）是应用程序开发与交付过程中涉及的所有组件和软件依赖项的详细清单。它已成为软件开发生命周期和DevSecOps流程中日益常见和关键的部分，帮助希望加强安全态势的组织识别和管理风险。

现代软件应用程序和服务通常由来自不同来源的多个组件和依赖项构建而成。这些组件可以包括开源软件项目、许可证、专有代码、应用程序编程接口、编程语言框架和软件库。构成现代软件的各种来源是软件供应链的一部分，作为支持应用程序和服务的供应源。SBOM列出了所有这些组件，供组织用于改进安全性和软件供应链风险管理流程。

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工具。