什么是软件物料清单 (SBOM)？

软件开发团队在十多年前就开始使用 SBOM 来管理开放源代码库和第三方存储库。重大供应链攻击事件暴露关键漏洞后，网络安全问题将 SBOM 推向核心位置。2020 年的“SolarWinds 数据泄露”事件中，攻击者在受信任的软件更新中插入了恶意代码，影响了包括多个政府机构在内的 18,000 个组织。2021 年 Log4j 漏洞曝光后不久，全球数亿台设备受到波及，进一步揭示了受感染组件如何威胁整个系统安全。

这些网络攻击事件凸显了一个严峻的现实：包括联邦政府机构在内的组织都缺乏对其软件系统中组件和依赖关系的了解。可见性的缺失，致使组织难以评估网络安全风险并有效应对威胁。威胁的紧迫性促使美国白宫果断采取行动。2021 年 5 月，“第 14028 号行政令”强制要求所有联邦软件采购部门使用 SBOM。

美国国家电信和信息管理局 (NTIA) 制定了 SBOM 最低要素要求，适用于向政府实体销售产品的软件供应商。2024 年 9 月，CISA 发布了一份名为“规范软件组件透明度”的文档，针对上述最低要求进行扩展，并为整个软件生态系统内 SBOM 的实施和管理提供更详细的指导。

该联邦指令现已成为行业软件透明度的标杆规范。例如，在金融服务行业，“支付卡行业数据安全标准”(PCI DSS) V4.0 包含软件库存管理要求，旨在保护支付系统并解决漏洞。在医疗保健领域，FDA 要求医疗器械使用 SBOM，而国际医疗器械监管机构论坛 (IMDRF) 则建议将其用于保护医疗器械和患者数据系统。

这些行业准则和建议反映了私营部门向采用 SBOM 的广泛转变。Gartner 预测，到 2025 年，60% 的构建或采购关键基础设施软件的组织将强制使用 SBOM，而 2022 年这一比例还不到 20%。这种采用是出于必要性 - 最近的分析表明，超过 90％ 的现代软件应用程序包含开源依赖项，其中 74％ 包含高风险依赖项。各个组织越来越多地使用 SBOM 来满足合规性要求、验证第三方组件以及处理发现的安全漏洞。

与详细说明成分及其来源的食品标签一样，SBOM 针对软件组件及其供应商和依赖项之间的关系提供结构化文档。

自“第 14028 号行政令（2021 年）”提出 SBOM 要求以来，该要求已发生显著变化。最初由 NTIA 提出的最低要求，已通过行业应用和监管完善而得到扩展。当前框架由 CISA 于 2024 年 9 月发布，并围绕上述基础而建立，为更广泛的实施提供了强化指导。

根据组织所属部门及其与联邦政府的关系，它们要面对不同的 SBOM 要求。美国政府承包商、关键基础设施提供商和受监管行业的组织必须遵守相应的 SBOM 要求。尽管联邦政府强制要求其供应商采用 SBOM，但非政府合约的私营机构组织仍属自愿采纳范畴。不过，实施 SBOM 实践对保障供应链安全及维系客户信任已愈发重要。

CISA 的 2024 框架引入了三层成熟度模型，可帮助组织逐步强化其 SBOM 实践：

• 最低要求：基础 SBOM 功能和合规性所需的基本要素
  
  
• 建议做法：增强文档以支持更广泛的安全和合规用例
  
  
• 理想目标：实现全面供应链可见性的高级功能

以下属性表示完整 SBOM 中所需的基本元素：

• SBOM 元信息：SBOM 文档本身的核心数据，包括 SBOM 数据的创建者、创建时间戳和记录的主要组成部分
  
  
• 供应商名称：创建、定义和制造软件组件的实体
  
  
• 组件名称：软件组件的指定名称，由原始供应商指定
  
  
• 组件版本：捕获特定于版本的更改，以准确跟踪更新和修改情况
  
  
• 其他唯一标识符：包括参考类型，例如通用平台枚举 (CPE)、SWID 标签或用于精确组件跟踪的软件包 URL (PURL)
  
  
• 加密散列：每个软件组件的唯一指纹，可用于验证完整性和精确识别
  
  
• 依赖关系：显示组件如何实现互连的结构化映射，涵盖直接和传递依赖关系
  
  
• 许可证信息：所提供软件组件的法律条款文档
  
  
• 版权声明：拥有所列组件专有权和合法权利的实体

软件依赖关系在现代应用程序中形成了复杂的互联体系。SBOM 必须清楚地捕获这些关系，区分直接依赖关系（明确包含在软件中的组件）以及传递依赖关系（由其他依赖关系拉入的组件）。

