AI 挖漏洞到底靠不靠谱，能否应用实际项目

原创

拉玛刹
拉玛刹

智械AI

2026年8月11日 13:02
北京

去阅读

用大模型挖代码漏洞，几个AI大厂已经具备很强的能力了。OpenAI 的 Codex Security 扫了 120 万次 commit，找到 1 万多个高危问题，误报率比传统扫描器低一半以上。但它深度绑定 OpenAI，在国内用不了。我找了两个开源方案——DeepAudit 和 ARM Metis，拿自己的项目实测了一轮，看看 AI 漏洞挖掘能否投入生产使用。

先说结论

两个工具都跑完了，结果如下：

DeepAudit（项目级深度审计）：扫了开源项目 AgentBridge，2 万行代码，448 个文件。

10 个发现里，2 个是工具自己写了攻击脚本在沙箱里跑通的真漏洞，8 个是\"这里可能有问题但没跑通\"的疑似项。

ARM Metis（轻量级 CLI）：我写了一个故意带 4 个漏洞的 Flask 文件，用同一个模型跑。

4/4 全部检出，CWE 编号和严重性分级都准。

总结：AI 漏洞挖掘可信，但有条件。能发现传统扫描器漏掉的配置错误和逻辑漏洞，也会报出一堆\"疑似\"需要人工判断。不是银弹，但作为安全检查的一层补充，已经够用了。

它们怎么做到的

不是\"拿大模型读一遍代码就完事\"。两个工具的实现思路不一样。

DeepAudit：4 个 Agent 协作 + 沙箱验证

模拟一个安全团队的工作方式，四个 Agent 各司其职：

最后一个 Verification 是关键。很多工具报完\"疑似 SQL 注入\"就结束了，DeepAudit 会自己写一段攻击代码在沙箱里跑，跑通了才算真漏洞。这次扫描里，10 个发现有 2 个跑通了，8 个没跑通——没跑通的就标成\"未验证\"，不充数。

Agent 审计主界面：左侧 Agent 树（Orchestrator → Recon + Analysis + Verification），右侧实时 Activity Log

Analysis Agent 不是盲目扫描。它内置了 22 个漏洞知识模块（SQL 注入、XSS、认证绕过、SSRF 等），每个模块都有 CWE 编号、OWASP 分类、各语言的危险写法和安全写法对比。还有 7 个框架专项知识（Django、Flask、FastAPI、Express 等），知道框架自身的安全机制哪里可信、哪里可能被绕过。

这次扫描 AgentBridge（FastAPI 项目），Analysis Agent 就用了 FastAPI 的框架知识来判断哪些路由需要认证、哪些不需要。

沙箱配置：无网络（network\_mode=none）、只读文件系统、非 root 用户、禁止提权、512MB 内存限制。PoC 代码不会影响你的项目，也不会外发数据。

ARM Metis：tree-sitter 可达性分析 + LLM 判断

Metis 更轻量。用 tree-sitter 做代码的语法解析和可达性分析，能理解跨文件调用关系（不只是看单个文件的模式），然后把可疑代码片段发给 LLM 做最终判断。

没有 Agent 协作，没有沙箱验证，是一次 LLM 调用完成所有工作。速度快，但不会有\"攻击脚本跑通了才算真漏洞\"这一步。

两个工具对比

简单说：DeepAudit 是重武器，Metis 是轻骑兵。大项目用 DeepAudit 做全面审计，日常开发用 Metis 扫一下改动的文件。

实测过程

DeepAudit 扫 AgentBridge

AgentBridge 是一个开源项目，Python 后端 176 个文件约 16,000 行代码，TypeScript 前端 68 个文件约 4,600 行，总共 21,000 行代码。用 DeepSeek V4 Flash 做推理。

安装：

需要 Docker。下载配置文件，启动：

# 第一步：下载配置文件（国内镜像加速）curl -fsSL https://raw.githubusercontent.com/lintsinghua/DeepAudit/v3.0.0/docker-compose.prod.cn.yml \\  -o docker-compose.yml # 第二步：启动（首次会拉取镜像，约 800MB，耐心等）docker compose up -d

启动后访问 http://localhost:3000。

登录界面：终端风格 UI，支持邮箱注册

配置模型：

在 Web 界面的「系统管理」页面，选 OpenAI 兼容提供商，填 Key 和 Base URL。

也支持通义千问、智谱 GLM、Kimi、豆包、MiniMax 等，每种都有单独的 Key 输入框。Key 是按用户隔离的。

扫描：

导入 GitHub 仓库地址，点「Agent 审计」，四个 Agent 自动开始工作：

项目管理页：导入 GitHub 仓库，识别出 Python + TypeScript

1. Recon 先扫目录结构，识别出 Python + TypeScript、FastAPI 框架、PostgreSQL 数据库
2. Analysis 逐文件审查，重点看认证、数据库查询、配置文件
3. Verification 对发现的疑似漏洞写 PoC，在沙箱里验证
4. Orchestrator 汇总结果，生成报告

整个过程在 Web 界面实时可见，能看到每个 Agent 的思考过程。比如 Analysis Agent 会说：\"我发现所有数据库查询都用了参数化占位符 $1/$2，这部分是安全的。现在检查 admin 路由文件，Recon 标记了 admin\_\*.py 有风险。\"

