文章总结： 论文提出PoVSmith框架，通过调用路径分析和AI编码代理自动生成漏洞验证测试，帮助开发者评估第三方库漏洞的实际影响。在33个Java程序对测试中成功生成152个测试用例，其中55%能演示漏洞可利用性，较现有方法提升4倍以上。该方法为软件供应链安全提供了可操作的自动化验证方案。 综合评分： 85 文章分类： 漏洞分析,安全工具,AI安全,安全开发,供应链安全

【论文速读】|生成漏洞验证测试以帮助增强复杂软件的安全性

原创

知识分享者 知识分享者

安全极客

2026年5月6日 17:35 北京

在小说阅读器读本章

去阅读

基本信息

原文标题：Generating Proof-of-Vulnerability Tests to Help Enhance the Security of Complex Software

原文作者：Shravya Kanchi, Xiaoyan Zang, Ying Zhang, Danfeng (Daphne) Yao, Na Meng

作者单位：Virginia Tech（弗吉尼亚理工大学），Blacksburg, Virginia, USA

关键词：软件供应链安全、漏洞验证测试、调用路径分析、AI编码代理、大语言模型、PoV测试生成

原文链接：https://arxiv.org/abs/2605.03956

论文要点

论文简介：现代软件开发高度依赖第三方库（Libraries，简称 Libs），应用程序（Apps）构建在这些库之上，一旦库中存在安全漏洞且可被应用层代码触达，整个应用便面临软件供应链攻击的威胁。然而，开发者在收到漏洞报告时，往往需要具体可执行的证据——即”漏洞验证测试”（Proof-of-Vulnerability，PoV）——才能判断某个依赖漏洞是否真正对自己的应用构成实际安全风险。

手工编写这类测试极为困难，现有工具的自动化支持也严重不足。为此，来自弗吉尼亚理工大学的研究团队提出了 PoVSmith，一种结合调用路径分析、示例测试、代码上下文与反馈机制的新方法，通过多轮提示引导 AI 编码代理（Codex）和大语言模型（GPT）完成测试生成、执行与评估的全流程自动化。在 33 个 Java 程序对的评估中，PoVSmith 识别出 158 个应用层入口点，生成了 152 个测试，其中 84 个（55%）成功演示了漏洞的可利用性，大幅超越现有最先进方法。

研究目的：本研究的核心目标是解决软件供应链安全中的一个关键痛点：当第三方库被报告存在漏洞时，开发者无法快速判断该漏洞是否真正影响自己的应用。研究团队希望构建一套自动化流程，能够从应用代码中找到可触达漏洞 API 的调用路径，并据此生成可执行的 PoV 测试，让开发者获得直观、可运行的漏洞利用证据，从而做出更准确的安全决策，而无需等待渗透测试结果或依赖人工分析。

研究贡献：本文的研究贡献体现在四个层面。

第一，提出了 PoVSmith 这一新颖的自动化方法，将调用路径分析、示例测试参考、代码上下文感知与迭代反馈机制融合为统一的多阶段流程，实现了 PoV 测试的端到端自动生成与评估，显著降低了人工介入的需求。

第二，在 33 个真实 Java 应用与漏洞库配对数据集上进行了系统性评估，覆盖 20 个 CVE 条目，验证了方法的有效性与泛化能力。

第三，通过消融实验对比了不同 AI 编码代理（Codex、Gemini Code Assist、Mistral Vibe）的表现，揭示了代理选择对测试生成质量的影响规律。

第四，在测试生成过程中发现了若干此前未被报告的新漏洞，并为此提交了六个 Pull Request 和六个 CVE 申请，为开源社区的安全改进做出了实质性贡献。

引言

软件供应链（SSC）是指参与软件开发或版本更新全过程的人员、流程与技术的集合。软件供应链漏洞，是应用软件所依赖的外部依赖项或第三方库中存在的安全缺陷。黑客可利用这类漏洞攻击应用软件，实施数据窃取、远程控制或勒索软件投放等恶意行为（见图 1）。

初始入侵阶段：攻击者在第三方供应商组件、开源软件包或 CI/CD 流水线中挖掘漏洞，或是注入恶意代码。

扩散传播阶段：存在漏洞或已被植入恶意代码的软件被分发至大量企业与组织机构。

漏洞利用阶段：漏洞代码或恶意代码被触发，进而实现数据窃取、远程接管系统、部署勒索软件等恶意操作。

造成影响阶段：攻击形成大范围破坏，波及数千家企业业务。

