GitHub 7k Star，挖出49个CVE：这个国产AI代码审计工具杀疯了！

阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/deepaudit-ai-code-audit/ 「芋道源码」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

代码安全审计一直是笔不小的开销。要么养人手工翻，要么买 SAST 产品，回来还要自己消一堆误报。所以看到有人用 AI 做这件事，还实际挖出了 49 个 CVE，我会认真看一眼。

这篇的主角是 DeepAudit。它把审计拆成一条流水线，四个 Agent 接力，最后一步是把漏洞真的打一遍。

这个项目到底是干什么的

DeepAudit 是 lintsinghua 开发的开源项目，定位是代码漏洞挖掘系统，能力是自主协作审计加自动化沙箱 PoC 验证，支持 Ollama 私有部署，也能一键生成报告。协议是 AGPL-3.0，这一点后面单独说。

它自述是国内首个开源的代码漏洞挖掘多智能体系统。目前七千多 Star。

lintsinghua/DeepAudit 仓库首页，Star 7.1k

先把一件事说清楚，这里的 Multi-Agent 不是给模型套一层壳就自称 Agent。四个角色之间有真实的上下游关系，上一个的产出是下一个的输入。

四个 Agent，把审计拆成一条流水线

第一个是 Orchestrator，也就是总指挥。你把一个项目丢给它，它先分析代码库结构、判断技术栈，再把任务拆解下发。等审计跑完，由它汇总结果、剔除误报、生成最终报告。

第二个是 Recon Agent，干侦察的活。它扫项目结构、识别框架依赖、找出 API 入口点，把整个项目的攻击面先画出来。传统 SAST 在这块很弱，因为它们不理解路由，也不理解框架约定。

第三个是 Analysis Agent，负责挖漏洞本身。它背后挂着一个装 CWE/CVE 数据集的 RAG 知识库，分析代码时调库做语义比对。这比纯跑规则引擎聪明，代价是 token 消耗更高。

第四个是 Verification Agent，也是这套东西真正的分水岭。

DeepAudit 官方架构图

技术栈这边，后端是 Python FastAPI，Agent 编排用 LangGraph，向量库 ChromaDB，数据库 PostgreSQL 加一个 Redis。前端 React 配 TypeScript，UI 用 shadcn/ui。代码结构也很直白，backend/agents/ 下面就四个文件，orchestrator.py、recon.py、analysis.py、verification.py。

沙箱里跑不通就直接丢掉

这是我认为整个项目最值得看的设计。

Verification Agent 会对每一个疑似漏洞自动写一份 PoC 脚本，然后扔进 Docker 沙箱里执行。脚本跑通了，这个漏洞才进报告。跑不通，直接丢掉。

传统 SAST 的痛点是告警太多，一百条里真有五十条就算不错，剩下的要靠人去消。DeepAudit 的思路是只留能打通的，把消误报这件事从人工挪到了流程里。

沙箱本身是独立镜像，和主服务隔离。这个设计是对的，不能让一段自动生成的攻击代码在宿主机上直接跑。

两个模式，重活和轻活分开

Agent 深度审计是主角。你从 GitHub、GitLab、Gitea 的地址导入项目，或者直接传 ZIP，它就开始跑，界面上能实时看到 Agent 的思考过程和执行日志。日志这个设计很实用，你能看到它在想什么、在干什么，出了问题也好定位。

Agent 审计入口首页

审计流实时日志

即时分析更轻量，粘贴一段代码进去，秒级出结果，覆盖安全问题、Bug、性能、代码风格、可维护性五个维度。它比传统 AI 代码审查多了一层 What-Why-How，会讲清为什么有问题、该怎么修。

即时分析功能

界面里能看到什么

仪表盘把项目整体安全态势摊开，项目管理支持多仓库并行。报告可以一键导出 PDF、Markdown 或 JSON。

智能仪表盘

项目管理界面

审计报告示例

49 个 CVE 的成色

这部分是它能被认真讨论的原因。

团队拿自己的工具跑了一批国内知名开源项目，产出的 CVE 都能在 NVD 上查到。禅道 PMS 上找到 SSRF 和权限提升，CVSS 最高 9.1。DataEase 挖出三个 JNDI 注入，CVSS 全是 9.8，另外还有一个 9.8 的 SSRF。H2O-3 两个反序列化，同样 9.8。