在记录依赖关系时，组织应明确表明其知识的完整性。默认情况下，依赖关系信息可能不完整，除非另有明确标注。这一透明度有助于下游用户了解其软件供应链中的潜在盲点。

组织还需考虑运行时加载的动态依赖关系以及从外部服务调用的远程依赖关系。虽然这些依赖关系不属于传统软件构建的范畴，但了解这些关系对于全面的安全评估至关重要。

在实际部署中，往往无法完全掌握所有软件组件的完整信息。组织必须明确记录未知的依赖关系和不完整的信息，以透明的方式弥合这些差距。当某些组件由于合同义务或其他限制而无法完整记录时，SBOM 应在保留整体依赖关系结构的同时，注明这些修订内容。

组织不应遗漏不确定的信息，而应将这些内容明确标注为“未知”或“不完整”。这一做法可帮助下游用户就风险管理和后续调查需求做出明智的决策。对于编辑过的组件，组织应维护完整的内部 SBOM 和供外部共享的相应修订版本。

创建和维护 SBOM 的过程涉及整个软件开发生命周期 (SDLC) 中的多个利益相关者。组织应该为专有和开源软件 (OSS) 组件生成 SBOM。软件供应商和开发人员主要负责在开发过程的早期生成初始 SBOM。这些 SBOM 捕获了整个代码库组件的全面视图。软件购买者在验证和维护其已部署应用程序的这些文档方面发挥着关键作用。

软件开发团队将 SBOM 生成直接整合到其持续集成和持续交付 (CI/CD) 管道中。在构建过程中，自动扫描工具会分析源代码以盘点所有组件，捕获直接和传递依赖关系。这些工具可生成 SPDX 和 CycloneDX 等格式的标准化 SBOM 文件。（SWID 标签不太重要，但仍然是有效的选项。）它们记录了每个组件的元数据、版本信息和许可详细信息。

版本控制系统维护 SBOM 更改的历史记录，跟踪软件组合如何随时间演变。组织可以跟踪每个版本的软件组件中的版本变更和安全补丁，这对于管理漏洞和处理安全事件至关重要。

开发团队通常将其管道配置为基于特定事件触发 SBOM 更新：何时添加新的依赖关系、何时更新现有组件或何时应用安全补丁。此持续更新过程可维持软件实际组成与其文档记录之间的一致性。

整个开发管道中的质量控制检查点可验证 SBOM 的完整性和准确性。这些核验步骤可验证每个 SBOM 是否符合要求的标准，并且包含软件发布前所需的全部组件信息。自动验证可缩小文档记录差距，并提高不同发布版本间的一致性。

支持 SBOM 创建的工具生态系统持续扩展。SBOM 生成器构成其基础，可自动扫描源代码以识别组件及其关系。然后，验证工具可根据既定的标准和规范验证所生成的 SBOM，并标记缺失或不正确的信息。成功部署 SBOM 自动化依赖既定的最佳实践：实现团队间格式的标准化、采用一致的命名规范、维护清晰的自动化规则文档并建立持续改进的反馈机制。

管理平台以这些能力为基础，提供跨组织的 SBOM 存储、分析和分发功能。先进的平台通过将 SBOM 数据集成到更广泛的风险和合规工作流程中而更进一步。

例如，自动化工具可以将漏洞映射到特定的软件组件，根据严重程度确定修复工作的优先级，并跟踪一段时间内的变化，以识别新引入的风险。通过整合数据并提供实时洞察分析，这些工具可支持开发、安全和合规团队有效协作。

选择正确的 SBOM 格式对于有效实施至关重要。SBOM 必须支持自动生成和机器可读功能，以便在软件生态系统中进行扩展。SBOM 流程自动化可消除创建过程中的手动输入错误，并实现与安全和开发工具的无缝整合。

有多种标准化格式可用于自动生成、验证和使用 SBOM 数据，同时支持与现有安全和开发工具的整合。组织应在其 CI/CD 管道中实现 SBOM 的自动生成，从而确保文档记录与软件更改同步。

当前的 CISA 框架主要可识别两种格式：SPDX 和 CycloneDX。每种格式都以不同的方式编写软件组件文档，其详细程度各不相同，且侧重于软件开发生命周期中的特定用例。

Software Package Data Exchange (SPDX) 由 Linux 基金会开发，已获得开源生态系统和商业软件供应商的广泛采用。该格式支持加密包验证，并提供多种机器可读的格式选项，包括 JSON、RDF、XML 和 YAML。其丰富的元数据支持可在整个软件供应链中实现详细的安全性和来源跟踪。