如今，软件供应链已成为网络攻击的主要突破口。仅 2025 年，恶意开源软件包及第三方库数量就同比增长 73%，供应链安全风险加剧趋势显著 —— 这类开源库最终会被大量下游应用软件引用。网络安全厂商 Cyble 基于暗网数据泄露站点的攻击者宣称攻击事件统计显示：2025 年 10 月软件供应链攻击数量达到 41 起，创下历史新高，较 4 月此前峰值高出 30% 以上。SolarWinds、Log4j、MOVEit 等重大高危安全事件均印证：单一第三方依赖库一旦被攻陷，便可牵连成千上万套基于其构建的软件系统。软件供应链攻击在波及范围、影响深度和整体破坏力上都愈发严峻。

为弥补开发者实际需求与现有工具能力的差距，本文提出PoVSmith框架，专门面向 Java 应用自动生成可直接运行的 JUnit 格式漏洞验证测试用例。

如图 2 所示，PoVSmith 共分为四个核心阶段：调用路径分析、PoV 测试用例生成、测试编译执行、大模型评估校验。

输入为存在漏洞的第三方库版本与依赖该库的应用软件后，第一阶段依托 AI 代码智能体 Codex，解析应用程序上下文，定位两类关键信息：一是调用漏洞库接口的应用公有方法，二是每个目标方法的完整调用路径。第二阶段结合调用路径与示例测试用例，调用 Codex 迭代生成 PoV 测试用例，根据编译与运行状态评估用例有效性，定位编译报错、运行异常的根本原因并持续迭代优化。第三阶段接收优化后的测试用例，自动完成项目构建编译；编译通过后，自动执行测试用例。第四阶段基于第三阶段输出的编译、运行日志和最终测试用例，利用大模型 GPT 评估生成的用例是否成功触发漏洞，并输出评估结果，连同测试用例一并提交给开发者审核。

背景与动机

软件供应链攻击（Software Supply Chain Attack，SSC）已成为当今网络安全领域最严峻的威胁之一。现代应用程序普遍依赖大量开源第三方库，这些库一旦被植入恶意代码或被发现存在安全漏洞，便可能成为攻击者入侵下游应用的跳板。根据论文引用的数据，仅 2025 年一年，恶意开源包的数量就增长了 73%，2025 年 10 月更创下单月 41 起供应链攻击的历史新高。SolarWinds、Log4j、MOVEit 等高知名度事件深刻揭示了单一库漏洞如何波及数千个依赖它的软件系统。

在这一背景下，漏洞验证测试（PoV 测试）的价值愈发凸显。当安全研究人员或漏洞数据库（如 CVE、NVD）报告某个库存在漏洞时，应用开发者面临的核心问题是：这个漏洞在我的应用中真的可以被利用吗？理论上的漏洞存在与实际可利用性之间存在巨大鸿沟——漏洞 API 可能根本没有被应用代码调用，或者调用路径上存在其他防护机制。没有具体可执行的 PoV 测试，开发者往往难以做出准确判断，要么过度反应浪费资源，要么忽视真实风险酿成事故。

然而，手工编写 PoV 测试需要深入理解漏洞原理、应用代码结构以及两者之间的调用关系，这对普通开发者而言极具挑战性。现有的自动化工具（如模糊测试工具 AFL、OSS-Fuzz）虽然能够发现漏洞，但并不专门针对供应链场景下的 PoV 测试生成，且往往需要大量计算资源和人工配置。AI 编码代理的兴起为这一问题提供了新的解题思路，但如何有效引导代理生成高质量、项目特定的安全测试，仍是一个开放性挑战。

PoVSmith 方法设计

PoVSmith 的核心设计理念是将复杂的 PoV 测试生成任务分解为四个相互衔接的阶段，每个阶段都通过精心设计的提示模板引导 AI 代理完成特定子任务，并将前一阶段的输出作为后一阶段的输入，形成完整的自动化流水线。

第一阶段：基于代理的调用路径分析（Phase I: Agent-Based Call Path Analysis）

这一阶段的目标是在应用代码中找到所有可以触达漏洞库 API 的公共方法及其完整调用路径。研究团队将漏洞库 API 视为”汇点”（sink），将应用中可被外部调用的公共方法视为”源点”（source），通过提示 Codex 在项目代码库中搜索从源到汇的完整调用链。

传统的程序分析工具（如 WALA、Soot、CodeQL）在这一场景下存在明显局限：它们难以处理 JDK 9+ 的新语言特性（如 switch 表达式），且主要面向字节码分析，而源码分析更便于将结果映射到具体代码位置。PoVSmith 选择让 Codex 直接分析源码，利用其对代码语义的理解能力来识别调用关系。提示模板明确要求代理使用 rg/grep 等工具定位每个汇点的调用位置，逐层向外追溯到第一个满足条件的公共方法，并以标准格式输出完整调用链（包含文件路径和行号范围）。