再往下看。O2OA 有一批 XSS，密密麻麻将近二十个。Jimureport 的反序列化 9.8，Litemall 的硬编码凭据 9.8。Mall、xxl-job、eladmin 这些更常见的项目也都在列。OpenClaw 上还贡献了 6 个 GHSA，类型是命令注入、RCE、签名验证绕过和凭证泄露，多个 High 级别，对应项目官方都发了公告。

官方仓库里的 CVEList.md 当前统计是 49 个 CVE、涉及 16 个项目、12 类漏洞。这些漏洞都被对应项目官方确认过，这比任何自评都硬。

部署只要一行命令

部署不复杂，官方给的就是一条命令。

curl -fsSL https://raw.githubusercontent.com/lintsinghua/DeepAudit/v3.0.0/docker-compose.prod.yml | docker compose -f - up -d

国内拉取慢的话有加速版，走南京大学的镜像站。

curl -fsSL https://raw.githubusercontent.com/lintsinghua/DeepAudit/v3.0.0/docker-compose.prod.cn.yml | docker compose -f - up -d

容器起来之后访问 http://localhost:3000，在系统设置里填上 LLM API Key 就能用。另外模型配置是在浏览器里改的，不用重启服务，想对比不同模型的效果很方便。

如果要做源码开发，环境要求是 Python 3.11 以上、Node.js 20 以上、PostgreSQL 15 以上，用 uv 管 Python 环境，前端用 pnpm。

想上生产之前，这几条得先认清

第一是模型依赖太重。四个 Agent 都靠 ReAct 格式驱动，也就是 Thought、Action、Action Input 那一套，模型得能稳定遵循这个格式。用 GPT-4o 或者 DeepSeek V3 问题不大，换成参数小的本地模型，比如 Qwen2.5-7B，跑几步就开始格式漂移，编排直接断掉。支持 Ollama 和什么模型都能用好，是两件事。

第二是大仓库扫起来慢而且贵。四个 Agent 轮番工作，每一步都在烧 token。审一个几十万行的项目，光 API 费用就不是小数目，扫完可能要以小时计。传统 SAST 比如 Semgrep 几秒钟就出结果，速度上不是一个量级。

第三是沙箱 PoC 验证不是万能的。它目前在 SQL 注入、命令注入这类偏通用的漏洞上效果好，但如果漏洞触发需要复杂的多服务环境，沙箱根本建不起来。遇到内存破坏类漏洞，自动生成的 PoC 成功率也会打折。报告显示验证通过，不代表百分之百可利用。

第四是社区反馈过一些具体问题。有人遇到加载项目失败，有人发现报告里的漏洞路径缺绝对路径或行号有偏差，定位代码时要自己再对一遍。南京大学的镜像站之前还下架过 sandbox 镜像，导致国内拉取失败。

第五是协议。AGPL-3.0 拿来做内部工具没问题，要在商业产品里集成，就得认真读一遍许可条款。

最后说我的判断

模型支持范围是够用的，GPT-4o、Claude 3.5、Gemini Pro、DeepSeek V3 都在，国内的通义千问、GLM-4、Kimi、文心一言、豆包也能接。支持 Ollama 本地部署这点尤其重要，可以跑 DeepSeek-Coder、Llama3、Qwen2.5、CodeLlama，代码不出内网，有合规要求的场景就得靠它。

免责声明写得挺实在。开头就把「代码会被发到所选 LLM 服务商的服务器」摆在最前面，还列出几类不该上传的代码。商业机密、敏感数据、受法规限制不能外传的内容，以及未经授权拿到的第三方代码，都点名了。结论也清楚，这类代码要走 Ollama 本地模型或者私有部署的 LLM 服务。

文档这块做得也不含糊。仓库 docs/ 目录下有 Agent 审计、架构、部署、配置、LLM 供应商、常见问题等专题文档，还有中英日三版 README，上手前值得先翻一遍。

整体看下来，它现阶段适合当安全研究人员的辅助工具，或者中小团队给自己的项目做一次安全摸底。方向有价值，但 Issues 里的人反馈它还不成熟，会漏东西、也会误报，还出现过卡死。

想动手的话，直接从那条 docker compose 命令开始就好，项目地址是 https://github.com/lintsinghua/DeepAudit