仅仅发布 SBOM 是不够的，质量和可用性因项目而异

软件物料清单（SBOM）正成为确保软件供应链健康的重要组成部分。最近对开源存储库中 SBOM 的质量和可用性进行的一项评估发现，SBOM 的可用性和实现存在很大的差异。OpenSSF的开源软件安全动员计划有一个专门的流来改进 SBOM 的可用性、生成和消费。

正如开源软件安全动员计划的作者所指出的那样，“仅仅发布 SBOM 是不够的，还需要积极地使用它们”。然而，Chainguard 的安全数据科学家John Speed Meyers怀疑，我们是否也需要专注于确保高质量的生成工具的存在。Meyers 指出：

尽管存在许多 SBOM 生成工具（以及许多 SBOM 的隐含存在），但 SBOM 消费工具仍难以解析格式不正确和不完整的 SBOM，并且实现软件透明度的目标仍然遥不可及。

为了“在自然状态下”验证 SBOM 的可用性和质量，Chainguard 创建了一个包含 50 多个公开可用的 SBOM 的数据集（bom-shelter）。然后，该团队针对数据集应用了两个 SBOM 质量评估工具。第一个工具SBOM Scorecard是 eBay 的一个开源项目。第二个工具是来自 SPDX 社区的美国国家电信和信息管理局（NTIA）一致性检查器。

Meyers 报告称，许多开源项目 SBOM 的质量很低。例如，SBOM Scorecard 工具检查是否存在软件包许可证信息。在被评估的 SBOM 中，只有大约 20%的有此信息。

NTIA 一致性检查器根据NTIA“最小元素”框架评估 SBOM。它们将这些最小元素描述为“支持基本 SBOM 功能的基本要素，并将其作为不断演进软件透明度方法的基础”。“最小元素”包括供应商名称、组件名称、组件版本、其他唯一标识符、依赖关系、SBOM 作者和时间戳。所有评估的 SBOM 没有一个全部包含所有这些信息。

开源软件安全动员计划提出了十个行动流，重点是提高开源软件的安全性。第九个流侧重于改进 SBOM 工具和培训，以帮助推动整个生态系统采用 SBOM。为了实现这一目标，他们强调了三种方法：

1. 推动就跨各种 SBOM 规范实施的共同要求达成一致

2. 确保有易于使用的开源工具可以根据这些要求生成 SBOM

3. 提供无障碍教育、意识和实施指导

该团队指出，已经有多种 SBOM 规范可用，其中包括SPDX和CycloneDX。工作组的重点不是将所有可用格式整合成一种格式，而是在可用格式之间实现“无缝互操作性”。

Amélie Koran、Wendy Nather、Stewart Scott和Sara Ann Brackett最近发表的一篇文章旨在明确定义消费SBOM的用例。他们指出，缺乏明确定义的用例会带来两个主要风险：

首先，它有使命偏离的风险，政策制定者可能会在没有明确界定 SBOM 旨在解决的问题的情况下，开始将 SBOM 视为解决所有供应链问题的灵丹妙药。

他们强调的第二个风险是由于 SBOM 的价值被低估而导致的采用率低下。作者确定了四个主要用例：采购、漏洞管理和威胁情报、事件响应、以及生态系统映射。

Meyers 同意提高 SBOM 可用性及其质量的双重目标，他指出“如果要通过 SBOM 实现软件透明度，SBOM 质量将成为一个关键问题。”有关 SBOM 分析结果的更多详细信息，请访问Chainguard的博客。

原文链接：

https://www.infoq.com/news/2023/01/sbom-quality-availability/

相关阅读：

Linux 基金会《软件材料清单（SBOM） 与网络安全准备度》报告深度解读