SPDX 擅长开源合规场景，可提供详细的许可证信息，并帮助组织有效管理其开源组件的使用情况。主流软件供应商和云服务提供商已普遍采用 SPDX，因其规范严谨且生态系统支持广泛。

CycloneDX 由 OWASP Foundation 开发，专为应用程序安全防护和软件供应链风险管理而设计。它具备漏洞管理、组件跟踪和供应链安全防护等基本功能，且专注于支持 VEX 整合和容器分析。

该格式以安全为中心的元素使其特别适合实施全面软件供应链安全计划的组织。它对安全用例的本机支持推动了安全团队和漏洞管理工作流的采用。

软件识别 (SWID) 标签为软件识别和管理提供了标准化机制。该格式可支持全面的软件资产跟踪，且面向企业环境提供生命周期管理、补丁跟踪和库存控制功能。值得注意的是，SWID 标签在“2024 年属性映射指南”中不再列为支持格式，但其仍然是 SBOM 中唯一标识符的有效选择。

软件构成分析 (SCA) 是一种主动网络安全流程（及相关工具），可用于扫描代码中的漏洞；软件物料清单 (SBOM) 则可针对产品中所有软件组件建立标准化库存。尽管两者都支持软件供应链安全防护功能，但其在现代开发环境中的用途截然不同。

虽然这两个工具都侧重于软件组件，但 SCA 工具会在开发过程中主动扫描和分析代码，且主要关注开源组件和第三方依赖关系。这类工具可为漏洞检测、许可证合规性和安全策略实施提供实时洞察分析。

SBOM 作为标准化库存文档，可捕获所有软件组件，包括专有代码。SBOM 通过 SPDX 和 CycloneDX 等结构化格式确保软件构成的透明度，但其本身不具备分析能力。虽然 SCA 工具通常用于支持内部安全实践，但 SBOM 正逐步发展为法规和行业标准的强制要求。

组织通常一起实施这两种解决方案，使用 SCA 工具主动监控开发期间的安全性，同时维护 SBOM 以满足合规性要求和供应链可见性。SCA 工具通常会自动生成和验证 SBOM，而 SBOM 文档则有助于制定扫描策略。

现代软件供应链日趋复杂，因此推行 SBOM 以实现全面风险管理和安全保障成为一项必要举措。组织正大力普及自动化平台，将 SBOM 数据与其他安全和合规信息整合，以便更有效地做出决策。

安全团队通过支持实时漏洞检测和响应的自动化平台，将 SBOM 数据集成到更广泛的应用程序风险管理战略中。当出现新的常见漏洞和风险 (CVE) 时，这些平台可以使用 SBOM 库存立即将它们映射到整个软件组合中受影响的组件。这有助于组织支持安全软件实践。

这一整合可以实现 AI 驱动式风险优先级洞察分析，帮助团队优先处理最严重的 CVE 问题。在事件响应期间，来自 SBOM 的详细组件数据可生成关于潜在受影响组件的关键情报，从而开展有针对性的修复工作和更准确的风险评估。

SBOM 在漏洞管理中发挥着重要作用，它能提供软件组件的全面库存清单，并在发现新的漏洞时快速识别受影响的系统。

然而，并非所有漏洞都会带来同样的风险，确定漏洞是否可被利用也很有难度。这就是漏洞可利用性交换 (VEX) 的用武之地。作为安全框架，VEX 可提供有关已知漏洞的关键背景信息，从而增强 SBOM 的实用价值。虽然 SBOM 可识别软件产品中的所有组件，但它无法指明已发现的漏洞是否可利用。VEX 则可通过阐明漏洞的实际影响，弥合这一差距。

VEX 会告知产品安全事件响应团队 (PSIRT) 和安全团队，特定漏洞是否会影响其软件环境。借助通用安全通告框架 (CSAF)，VEX 可提供有关漏洞影响的机器可读式状态更新信息。有了这些信息，安全团队就能做出更快速、更明智的决策。

通过将 VEX 数据与 SBOM 集成，组织可以减少误报，确定实际风险的优先级并简化漏洞管理工作流。这种组合方法标志着自动化安全风险评估和有针对性的补救措施取得了重大进步。

随着监管要求的变化，组织需要先进的合规管理能力，以便处理复杂的 SBOM 要求。SBOM 作为一种证明形式，提供可验证的文档，证明软件组件符合 NIST 指南和行政命令 14028 等标准。通过提供软件构成和安全性的透明记录，SBOM 可以简化审计并展示跨行业的监管一致性。

