CVE都可以自动发现并申请了，看看开源的AutoCVE

孙志敏
孙志敏

AI与安全

2026年7月18日 09:48
北京

在小说阅读器读本章

去阅读

申请 CVE 从来不是件容易事，它曾是许多白帽子引以为傲的勋章。Mythos 出来之后，\"发现漏洞\"这件事仿佛一下子变简单了——但对普通人来说，想直接拿到一个 CVE 编号依然很难。因为从\"看出这里有问题\"到\"提交一份能过审的申报材料\"，中间还隔着一整套工具链：筛项目、审源码、挖漏洞、写 PoC、出报告……缺一环都走不到最后。

今天，这套活儿被 AutoCVE 一次性打包自动化了。作者近乎\"一键\"，一周就拿下了 30 个 CVE，覆盖 14 个开源项目；项目刚开源，GitHub 收获 1300+ Star、80+ Fork。

什么是AutoCVE

AutoCVE 是一个面向代码安全审计与 CVE 挖掘的 Agent 化审计平台。它把整条链路都做成了自动化：

项目上传/导入 → 自动化审计任务 → Multi-Agent 工作流分析 → 结构化漏洞结果输出 → 一键 CVE 提交

对使用者而言，体验非常\"傻瓜\"：导入一个 GitHub 仓库或上传源码包，创建审计任务，剩下的交给 Agent。它会自己筛项目、读代码、找漏洞、验证漏洞，最后产出一份可直接提交的结构化报告——你只需要复制报告去提交 CVE 申请。平台还提供\"一键 CVE\"模式：自动从 GitHub 筛选项目并持续创建审计任务，直到 Agent 发现指定数量的 CVE 候选漏洞为止。

实现原理：一条会\"接力\"的 Multi-Agent 审计流

AutoCVE 的核心，是一条以\"如何自动化挖掘可申报的高价值漏洞\"为目标设计的 Multi-Agent 审计流。整个流程由 Orchestrator 统一编排调度，把一次代码审计切成几个明确的阶段：

Recon（侦察）

识别项目语言、框架、入口文件和重点审计路径，给后续阶段划定\"该往哪看\"；
* Scan（扫描）

调用规则扫描、依赖扫描、密钥扫描等工具做初步发现；
* Triage（研判）

对扫描结果做误报过滤和优先级筛选，把噪声压下去；
* Finding（挖掘）

这是整条流水线最核心的节点。它不满足于复述扫描器结果，而是结合上下文继续阅读源码，分析数据流、危险调用、权限边界和可利用链路，尝试产出符合 CVE 申报条件的结构化漏洞；
* Verification（验证）

结合 PoC、沙箱或测试工具，对漏洞进行动态验证。

各阶段之间不是靠\"甩一大段无结构文本\"来协作，而是通过 Handoff 机制 传递结构化上下文——上一阶段的发现、置信度、目标文件、推荐审计路径、可信候选等，都会被打包传给下一个 Agent。正是这套接力机制，让\"信息收集 → 漏洞确认\"的审计闭环能够连续、稳定地跑完。

架构设计：从入口到落库的全链路

先看整体架构总览：

如图所示，AutoCVE 是一套完整的前后端系统，而不是一个\"套壳脚本\"：

入口与项目来源

React + Vite 前端 + FastAPI 网关，支持从 GitHub / GitLab / Gitea / ZIP 导入项目；
* LLM Provider

兼容 OpenAI 协议、Anthropic / Claude、DeepSeek / Qwen、Gemini / Ollama 等多家模型，可为不同 Agent 配置不同模型方案；
* Multi-Agent System

即上文的 Orchestrator + Recon/Scan/Triage/Finding/Verification 编排；
* Agent Runtime / Tool Runtime

会话式运行时，负责 QueryLoop、工具注册、工具编排与流式执行；
* Security Tool Suite

内置代码检索工具、Shell 工具，以及 Semgrep、Bandit、Gitleaks、TruffleHog、npm audit 等 SAST / 密钥 / 依赖扫描能力；
* Isolated Environment

Docker 沙箱 + PoC Runner，把高风险的动态验证放进隔离环境执行；
* 漏洞资产与报告

人工研判、CVE 状态跟踪，产出中文 / English / CVE Markdown 报告；
* Persistent Storage

PostgreSQL 落库业务数据，Redis 承载 SSE 事件与运行状态，projects/ 保存导入仓库与工作副本。

一句话概括：每一步都可追踪、可回放、可落库，这是它能稳定产出\"可申报\"漏洞的地基。

工具体系与 Agent Loop：把\"开放式审计\"约束成\"工程流程\"

如果说架构总览是骨架，工具体系就是让 Agent\"手脚受控\"的关键设计：

这张图把工具体系拆成了五层：

Agent 决策层

模型只能看到「当前 Agent + 当前阶段 + 当前权限」下的 active tools；
2. Runtime 会话层

QueryLoop 构造 system / user / history / tool result 消息，驱动模型推理；
3. 工具注册层

ToolRegistry 是\"能力目录\"，决定模型这一轮能看到哪些工具，并支持 deferred tools 延迟加载；
4. 工具编排层

ToolOrchestrator 是所有工具调用的入口，负责查找、校验、授权、记录与执行，每一次调用都会写入 AuditToolCall；StreamingToolExecutor 则按并发安全性分批执行——只读工具可以并行，写入 / Shell / 沙箱等有副作用的操作串行执行，出错还能中止同批调用，避免错误扩散；
5. 工具能力层

文件与代码检索（Read/Glob/Grep/Write）、Shell 执行、Skill 体系、Finding 适配工具、Triage 工具、扫描与分析工具（Semgrep / Bandit / Gitleaks / TruffleHog 等）。

右侧的权限与护栏同样重要：Pydantic 输入校验、is_enabled 启用检查、default / plan 权限模式、allow / ask / deny 授权策略，以及针对 Write 与 Shell 的越权保护——允许 Agent 做审计必要动作，同时不让它越界写文件、覆盖源码或执行不可控命令。

比工具约束更妙的，是 Agent Loop 的状态机设计。AutoCVE 不再依赖模型用自然语言判断\"要不要继续\"或\"是不是完成了\"，而是用状态机对每一轮\"推理 → 工具调用 → 结果回填 → 状态判断\"进行调度：

当证据不足、利用链未闭合、或模型提前声称完成时，Runtime 会进入不同的 Continue 节点，并通过 Nudge 机制 提醒模型继续调用 Read / Grep / Glob 补证据；
更关键的是，Finding Agent 不能只输出一段自然语言总结就收工，必须调用结构化终止工具 FinalizeFinding，提交漏洞类型、影响路径、source / sink、利用链、PoC、修复建议、置信度和 CVE 申报理由等字段。字段不合法就返回 finalization_rejected，把校验错误反馈给模型，让它继续补全。