文章总结： 本文介绍ViperScan方法，通过从安全补丁提取语义约束来精准检测Java跨库漏洞传播。该方法结合LLM语义提取与规则化执行分析，解决版本差异导致漏报、利用条件建模难导致误报及跨库分析成本高等挑战，在810个JavaCVE和4.4万条依赖链验证中，漏洞函数识别召回率提升至95%，误报下降40%-69%，并揭示仅5.6%传播链可达且其中53.8%满足利用条件。 综合评分： 88 文章分类： 漏洞分析,安全开发,应用安全,供应链安全

白泽成果分享：通过补丁语义分析让“依赖库漏洞传播”看得更准

原创

复旦白泽战队 复旦白泽战队

复旦白泽战队

2026年5月11日 14:43 上海

在小说阅读器读本章

去阅读

NEWS

白泽成果分享：通过补丁语义分析让“依赖库漏洞传播”看得更准

Fine-grained Detection of Java Cross-library Vulnerability Propagation by Extracting Semantic Constraints from Security Patches

研究背景

在 Java 生态中，Maven、Gradle 等工具提升了依赖复用效率，但也带来一个长期难题：一旦上游依赖出现漏洞，风险可能会沿着依赖链一路传到下游项目。针对这一问题，现有检测方法主要是 SCA（检测是否引入漏洞版本）和调用图分析（检测是否能调用到漏洞函数），但两者通常只能说明“可能有风险”，难以判断“是否真实可利用”。

为了更准确刻画漏洞传播，理解漏洞代码语义至关重要，而补丁（patch）正是公开漏洞信息中最直接、最结构化的来源。与漏洞描述文本相比，补丁不仅给出“哪里被修复”，还明确展示“修复前后语义差异”——即哪些路径被阻断、哪些校验被新增、哪些输入约束被强化。这些变化恰好对应漏洞利用成立所依赖的关键条件。

因此，本文从补丁切入，提取与漏洞传播相关的语义约束，并将其与跨组件传播分析结合，提出 VIPERSCAN。该方法不仅判断漏洞路径是否可达，还进一步验证攻击前提是否成立，并提升历史版本中漏洞函数识别的准确性。

研究已发表于 IEEE Transactions on Dependable and Secure Computing（TDSC）。

01

核心思路

补丁中蕴含的漏洞利用信息主要包括三类：

• 数据流关系：攻击者可控数据能否实际流向危险操作点；
• 路径条件：执行过程中是否存在权限校验、分支保护等拦截约束；
• 全局语义标签：与漏洞相关的类、方法、字段及其上下文关联。

大模型在代码语义理解方面具有优势，但在大规模、批量化的跨库传播分析场景下，若完全依赖 LLM，往往面临稳定性不足、结果可复现性弱以及分析成本高的问题。为此，VIPERSCAN采用“LLM 语义提取 + 规则化执行分析”的核心思路：首先利用 LLM 对漏洞补丁进行语义解析，提取利用相关约束；随后将这些语义信息自动转化为可执行分析规则，并将规则注入后续可达性分析流程。

这样的思路面临三项技术挑战：首先，版本差异导致漏洞点漏检：漏洞在引入到修复之间常经历多次演化，若仅基于最终修复提交提取特征，易忽略历史上下文。其次，分析规则语言是复杂的，用LLM直接生成分析规则成功率低。最后，跨库边界常导致调用/数据流断链，而全量分析代价过高。

面对这些问题，VIPERSCAN 提出三步解决方案：（i）版本感知的漏洞 API 提取从补丁往历史版本回溯，把不同版本中“语义等价”的危险函数和相关代码上下文都找出来。（ii）引入更简洁的中间语言，辅助LLM对漏洞利用条件的提炼，并通过回归测试迭代优化。（iii）基于摘要的跨库可达性分析只对断点方法做摘要，补齐跨库调用中的缺漏。

VIPERSCAN整体框架

02

挑战与关键技术

论文指出了三个关键难点和解决方案：

挑战一：版本差异导致漏报

在真实项目里，漏洞从“引入”到“修复”之间，往往会经历多个 commit。如果只孤立地看“最终修复的那个 commit”，很可能看不到完整上下文，也就难以准确识别真正的漏洞点。

本文还总结了一个很关键的现象：版本漂移（version drift）。也就是说，在漏洞修复之外的普通代码演进中，函数重命名、封装层变化、调用关系调整等改动，会让“同一漏洞语义”在不同版本里表现成不同 API 关系。结果就是：如果只盯补丁版本中的函数签名，早期受影响版本里的真实漏洞点就可能被漏掉。