联邦机构和受监管行业必须证明遵守各种框架，包括 NIST 指南和第 14028 号行政命令。高级合规平台可以自动验证软件组件是否符合安全标准，跟踪多个框架的合规状态，并在组件偏离要求时发出实时警报。这些能力可以帮助组织保持持续合规，同时减少人工监督。

云原生和容器化环境为 SBOM 管理带来了独特的挑战。基于这些环境的动态特性，组织需要应用专业方法来应对复杂的微服务架构、持续变更容器映像并跨多个云供应商和平台进行部署。

组织通过与容器编排平台直接集成的专门 SBOM 工具来应对这些挑战。这些解决方案支持在构建和部署容器映像时实时生成 SBOM，同时为混合云环境提供统一的可见性。

通过自动执行组件跟踪并与现有的云安全工具集成，组织可以维护准确的软件组件库存，并快速响应整个云基础架构中的安全威胁。无论应用程序运行于容器、无服务器功能，还是传统环境，此功能都适用。

SBOM 通过实现对第三方软件的全面可见性，为供应链风险管理奠定了基础。组织通常利用 AI 驱动的平台来分析 SBOM 数据和其他安全指标，从而全面了解其应用程序的健康状况和风险状况。

这类平台可跟踪组件版本、评估供应商风险并提升许可证合规性，同时提供有效的洞察分析以缓解风险。将 SBOM 数据与更广泛的风险管理流程整合，可帮助组织就其软件依赖关系制定明智的决策，并维护更安全、合规的应用环境。

组织在其软件生态系统中践行 SBOM 计划时，可能面临几个显著障碍。了解并应对这些挑战，是成功推行计划和有效维护供应链数据安全的关键所在。

组织实施 SBOM 实践时经常会遇到以下挑战：

• 跨不同环境管理数千个软件组件
  
  
• 在不同的开发工具和安全平台之间整合 SBOM 数据
  
  
• 维护数据质量，特别是旧版软件和第三方组件的数据
  
  
• 通过快速部署周期跟踪云环境中的依赖关系
  
  
• 平衡资源限制与即时准确的 SBOM 数据需求
  
  
• 适应组件频繁变化的动态云原生架构

成功实施 SBOM 需要采取战略手段，以满足行业标准和组织需求，其关键要素包括：

• 在整个软件开发生命周期中实现流程自动化
  
  
• 与现有工作流和安全工具无缝整合
  
  
• 使用统一平台进行 SBOM 管理

• 实现基础 SBOM 功能和合规性所需的基本要素
  
  
• 增强文档以支持更广泛的安全和合规用例
  
  
• 通过高级功能实现全面的供应链可见性

• 实时生成和更新 SBOM，尤其是在云原生环境中
  
  
• 透明地记录未知信息，而不是忽略信息
  
  
• 管理完整的内部 SBOM 和供外部共享的编辑版本
  

• 制定明确的 SBOM 治理政策，定期进行审核和自动化验证
  
  
• 将 SBOM 数据与漏洞可利用性交换 (VEX) 连接，改善漏洞管理

通过遵循这些实践，组织可以提高供应链可见性、增强安全性并维持合规性，同时应对 SBOM 实施的挑战。

软件供应链安全态势的不断演进，推动了 SBOM 技术和应用的创新。随着组织面临日益复杂的威胁，SBOM 在保护软件生态系统方面的作用变得越发重要。

几个关键趋势正在塑造 SBOM 实施和利用的未来：

人工智能的进步正在改变组织管理和利用 SBOM 的方式。现代 AI 系统目前能够自动生成和分析 SBOM，同时提供更准确的预测性风险分析以及完善的漏洞检测。该自动化技术已得到扩展，可主动识别软件供应链中的安全风险。

其中一项重大进展是专业 AI/ML BOM 的问世，二者均有助于解决 AI 生成式代码和模型中的独特挑战。此类增强型 BOM 可记录 AI 模型架构、训练数据并测试方法，为 AI 开发流程引入了必要的透明度。

SBOM 管理的安全态势在继续发展。区块链和分布式账本技术为安全的 SBOM 存储和共享提供了新的解决方案，创建了不可变的审计跟踪，这对关键基础设施系统特别有价值。组织越来越需要可操作的 SBOM 数据，以便能够快速识别受损组件并简化修复过程。

区块链可以通过提供防篡改存储、实现分散验证以及通过严格的访问控制促进安全的跨组织共享来增强 SBOM 安全性。

这种技术融合推动了与现有 DevSecOps 实践相集成的统一平台的采用。这些解决方案实现了整个 SBOM 生命周期的自动化，从合并不同的数据源到管理跨多个软件版本和分支的审批，同时提供智能以降低风险。