这篇论文就像是一次对软件安全领域的“现实体检”。它发现了一个令人震惊的真相：我们用来保护软件供应链的“安检仪”（SBOM 漏洞扫描工具），虽然看起来很先进，但实际上正在制造大量的假警报，让开发者疲于奔命，甚至可能因为太吵而忽略了真正的危险。
为了让你更容易理解，我们可以把整个软件供应链想象成开一家连锁餐厅。
1. 什么是 SBOM？（餐厅的“食材清单”）
想象一下，你开了一家餐厅（软件），你的厨师（开发者）不自己种菜，而是从各种供应商那里买食材（第三方代码库/依赖包）。
- SBOM (软件物料清单) 就是这份详细的食材采购清单。它列出了你用了什么品牌的番茄酱、哪家的牛肉、什么批次的香料。
- 目的：如果某批牛肉（比如 Log4j 组件）被发现有沙门氏菌（漏洞），你可以通过清单迅速查出哪些餐厅用了这批牛肉，然后立刻下架，防止顾客中毒。
2. 第一个发现：清单本身写得对不对？（“手写菜单”vs“智能库存系统”）
以前的研究经常抱怨：不同的 SBOM 生成工具，对着同一个项目，列出的清单居然不一样！有的漏了，有的多了。这就像两个不同的会计，对着同一堆发票，算出来的食材数量不一样，这怎么行？
- 论文发现：问题出在输入源上。
- 旧方法（项目文件）：就像厨师只给了会计一张手写的需求单（比如“我要一些番茄酱”）。会计得自己去猜买哪个牌子、买多少，结果大家猜的不一样，清单自然乱套。
- 新方法（锁文件 Lock Files）：就像厨师直接给了会计智能库存系统的导出单。这张单子不仅写了“番茄酱”，还精确到了“亨氏 500ml 装，批次号 12345"。
- 结论：只要用这种精确的“智能库存单”（锁文件）作为输入，不同的 SBOM 工具列出的清单完全一致且准确。这解决了清单不准的问题。
3. 第二个发现（也是最大的震惊）：清单对了，但“安检仪”还是瞎报警！
既然清单（SBOM）现在非常准确了，那拿着这份清单去查“有毒食材”（漏洞扫描），应该很准了吧？
大错特错！
- 现状：研究人员拿着这份完美的清单，去问两个最流行的“安检仪”（Trivy 和 Grype）：“这里面有有毒食材吗？”
- 结果：安检仪大喊：“有！有！有！”它们列出了 100 个潜在的危险。
- 真相：研究人员拿着这份清单，像侦探一样去厨房（代码）里实地检查，发现其中 92 个都是假的！
- 为什么？ 因为安检仪只看“有没有这个食材”，不看“这个食材有没有被用到”。
- 比喻：假设你的清单里有一瓶“剧毒老鼠药”（某个有漏洞的库）。安检仪看到清单上有，就尖叫“着火了！”。但实际上，这瓶老鼠药被锁在仓库最角落的柜子里，从来没人打开过，也没人把它放进菜里。它虽然“存在”，但无法被利用，对顾客（用户）毫无威胁。
- 后果：开发者每天收到几百条警报，大部分是这种“仓库角落的老鼠药”。久而久之，他们累了，开始无视所有警报。结果，当真正的“毒药”（真实漏洞）混进菜里时，大家反而没反应了。这就是警报疲劳。
4. 解决方案：给安检仪装上“大脑”（可达性分析）
既然问题出在“只看有没有，不看用没用”，那怎么解决？
- 论文提出的方法：函数调用分析（Function Call Analysis）。
- 比喻：给安检仪装上一个智能追踪器。它不再只看清单，而是去厨房走一圈，看看厨师到底有没有把那个“有毒食材”拿出来切、炒、拌。
- 如果那个有毒食材在仓库里吃灰，没被用到 -> 忽略警报（这是假警报）。
- 如果那个有毒食材正在被炒进菜里 -> 立刻报警（这是真危险）。
- 效果：通过这种方法，研究人员成功过滤掉了 61.9% 的假警报。警报数量大幅减少，剩下的都是真正需要处理的“真凶”。
5. 总结与未来建议
这篇论文给行业提出了一个两步走的实用建议：
- 第一步（修好清单）：别再用手写的需求单了，强制使用锁文件（Lock Files）。这能保证你的“食材清单”是 100% 准确和一致的。
- 第二步（升级安检仪）：别只盯着清单看，要升级工具，让它们具备**“可达性分析”**的能力。只有当漏洞代码真的被“调用”时，才报警。
一句话总结：
现在的软件安全工具就像是一个只会看购物小票的保安，只要小票上有“毒药”两个字，他就拉响警报，不管毒药有没有被打开。这篇论文告诉我们：先要把购物小票写对（用锁文件），然后让保安学会去现场看看毒药到底有没有被打开（做可达性分析），这样才能真正保护我们的软件安全，不让开发者在假警报中累垮。
这是一篇关于基于软件物料清单（SBOM）的漏洞管理现状的实证研究论文。作者对 SBOM 生成的准确性以及下游漏洞扫描器的有效性进行了大规模评估，并提出了改进路径。
以下是该论文的详细技术总结：
1. 研究背景与问题 (Problem)
- SBOM 的重要性与现状： 软件物料清单（SBOM）是保障软件供应链安全的关键工具，用于记录软件构建所需的所有直接和传递依赖。然而，现有的 SBOM 生成工具在准确性和一致性方面存在严重缺陷。
- 输入源的不确定性： 许多研究和工具依赖“项目文件”（如
requirements.txt, package.json）作为输入。这些文件通常只声明直接依赖和版本范围，缺乏传递依赖的精确版本锁定，导致不同工具生成的 SBOM 结果不一致且不准确。
- 下游扫描器的高误报率： 即使生成了准确的 SBOM，现有的基于 SBOM 的漏洞扫描器（如 Trivy, Grype）通常仅通过版本号匹配来检测漏洞。这种粗粒度的方法忽略了代码是否真正调用了包含漏洞的函数，导致大量的误报（False Positives）。
- 警报疲劳： 高误报率导致开发人员面临“警报疲劳”，迫使他们手动验证大量无关警报，甚至可能因此忽略真正关键的漏洞。
2. 研究方法 (Methodology)
作者对 2,414 个开源仓库（涵盖 Python, Rust, Ruby, PHP 四种语言）进行了大规模实证研究，研究流程分为两个主要阶段：
阶段一：SBOM 生成准确性评估
- 输入源对比： 对比了使用“项目文件”与使用“锁文件（Lock Files）”作为输入时，SBOM 生成工具（Syft 和 Trivy）的表现。
- 强包管理器（Strong PMs）： 重点考察了能生成锁文件的强包管理器（如 Python 的 Poetry, Rust 的 Cargo, Ruby 的 Bundler, PHP 的 Composer）。
- 基准测试（Ground Truth）： 将锁文件解析出的依赖列表视为“真实情况（Ground Truth）”，计算生成 SBOM 与真实情况之间的 Jaccard 相似度 和 准确率。
- 一致性测试： 评估不同工具在相同锁文件输入下的输出一致性。
阶段二：漏洞扫描有效性评估
- 扫描流程： 使用上述生成的准确 SBOM 输入到主流扫描器（Grype 和 Trivy）中生成漏洞报告。
- 人工验证： 由于缺乏自动化工具，作者对 4 个代表性仓库（每种语言 1 个）进行了深度人工代码审查，验证报告的漏洞是否真实存在且可被利用。
- 可达性分析（Reachability Analysis）： 引入函数调用分析，检查报告中指出的漏洞函数是否在代码中被实际调用。如果函数未被调用，则判定为不可达（Unreachable），从而剔除误报。
- Go 语言自动化验证： 利用 Go 语言漏洞数据库提供的结构化符号元数据，开发了一个概念验证（PoC）工具，在 12 个 Go 项目中自动化验证可达性分析的效果。
3. 关键贡献 (Key Contributions)
- 确立了锁文件作为 SBOM 生成的唯一可靠输入： 证明了使用锁文件（而非项目文件）配合强包管理器，可以消除工具间的差异，生成完全一致且准确的 SBOM。
- 揭示了下游扫描器的严重缺陷： 首次大规模量化了基于 SBOM 的漏洞扫描器的误报率，发现高达 92.0% 的误报率。
- 定位了误报的根本原因： 指出主要误报来源是不可达代码（Unreachable Code）。扫描器仅检查包版本，未检查漏洞函数是否被调用。
- 提出了两阶段改进方案：
- 阶段一： 使用锁文件生成高保真 SBOM。
- 阶段二： 结合函数调用/可达性分析，过滤不可达漏洞，生成可操作的报告。
- 开源工具与数据： 开源了验证代码、SBOM 及漏洞验证工件，并提供了从弱包管理器迁移到强包管理器的实践指南。
4. 主要实验结果 (Results)
SBOM 生成准确性：
- 当使用锁文件作为输入时，Syft 和 Trivy 在 Python, Rust, Ruby, PHP 四种语言上生成的 SBOM 与真实情况（Ground Truth）的 Jaccard 相似度达到 1.0，准确率达到 100%。
- 相比之下，使用项目文件会导致工具间结果不一致且遗漏传递依赖。
- 对于仅包含项目文件的旧仓库，可以通过强包管理器（或桥接工具如
uv）成功生成锁文件。
漏洞扫描误报率：
- 在人工验证的 16 个仓库样本中，扫描器报告的 113 个潜在漏洞中，仅确认了 9 个真实漏洞。
- 总体误报率高达 92.0%。
- 误报的主要原因是扫描器报告了基础运行时库（如 Ruby 的
activesupport）中的漏洞，但这些漏洞模块在实际应用中从未被导入或调用。
可达性分析的效果：
- 通过函数调用分析，成功剔除了 61.9% 的误报（在人工验证样本中，警报数量从 113 降至 42）。
- 在 Go 语言的自动化测试中（12 个项目），可达性分析将误报减少了 74.4%（从 121 个降至 31 个）。
5. 意义与未来方向 (Significance & Future Work)
- 对开发者的启示： 必须停止依赖项目文件生成 SBOM，转而使用强包管理器并强制提交锁文件到版本控制，这是供应链安全的基础。
- 对工具开发者的启示： 现有的 SBOM 扫描器仅靠版本匹配已不足以应对实际安全需求。下一代工具必须集成可达性分析（Reachability Analysis），以区分“存在漏洞的包”和“被利用的漏洞”。
- 行业瓶颈： 目前主要漏洞数据库（如 NVD, GHSA）缺乏机器可读的“受影响函数/符号”元数据，导致自动化可达性分析难以大规模实施。作者呼吁社区推动漏洞元数据的结构化标准化。
- 结论： 准确的 SBOM 是必要条件，但不是充分条件。只有将高保真 SBOM 与细粒度的可达性分析相结合，才能真正解决警报疲劳问题，提供可操作的供应链安全情报。
总结
这篇论文通过严谨的实证研究，打破了“有了 SBOM 就能解决供应链安全”的迷思。它证明了当前流程中存在两个致命弱点：输入源（项目文件）导致的 SBOM 不准确，以及分析粒度（仅版本匹配）导致的极高误报率。论文提出的“锁文件 + 可达性分析”双阶段路径，为构建真正实用的软件供应链安全体系指明了方向。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。