关键技术：版本感知的漏洞 API 提取

针对这个问题，本文采用了沿版本历史回溯的漏洞 API 提取方法：

1. 从修复补丁出发，沿提交历史向前追踪到漏洞引入阶段；
2. 在追踪过程中识别函数结构变化（如重命名、封装调整、调用迁移）；
3. 为不同受影响版本建立对应的“危险 API 映射”，而不是只保留补丁版本签名。

这样做的效果是：跨版本函数签名对齐，并为后续步骤提供充分的代码上下文。

回溯过程中识别函数结构变化

挑战二：漏洞“利用条件”难以建模，导致误报

很多漏洞并不是“调用到危险函数就一定能利用”。它通常还依赖一组前提条件，比如：特定数据流是否成立、关键分支是否被绕过、配置开关是否开启等。这类条件类型多、语义强，传统静态分析很难完整建模；而如果直接让 LLM 对每条调用链做最终判定，又容易受随机性影响，稳定性和可复现性不足。

关键技术：LLM 生成 DSL + 高容错解析 + 回归迭代

1. 不让 LLM 直接生成复杂分析规则（如 CodeQL 查询），因为这类输出容易不稳定、语法错误率高；
2. 引入语法更简单的中间语言 DSL，先由 LLM 生成 DSL 形式的漏洞条件表达；
3. 设计更高容错的 ANTLR 解析器，把 DSL 自动转换成可执行分析规则；
4. 使用已提取的多版本代码样例做回归测试，不断迭代优化规则质量。

把“语义理解能力”和“工程可执行性”拆开处理：LLM 负责看懂补丁语义，解析引擎负责稳定生成可用的规则。

补丁片段->DSL->QL规则

挑战三：跨库传播链长，分析成本高

在真实依赖生态中，一条漏洞传播路径常常跨越多个库。一到库边界，调用流和数据流就容易“断链”；但如果做全量全程序分析，计算成本又太高，难以落地。

关键技术：选择性摘要补全

本文采用“按需摘要”策略：先定位最可能发生断链的关键位置，再只对这些位置生成跨库摘要，用于补全传播路径。这样既能提升跨库可达性分析的完整度，也避免了全量分析带来的高开销。

03

核心结论

论文在大规模数据上做了验证（810 个 Java CVE、44,184 条 Maven 依赖链），代表性结果：

• 漏洞函数识别召回率达到 95%（对比基线 72%）
• 相比常见 SCA 工具，误报下降约 40%–69%
• 在 44,184 条传播链中，真正“可达”的仅 5.6%
• 而在可达路径里，满足利用条件的只有 53.8%

此外，论文还给出了几个关键工程结论：

1. DSL 辅助 LLM 规则转化是有效的：相比直接生成复杂分析规则，采用 DSL 中间层能显著提高规则转化成功率和稳定性。
2. 选择性摘要策略性价比高：只引入不到 5%的额外时间开销，就达到了与全量分析基本一致的准确率。

44,184组依赖链中真正高危的跨库利用链只有1,327条

04

研究团队

张磊，复旦大学助理研究员，主要研究方向为漏洞挖掘与治理，目前主持国家重点研发计划子课题、国家自然科学基金青年基金、上海市人民政府决策咨询项目等，在 IEEE S&P、ACM CCS 等网络安全顶会上发表论文十余篇，获上海市科技发明一等奖、上海 CCF 科学技术一等奖、ACM SIGSAC 中国优博奖和 ACM 中国优博提名奖，并获得 2022 年 USENIX Security 杰出论文奖、2024 ACM FSE 杰出论文奖等。多项研究工作以内参、专报等形式上报政府相关部门，多次获得党和国家主要领导人批示，发现的某关键漏洞获 CNVD 最具价值漏洞奖，并多次配合相关部门开展工作。

孙福特，复旦大学计算与智能创新学院博士研究生。主要研究方向为静态程序分析、LLM驱动的漏洞检测与软件供应链安全分析等。

联系邮箱：[email protected]，张磊老师

供稿、排版：复旦白泽战队

责编：董佳仪

审核：张琬琪、张磊、洪赓

复旦白泽战队

一个有情怀的安全团队

还没有关注复旦白泽战队？

公众号、知乎、微博搜索：复旦白泽战队也能找到我们哦~

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：复旦白泽战队 复旦白泽战队 复旦白泽战队《白泽成果分享：通过补丁语义分析让“依赖库漏洞传播”看得更准》