审计进行中：Analysis Agent 正在思考，30% 进度，已消耗 338.8k tokens

发现的 2 个真漏洞：

漏洞 1：认证绕过（高危，95% 置信度）

# settings.pyauth_required: bool = False

auth\_required 默认是 False。意思是：默认配置下，所有 API 接口不需要登录就能访问。DeepAudit 给的 PoC：

curl http://target/api/admin/users# 直接返回数据，不需要任何认证

这个确实是我的疏忽——开发时为了方便调试设成 False，忘了改回来。

漏洞 2：Cookie 不安全（低危，85% 置信度）

# settings.pyauth_cookie_secure: bool = False

会话 Cookie 的 Secure 标志是 False，意味着 HTTP 连接下 Cookie 是明文传输的。中间人攻击可以截获会话令牌。

两个漏洞都是settings.py里的配置问题。这很合理——配置错误是最常见的安全漏洞来源，也是传统扫描器最容易漏掉的（因为它们不理解\"这个默认值在生产环境意味着什么\"）。

Metis 扫测试文件

Metis 不需要 Docker，pip install 就能用：

python3 -m venv metis-env && source metis-env/bin/activatepip install git+https://github.com/arm/metis.git

配置一个 metis.yaml：

llm_provider:  name: ”openai”  base_url: ”https://api.deepseek.com/v1”  model: ”deepseek-chat”  api_key: ”sk-xxx”

也支持 Ollama、vLLM、llama.cpp 等本地模型，只要填对应的 base\_url 就行。

扫描命令：

metis --config metis.yaml --codebase-path ./your-project \\  --non-interactive --command ”review_code” \\  --output-file result.json

我写了一个故意带 4 个漏洞的 Flask 文件：

@app.route('/run', methods=['POST'])def run_cmd():    cmd = request.form.get('cmd')    result = os.popen(cmd).read() # 命令注入    return result @app.route('/read', methods=['GET'])def read_file():    path = request.args.get('path')    with open(path, 'r') as f: # 路径穿越        return f.read() @app.route('/eval', methods=['POST'])def eval_expr():    expr = request.form.get('expr')    return str(eval(expr)) # eval 注入 if __name__ == '__main__':    app.run(debug=True) # debug 模式

4 个漏洞全部检出，CWE 编号和严重性分级都准。Metis 用 tree-sitter 做可达性分析，能理解跨文件调用关系，不只是简单的模式匹配。

扫描前必须做的事：清理密钥

这一点容易忽略，但很重要。AI 漏洞挖掘工具会把代码片段发给 LLM 分析，如果你的项目里有硬编码的密钥、数据库密码、内网地址，这些内容会随代码一起发送到模型 API。

扫描前检查这几项：

• .env

文件：替换成占位符，比如 API_KEY=sk-placeholder
* settings.py

/ config.yaml：数据库密码、Redis 密码用占位符替代
* 硬编码的 Token、密钥：搜索 sk-、password、secret、token 关键词
* 内网地址：如果有 192.168.x.x、10.x.x.x 这类内部服务地址，建议也脱敏

扫完之后改回来就行。这步不费事，但能避免\"查漏洞的过程中反而泄露了密钥\"这种尴尬。

代码会上传，这个风险怎么理解

用云端模型（DeepSeek、通义千问等）做漏洞挖掘，本质是把代码发到第三方服务器。这一点跟传统扫描器（本地跑规则、代码不出机器）有根本区别。

但换个角度看，如果你已经在用 Cursor、Copilot 这类 Vibe Coding 工具写代码，你的代码早就经过云端 API 走了一轮了。AI 漏洞挖掘只是多了一个通道，风险模式是一样的。

对于有信息安全管理规定的大厂，这个问题没有讨论空间——只能用内部部署的模型，Vibe Coding工具也好 安全软件也好，都得走私有化。这些工具都支持 本地，代码完全不出内网。

但对于大多数 B/S 业务系统，情况不太一样。表单、审批、报表这类系统的代码本身价值不高，核心价值在数据和业务流程。这类系统真正的风险不是\"代码被人看到\"，而是\"代码有漏洞导致数据泄露\"。用云端 API 做安全审计，是用一个可接受的暴露去换发现真实漏洞的机会，这笔账是算得过来的。

简单说：代码值钱用本地模型，代码不值钱但安全重要用云端 API，两头都敏感的用本地模型。

不足

诚实说：

• 10 个发现只有 2 个已验证。8 个未验证的发现置信度只有 50-60%，本质上是\"建议你看看这里\"，不是\"这里一定有问题\"。需要人工判断。
• 扫描速度与挖掘能力取决于模型。DeepSeek V4 Flash 响应快，10 分钟扫完 448 个文件。如果模型慢，时间会更长。对漏洞挖掘的能力十分依赖模型的能力，随着国内大模型的发展，模型对安全漏洞的捕获也会越来越强

适合谁

工具链接

• DeepAudit：https://github.com/lintsinghua/DeepAudit · 6.8k stars · AGPL-3.0
• ARM Metis：https://github.com/arm/metis · 821 stars · Apache-2.0

> 更多工具实测，欢迎关注「不看Star看疗效」知乎专栏