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

misa2 03-06 3次浏览 0条评论

作者 | Matt Campbell

译者 | 刘雅梦

策划 | 丁晓昀

软件物料清单（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。为了实现这一目的，他们强调了三种方法：

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

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

展开全文

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

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

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

原文链接：