用 AI 审代码:它挖出了 49 个 CVE,但我不敢直接用在生产环境

大家好，我是互联网架构师！

上周，我花了一下午，把 DeepAudit 跑在了自己一个老项目上。

那是一个三年前的 Python 项目，大概两万行代码，我自己写的，心里大概有数——肯定有坑，但应该不至于太离谱。结果 DeepAudit 跑完，给我报了 17 个「严重」级别的问题，其中 3 个它声称能 PoC 验证通过。

我盯着那个报告看了很久。一方面觉得「这玩意儿有点东西」，另一方面又隐隐不安——它说的这些漏洞，真的存在吗？

先说结论：DeepAudit 确实能挖出来东西。

GitHub 上 6k+ Star，团队拿它跑了一批国内知名开源项目，挖出了 49 个 CVE，全部在 NVD 上能查到。禅道 PMS 的 SSRF、Dataease 的 JNDI 注入、H2o-3 的反序列化、O2OA 的 XSS 批量……这些都不是自娱自乐，是被官方确认过的真实漏洞。

从「能挖到」这个维度，它通过了最硬的考核。

但「能挖到」和「能放心用」之间，隔着一条挺宽的河。

DeepAudit 的架构，设计得挺聪明。

四个 Agent 分工协作，不是那种「包一层 Claude 就敢叫 Agent」的伪智能：

• Orchestrator：总指挥，分析项目结构、判断技术栈、拆解任务

• Recon Agent：侦察兵，扫描依赖、找 API 入口、画攻击面

• Analysis Agent：分析师，挂 RAG 知识库，做语义比对找漏洞

• Verification Agent：验证官，写 PoC 脚本，扔进 Docker 沙箱跑，跑通才进报告

Verification Agent 是最核心的差异点。 传统 SAST 工具，比如 Semgrep，告警 100 条，真的可能只有 50 条。DeepAudit 理论上只留能打通的——PoC 跑成功，才算数。

这个设计思路是对的。但问题在于，「理论上」和「实际上」是两回事。

我实际跑下来的感受：

第一，它对模型能力的要求不低。

四个 Agent 都是 ReAct 格式驱动（Thought / Action / Action Input），模型必须稳定遵循这个格式。我用 GPT-4o 跑，基本没问题。换成本地 Ollama 的 Qwen2.5-7B，跑了三步就开始格式漂移，Agent 编排直接断掉。

「支持 Ollama」≠「什么模型都能用好」。 小参数模型在复杂推理任务上，还是撑不住。

第二，大仓库扫起来又慢又贵。

我那两万行代码的项目，GPT-4o 跑了四十多分钟。如果是一个几十万行的大型项目，光 API 费用就不是小数目，时间可能要以小时计。传统 SAST 比如 Semgrep，几秒钟出结果，速度上根本不是一个量级。

第三，PoC 验证不是万能的。

DeepAudit 在 SQL 注入、命令注入这类通用型漏洞上效果好。但如果漏洞触发需要复杂的多服务环境，沙箱建不起来。或者遇到内存破坏漏洞，自动生成的 PoC 成功率直接打折。

报告显示「验证通过」，不代表真的 100% 可利用。 这个边界，README 里写得不够清楚，容易让人误判。

第四，报告质量有瑕疵。

我遇到的几个具体问题：漏洞路径有时候是绝对路径，有时候又缺失；行号偶尔有偏差，定位代码时要自己再对一遍。这些问题不算致命，但用在正式审计工作里，会增加人工复核的成本。

但这些问题，不代表 DeepAudit 没价值。

它的价值在于方向——用 Multi-Agent + RAG + PoC 验证，把 AI 代码审计从「静态规则匹配」推向「动态验证」。这个思路是对的，而且比传统工具更接近「真实漏洞发现」的本质。

对安全研究人员来说，它是一个很好的辅助工具。对中小团队做自有项目的安全摸底，也有用——至少能帮你发现那些「一眼就能看到」的硬编码密码、SQL 注入、命令注入。

但它现阶段不适合当「主力」。

原因不是功能不够，是成熟度不够。社区反馈里有加载项目失败、镜像拉取失败、偶尔卡死的问题。AGPL-3.0 协议也意味着商业集成需要谨慎。更重要的是，它会漏掉东西，也会误报，你需要有足够的安全背景去判断哪些该信、哪些该 discard。

写到这，我想聊聊「AI 代码审计」这件事本身。

很多人看到「AI + 安全」的组合，第一反应是「安全工程师要失业了」。但用了 DeepAudit 之后，我的感受恰恰相反——AI 不是在替代安全工程师，是在放大他们的能力边界。

以前一个安全工程师审代码，一天能看几千行就不错了。AI 工具能帮你快速扫一遍，把「明显有问题」的地方标出来，省下的时间用来做深度分析、做 PoC 验证、做漏洞利用链的梳理。

但 AI 不会替你做判断。 它报了一个「严重」级别的漏洞，你需要判断：这是真的吗？利用条件是什么？影响范围有多大？修复优先级怎么排？这些决策，AI 做不了，也不该让它做。

DeepAudit 最好的用法，是「第一遍筛子」。 让它快速过一遍，把可疑点标出来，然后人工复核。而不是直接把它当「终审法官」，它说有问题你就修。

最后，给想试试的人几个建议：

1. 优先用 Ollama 本地部署审私有代码，避免代码泄露到第三方 API

2. 大项目分批扫，不要一次性扔进去几十万行，钱包和耐心都扛不住

3. 报告里的每个「严重」都要人工复核，不要直接转给开发团队

4. 小参数本地模型谨慎用，格式漂移会让你怀疑人生

5. AGPL-3.0 协议读清楚，商业集成前先找法务

项目地址：github.com/lintsinghua/DeepAudit

协议： AGPL-3.0

如果你也是安全工程师，或者正在用 AI 工具做代码审计，欢迎评论区聊聊你的体验——它帮你挖到过什么？又让你踩过什么坑？