仅仅发布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/