为避免冗余路径带来的工作量膨胀，PoVSmith 采用了一个重要的过滤规则：如果公共方法 A 调用了另一个公共方法 B，而 B 直接调用了漏洞 API，则 A 不被视为攻击面——因为任何针对 A 的利用都可以通过方法调用重定向到 B。这一设计有效减少了冗余路径，聚焦于真正有价值的入口点。

第二阶段：基于代理的 PoV 测试生成（Phase II: Agent-Based Generation）

获得调用路径后，PoVSmith 进入测试生成阶段。这一阶段的提示模板设计尤为精妙，它向 Codex 提供了五类关键信息：目标源方法的签名、完整调用路径、漏洞库版本信息、用户提供的示例测试（exemplar test）以及项目的构建配置。

示例测试的引入是 PoVSmith 的一大创新。示例测试通常来自漏洞库本身的测试套件，展示了如何直接触发漏洞。PoVSmith 要求 Codex 参考示例测试中的语义载荷（semantic payload），将其适配到应用层的入口方法，生成一个以源方法为入口、不直接调用汇点方法的自包含 JUnit 测试。这种”语义迁移”的思路既保证了测试的漏洞相关性，又确保了测试符合应用层的调用约定。

生成过程是迭代式的：Codex 首先生成初始测试，然后根据构建和执行结果进行自我批评（self-critique）和修正，直到测试能够成功编译和运行，或达到最大迭代次数。这种迭代精化机制有效应对了代码生成中常见的幻觉问题和项目特定的编译错误。

第三阶段：测试编译与执行（Phase III: Test Compilation and Execution）

这一阶段由 PoVSmith 的自动化脚本接管，无需 AI 代理参与。脚本接收生成的测试代码，根据项目的构建配置（Maven 或 Gradle）自动构建并执行测试，输出包含编译结果、运行时日志、堆栈跟踪和测试结果的日志文件。

为了让后续的 LLM 评估更加准确，PoVSmith 对原始日志进行了智能处理：从 XML 日志文件中提取与目标测试相关的片段，转换为结构化的 JSON 格式（summary.jsonl），同时保留原始 .txt 日志作为补充。这一设计源于研究团队的实际观察——原始日志文件往往过于冗长，直接发送给 GPT 会导致模型被无关信息干扰，产生错误的评估结论。

第四阶段：基于 LLM 的测试评估（Phase IV: LLM-Based Evaluation）

最后一个阶段由 GPT 担任”裁判”，综合分析生成的测试代码和执行日志，判断测试是否成功触发了目标漏洞。评估提示要求 GPT 以严格的 JSON 格式输出结论，包含三个字段：triggered（yes/no/unknown）、confidence（low/medium/high）和 reasoning（引用日志证据的简短解释）。这种结构化输出便于后续的自动化处理和人工审查。

实验评估

研究团队在 33 个 Java 应用与漏洞库配对数据集上对 PoVSmith 进行了全面评估，这些配对涵盖 20 个 CVE 条目，代表了 DoS（拒绝服务）、DT（数据篡改）、RCE（远程代码执行）和 OTH（其他类型）四类攻击场景。

在调用路径分析（RQ1）方面，PoVSmith 共识别出 216 条调用路径，对应 158 个唯一源方法，其中 152 条路径（96%）被两位作者独立验证为正确。9 条错误路径主要源于两类问题：方法覆盖导致的混淆（3 例）和方法位置描述错误（6 例）。研究团队认为这些错误可以通过基础的静态程序分析进行过滤，未来版本将加以改进。

在测试生成（RQ2）方面，PoVSmith 针对 152 个任务生成了测试，其中 141 个（93%）成功编译，84 个（55%）成功演示了漏洞的可利用性。按攻击类型分析，DT 类漏洞的演示率最高（77%），OTH 类次之（84%），DoS 类为 50%，而 RCE 类最低（10%）。68 个未能成功演示 PoV 的测试中，37 个展示了非漏洞行为（可能是应用已打本地补丁），11 个在调用漏洞 API 之前就抛出了无关异常，7 个未能正确使用漏洞载荷。

在测试评估（RQ3）方面，GPT-5.1 的评估准确率达到 68%（103/152），高于 Codex 自我批评的 62%（94/152）。GPT 的优势在于它基于实际执行日志进行判断，而 Codex 的自我批评依赖自生成的执行数据，更容易受到幻觉的影响。

在代理对比（RQ4）方面，研究团队在 33 个样本任务上对比了三种代理配置。使用 GPT-5.2-Codex 的 PoVSmith 在 PoV 演示数量（23 个）上表现最佳；使用 Gemini-2.5-pro 的变体编译率最低（70%），演示率仅 33%；使用 Devestral 2 的变体编译率最高（97%），但演示率同样只有 36%。这表明代理的代码理解能力和对提示的遵循程度对最终测试质量有显著影响。

