VulnAgent-X：把漏洞检测从“一次性判断”升级为“可验证的多Agent审计工作流”
提出分层Agent漏洞检测框架：风险筛查→上下文扩展→多专家协作→动态验证→证据融合，让漏洞检测更可靠、更可解释、误报更低。
2025年9月1日OngoingFirst author
SecurityVulnerability DetectionAgentLLMCode IntelligenceRepository-levelVerificationExplainability
背景：为什么漏洞检测很难？
漏洞检测不像普通分类任务。很多高危问题并不“写在一行代码里”，而是藏在：
- 跨函数/跨文件的调用链（source → sink）
- 配置、权限、环境变量等隐性约束
- 运行时条件（某些输入组合才触发）
- 历史代码习惯（项目特定的防护/编码模式）
因此，单次把某段代码丢给模型问“有没有漏洞”常见的两类失败：
- 漏报：需要上下文，但模型没看到；
- 误报：模型讲得很像，但证据不足，路径不可达或已被过滤。
问题：单模型 one-shot 审代码的天花板
即便 LLM 代码理解很强，安全审查仍然面临：
- 上下文不足：只看函数/片段无法判断真实数据流
- 缺少验证：无法区分“可疑”与“可利用”
- 缺少反证机制：模型容易被自己的推断带跑
- 难以解释：给出结论但不给完整证据链
所以我把核心问题定义为：
能不能把漏洞检测从“静态判断”变成“像真正安全审计一样的闭环流程”，并且让输出带证据、可复核、可定位？
方法：VulnAgent-X（分层多Agent + 证据驱动）
VulnAgent-X 不是让一个模型一次性输出结论，而是把检测拆成五个阶段：
1) Fast Risk Screening（快速筛查）
先用低成本信号把搜索空间缩小：
- 轻量静态信号（危险 API、缺少校验等）
- 变更元信息（鉴权模块、输入处理模块、配置变更）
- 轻量模型风险评分
只保留 Top-K 高风险片段进入下一步，避免“全仓库大推理”。
2) Context Expansion（最小充分上下文扩展）
围绕高风险片段构建最小充分上下文，而不是把全仓库塞进模型：
- 调用者/被调用者（call chain）
- 相关配置、权限策略
- 测试、异常处理
- 相似历史修复
目标：给模型“刚好够用”的证据，而不是“越多越好”的噪声。
3) Multi-Agent Collaborative Analysis（多专家并行）
核心是“分工 + 互补 + 对抗”：
- Router Agent：先判断属于安全漏洞还是普通 bug，路由给专家
- Semantic Agent：盯语义/控制流/边界/异常
- Security Agent：盯 source→sink、注入、鉴权、危险 API 等
- Logic Bug Agent：盯状态机/事务边界/并发/校验顺序
- Sceptic Agent（反方）：专门找反证：路径是否不可达？是否已过滤？是否只是风格问题？
这一层的目标不是“多写几段解释”，而是形成可辩论的证据集合。
4) Dynamic Verification（选择性动态验证）
当风险高或不确定性大时，生成验证材料：
- 最小复现输入 / payload
- 单元测试 / regression test
- 运行轨迹（若允许沙箱执行）
把“看起来像漏洞”升级为“可验证的漏洞/缺陷”。
5) Evidence Fusion（证据融合与裁决）
最后不听某个 Agent 的“一票否决”，而是做证据融合：
- 静态证据 + 上下文证据 + 多Agent一致性 + 动态验证
- 再减去反证（counter-evidence）
输出结构化 findings：
- 类型、位置（文件+行号）
- 证据链（source→sink / reachability）
- 置信度与严重性
- 修复建议与回归测试建议
实验：怎么验证有效？
我按三类目标设计实验：
- 检测性能：Precision/Recall/F1/AUROC
- 定位能力：Top-1/Top-3/MRR（行级/语句级定位）
- 工程可用性：token 成本、时间、动态验证触发比例、早停比例
数据集选用公开基准（函数级 + 提交级）：
- Devign（经典函数级漏洞检测）
- Big-Vul（大规模 C/C++ 漏洞数据集）
- PrimeVul（更严格、更贴近真实的评测设置）
- 提交级 just-in-time 基准（commit-level detection + localisation）
你会在图里看到什么？
- Pareto 图：性能 vs 成本，展示分层调度带来的“更划算”的点
- 敏感性曲线：K / context budget 增大后性能提升很快饱和，但成本持续上升
- 阈值影响：不同置信度阈值如何影响验证率与成本
- 错误分布：环境依赖、helper 语义缺失、可达性判断等仍是主要错误来源
关键 takeaway
- 漏洞检测的瓶颈常常不是“模型看不懂代码”，而是证据不足与验证不足。
- 把任务拆成“筛查→上下文→多专家→验证→融合”，能显著提升可靠性与可解释性。
- 反方 Sceptic Agent 对降低误报很关键。
- 动态验证不需要全量执行，只要对高风险/高不确定样本做选择性验证，就能极大提升置信度。
局限与下一步
- 依赖环境配置的漏洞仍然难：需要更强的环境建模/沙箱执行支持
- 数据集标签噪声会影响评测：需要更严格的审计式评估
- 更希望把输出对齐实际安全流程：比如生成 PR review comment、给出可直接落地的修复 diff
如果你对这套工作流感兴趣，欢迎看论文与代码（链接在文首 front matter）。