[论文] 大规模实证分析：SBOM 标准与工具之间的遵循差距

发布: 1周前 (2026年1月9日 GMT+8 16:26)

8 min read

原文: arXiv

Source: arXiv - 2601.05622v1

Overview

该论文首次进行大规模、两阶段的实证研究，评估当今软件材料清单（SBOM）工具实际遵循官方 SBOM 标准（如 SPDX、CycloneDX）的程度。通过自动生成并分析来自真实开源项目的超过 55 k 份 SBOM，作者揭示了一个显著的“遵循差距”，这可能危及供应链安全和合规工作流。

工具选择 – 基于 GitHub 星标、下载量和语言覆盖率，挑选了六款广泛使用的 SBOM 生成器（支持 SPDX 与 CycloneDX 输出）。
代码库语料 – 从 GitHub 克隆了 3 287 个开源项目，涵盖 Java、JavaScript、Python、Go、Rust 和 C/C++，确保构建系统和依赖管理器的真实组合。
两阶段评估
- 基线 – 每个工具为每个代码库生成 SBOM；SAP 框架根据相应标准的策略规则（必填字段、数据类型、SPDX 许可证标识等）对 SBOM 进行验证。
- 纵向跟进 – 12 个月后，使用最新发布的版本在相同代码库集合上再次运行这些工具，以评估随时间的稳定性。
指标 – 合规率（满足所有强制规则的 SBOM 所占比例）、工具间一致性（不同工具检测到的包的 Jaccard 相似度）、工具内一致性（不同版本输出的变化）、以及字段级准确性（例如，与人工整理的真实标签相比的许可证检测准确度）。
根本原因调查 – 对每个主要缺陷，作者检查了工具的源代码、问题跟踪器以及标准本身，以确定产生差距的原因。

方面	关键结果	解释
政策合规性	仅有 31 % 的 SBOM 符合全部强制性标准字段；许多缺少必需的 SPDX 许可证标识符或组件哈希。	工具常常生成“最小化”SBOM，虽然在技术上可解析，但不足以满足下游合规性检查的需求。
跨工具一致性	不同工具之间的包检测重叠率在 7.84 %（Go）到 12.77 %（JavaScript）之间波动。	不同的解析器和依赖图算法导致组件列表差异巨大，使跨工具验证变得不可靠。
同工具一致性	同一工具的新旧版本在许多仓库中的重叠率 ≤ 15 %。	更新会引入回归或改变启发式规则，导致 SBOM 随时间的可复现性受损。
许可证准确性	大多数工具的正确许可证归属率低于 20 %；许多报告为“UNKNOWN”或错误识别的许可证。	许可证检测逻辑不够完善，削弱了 SBOM 的主要安全用例之一。
根本原因	– 规范章节模糊（例如，可选字段与必需字段的区别）。 – 组件列表缺乏确定性的排序。 – 依赖图提取工具（例如 `npm ls`、`go mod graph`）产生不一致的输出。	通过更紧密的规范‑工具对齐以及更健壮的解析流水线，可解决这些系统性问题。

针对 DevOps 团队 – 依赖单一的 SBOM 生成器可能会产生虚假的安全感；建议至少使用另一种工具进行交叉检查，尤其在合规审计之前。
针对工具供应商 – 实施完整的模式验证、确定性的组件排序，并提供版本稳定的 API，以避免升级后破坏下游流水线。
针对安全平台 – 将 SBOM 验证作为一等步骤（例如 CI/CD 门禁）集成，以在其传播到漏洞扫描器之前捕获缺失字段或格式错误的许可证。
针对标准组织 – 研究结果凸显了 SPDX/CycloneDX 中需要澄清的模糊语言；更严格的合规性测试套件可以提升生态系统的一致性。
针对供应链自动化 – 准确的许可证数据和稳定的组件列表是自动化策略执行（例如 “不允许 GPL 许可证的依赖”）的前提。目前的低准确率表明许多自动化策略工具正在基于噪声输入运行，导致误报/漏报。

未来的研究方向包括扩大语言覆盖范围、构建由社区驱动的 SBOM 标准符合性测试套件，以及调查 SBOM 不准确性在真实生产流水线中对下游漏洞管理工具的影响。