在与先进方法对比（RQ5）方面，PoVSmith 与 Zhang 等人的 LLM 方法进行了直接比较。在相同的 33 个样本任务上，PoVSmith 成功演示 PoV 的测试数量为 22 个，而对比方法仅为 5 个，提升幅度超过 4 倍。对比方法的主要不足在于：它不进行迭代式测试生成，缺乏编译/执行反馈机制，也没有自我批评能力，且需要人工修复编译错误。

讨论与局限性

PoVSmith 的实验结果令人鼓舞，但研究团队也坦诚地指出了若干局限性。首先，当前实验数据集规模相对有限（33 个程序对，20 个 CVE），结论的泛化性有待在更大规模数据集上验证。其次，实验中使用的 LLM 和代理（GPT-5.2-Codex、Gemini-2.5-pro、Devestral 2）代表了特定时间点的技术水平，随着模型迭代，结论可能发生变化。第三，RCE 类漏洞的演示率（10%）明显低于其他类型，这反映了远程代码执行漏洞在测试生成上的固有难度，需要专门的方法加以应对。

在未来工作方面，研究团队计划从两个方向增强自动化验证能力：一是在漏洞版本和补丁版本上分别执行测试，通过对比结果来确认漏洞触发；二是分析测试代码，标记对 CVE 的错误解读和误导性错误信息。此外，团队还计划扩展数据集规模，探索更多漏洞类型和应用场景，并引入基础静态分析来过滤调用路径分析中的错误结果。

值得特别关注的是，PoVSmith 在测试生成过程中意外发现了若干此前未被报告的新漏洞，并为此提交了六个 Pull Request 和六个 CVE 申请。这一”副产品”充分说明了自动化 PoV 测试生成工具在安全研究中的潜在价值——它不仅能帮助开发者评估已知漏洞的风险，还可能在这一过程中揭示新的安全问题。

相关工作

PoVSmith 所处的研究领域涵盖自动漏洞检测、自动漏洞修复和安全测试生成三个方向，研究团队对这三个方向的代表性工作进行了系统梳理。

在自动漏洞检测方面，依赖检查工具（如 OWASP Dependency-Check）能够扫描软件依赖并建议安全版本，但它们只能识别已知漏洞的存在，无法判断漏洞是否真正可被利用。基于深度学习的漏洞检测方法（如 DLAP）在代码层面的漏洞识别上取得了进展，但同样不能提供可执行的利用证据。

在自动漏洞修复（AVR）方面，VuRLE、SEADER 等工具从代码示例中学习漏洞修复模式，VulRepair、SeqTrans 等序列到序列模型从历史修复记录中学习修复策略。这些工作与 PoVSmith 形成互补关系——PoVSmith 专注于证明漏洞可利用性，而 AVR 工具专注于修复漏洞。

在安全测试生成方面，自动漏洞利用生成（AEG）工具（如 Mayhem）能够自动生成漏洞利用代码，但通常需要用户指定可利用性属性，且计算开销较大。模糊测试工具（如 AFL、OSS-Fuzz）通过随机输入变异来发现漏洞，但不针对特定的供应链场景。PoVSmith 与这些工作的核心区别在于：它专门面向软件供应链场景，利用调用路径分析精确定位攻击面，并通过 AI 代理生成项目特定的测试，无需用户指定利用属性，也无需进行昂贵的搜索。

结论

PoVSmith 代表了软件供应链安全领域的一次重要探索。面对日益严峻的供应链攻击威胁，它提供了一套切实可行的自动化解决方案：通过 AI 编码代理进行调用路径分析，结合示例测试和代码上下文生成项目特定的 PoV 测试，再借助 LLM 对测试质量进行客观评估，形成完整的闭环流程。

在 33 个真实 Java 程序对上的评估表明，PoVSmith 能够以 96% 的准确率识别应用层攻击入口，以 55% 的成功率生成可演示漏洞利用的测试，并以 68% 的准确率自动评估测试质量，全面超越现有最先进方法。更重要的是，PoVSmith 在测试生成过程中还发现了新的安全漏洞，体现了这类工具在安全研究中的额外价值。

从更宏观的视角来看，PoVSmith 的意义不仅在于技术层面的突破，更在于它改变了开发者应对供应链漏洞的方式。当开发者收到漏洞报告时，不再需要依赖模糊的风险评估或等待专业渗透测试，而是可以通过 PoVSmith 快速获得具体可执行的漏洞利用证据，从而做出更准确、更及时的安全决策。随着 AI 编码代理能力的持续提升和方法的不断完善，PoVSmith 所代表的自动化 PoV 测试生成范式有望成为软件供应链安全防护体系的重要组成部分。

-End-

免责声明：

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

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

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

本文转载自：安全极客 知识分享者 知识分享者《【论文速读】|生成漏洞验证测试以帮助增强复杂软件的安全性》