[Paper] 实用方案系统性监控基于 SBOM 的漏洞扫描器中的不一致性

Source: arXiv - 2512.17710v1

概览

本文针对软件供应链安全中日益突出的痛点：基于 SBOM 的漏洞扫描器 (SVS) 往往会给出不一致或悄然错误的结果，导致漏洞被漏检。作者提出 SVS‑TEST，这是一种系统化的方法和开源工具，用于评估这些扫描器在处理真实世界 SBOM 时的表现，揭示出可能让开发者产生错误安全感的可靠性缺口。

关键贡献

• SVS‑TEST 框架 – 一套可复现的方法论和工具套件，用于基准测试 SVS 工具的能力、成熟度和失效模式。
• 综合案例研究 – 使用 16 个精心构建、具备已知真实漏洞数据的 SBOM 对 七款流行的 SVS 工具 进行评估。
• 实证发现 – 对各工具的假阴性、静默失效以及错误处理差异进行详细量化。
• 公开制品 – 所有 SBOM、真实数据以及 SVS‑TEST 代码均开放发布，便于社区复现和扩展本研究。
• 可操作指南 – 为 SVS 工具开发者和依赖这些扫描器的组织提供具体的改进建议。

Source: …

方法论

1. SBOM 语料库构建 – 作者生成了 16 份 SBOM，大小、格式（CycloneDX、SPDX）和复杂度（例如，嵌套依赖、可选字段）各不相同。每个 SBOM 都配有一份 真实 的已知易受攻击组件列表。
2. 工具选择 – 选取了七款广泛使用的 SVS 工具（包括开源和商业产品），以代表当前市场。
3. SVS‑TEST 执行 – 对每个工具，框架会对所有 SBOM 运行扫描器，捕获输出，并自动将其与真实列表进行比对。同时记录任何错误信息、退出码和执行日志。
4. 指标与评分 – 作者定义了三个主要指标：
   • 召回率 – 报告出的真实漏洞数量。
   • 静默失败率 – 工具在输入有效的情况下未返回结果的情况。
   • 错误处理鲁棒性 – 是否提供有意义的诊断信息。
5. 分析 – 将结果进行汇总、可视化，并进行统计检验，以突出工具之间的系统性差异。

整个流水线使用 Python 编写并容器化，便于任何人添加额外的扫描器或 SBOM。

结果与发现

• 误报（假阴性）很常见：即使是表现最好的工具也遗漏了大约 8 % 的已知易受攻击组件。
• 静默失败令人担忧：有三款工具对多达 38 % 的有效 SBOM 返回空的漏洞列表，且未给出扫描失败的警告。
• 格式敏感性：有些扫描器只能正确处理 CycloneDX，而其他工具在 SPDX 或包含可选元数据的 SBOM 上会出错。
• 错误处理差异显著：能够提供清晰诊断信息的工具让用户能够纠正输入问题；而静默失败的工具则让开发者不知情。

总体而言，研究表明 在没有独立验证的情况下依赖单一的 SVS 工具可能会使软件供应链暴露于风险。

实际影响

• 针对 DevOps 团队：将 SVS‑TEST 集成到 CI 流水线中，持续验证您所依赖的扫描器。在它们出现静默故障并传播到生产发布之前进行检测。
• 针对安全工具供应商：该基准提供了一份具体的检查清单（格式支持、优雅的错误处理、全面的漏洞数据库），可用于提升产品成熟度。
• 针对审计员和合规官员：这些指标提供了一种可量化的方式，评估组织的 SBOM 扫描流程是否符合监管要求（例如行政命令 14028）。
• 针对开源维护者：公开发布的 SBOM 语料库可作为回归测试套件，在添加新语言生态系统或依赖图特性时使用。

简而言之，SVS‑TEST 将“黑盒”扫描转变为软件供应链安全栈中可测试、可观察的组件。

限制与未来工作

• 工具范围：仅评估了七个扫描器；该领域发展迅速，更新的工具可能表现出不同的行为。
• SBOM 多样性：虽然 16 个 SBOM 覆盖了常见的边缘情况，但并未穷尽所有可能的真实世界复杂性（例如，多语言单体仓库、定制元数据）。
• 漏洞数据库新鲜度：基准真实数据反映了某一时间点的快照；更频繁更新 CVE 源的工具在研究中可能显得不够准确。
• 未来方向：作者建议包括扩展 SBOM 语料库、自动化加入实时漏洞信息源，以及扩展 SVS‑TEST 在评估正确性的同时评估性能（运行时间、资源使用）。

通过认识到这些限制，社区可以在此基础上构建出更为稳健的基于 SBOM 的安全测试生态系统。

作者

• Martin Rosso
• Muhammad Asad Jahangir Jaffar
• Alessandro Brighente
• Mauro Conti

论文信息

• arXiv ID: 2512.17710v1
• 分类: cs.SE, cs.CR
• 发表时间: 2025年12月19日
• PDF: 下载 PDF