基于 AI 大模型的自动化代码安全审计系统,帮助开发者快速识别代码中的安全漏洞并提供修复建议。
本项目对 AI 审计行为施加三条不可违反的硬约束,从根源上杜绝幻觉和编造,确保每一条漏洞报告都有据可查:
| 铁律 | 禁止行为 | 正确做法 | 违反后果 |
|---|---|---|---|
| 铁律 1:禁止猜测文件路径 | 凭记忆或推测引用文件路径 | 只能引用实际提供给 AI 的代码内容 | 基于不存在文件的分析全部无效 |
| 铁律 2:禁止编造代码片段 | 凭印象描述代码内容,或引用未实际看到的代码 | 必须引用实际提供的代码行号和内容 | 基于编造代码的漏洞分析全部无效 |
| 铁律 3:禁止报告未见代码中的漏洞 | 在未实际看到代码的情况下报告漏洞 | 先看到代码 → 分析代码 → 才能报告漏洞 | 未见代码中的漏洞报告直接标记为无效 |
违反任何一条铁律将导致审计结果无效。
三条铁律的设计动机:大语言模型在代码审计场景中容易产生"幻觉"——虚构不存在的文件路径、编造并未出现的代码片段、或对未曾读取的文件断言存在漏洞。这三条铁律以最高优先级约束 AI 行为,将审计过程锚定在实际代码证据上,从而保证报告的可信度和可追溯性。
代码缺陷存在 ≠ 漏洞可利用
系统要求 AI 在报告每个漏洞前,必须基于实际代码逐项验证以下 9 个维度:
| # | 验证维度 | 说明 |
|---|---|---|
| 1 | 缺陷真实性 | 代码缺陷是否真实存在,是否存在被忽略的上游防护 |
| 2 | 路径可达性 | 代码路径是否可达(排除死代码、遗留代码、条件不满足) |
| 3 | 输入可达性 | 用户输入是否能真正传递到危险点 |
| 4 | 实际可利用性 | 攻击者是否能在实际环境中利用 |
| 5 | 系统性设计 | 该模式是否是框架的系统性设计而非个别遗漏 |
| 6 | Source 类型 | Source 是否为外部用户输入而非受信的服务器端代码 |
| 7 | 自攻击检验 | 利用前提权限是否已超越漏洞本身能力 |
| 8 | 设计意图 | 该行为是否是框架预期的设计行为而非缺陷 |
| 9 | 运行时可行性 | 理论攻击在实际运行时环境中是否可行 |
错误地将安全代码标记为"漏洞"会造成误导。准确性优于数量——一个准确的漏洞报告远胜十个误报。
每一个 AI 检测出的潜在漏洞,在写入最终报告之前,都必须通过四轮递进式质疑验证。任何一轮未通过都会影响最终判定:
潜在漏洞 → Round 0 → Round 1 → Round 2 → Round 3 → 最终判定 │ │ │ │ ▼ ▼ ▼ ▼ 可达性 代码逻辑 数据流 可利用性
各轮详细规则:
| 轮次 | 名称 | 质疑问题 | 通过条件 | 淘汰条件 |
|---|---|---|---|---|
| Round 0 | 可达性与设计意图 | 代码路径是否可达? | 路径可达且非设计行为 | 死代码/遗留代码/设计预期行为 |
| Round 1 | 代码逻辑质疑 | 危险代码模式是否真实存在? | 置信度为 MEDIUM 或 HIGH | 置信度为 LOW → 直接淘汰 |
| Round 2 | 数据流质疑 | 用户输入能否到达危险点? | 存在清晰的数据流描述(>10 字符) | 数据流不明确或不存在 |
| Round 3 | 可利用性质疑 | 攻击者能否构造有效攻击? | 置信度 HIGH 或严重等级 CRITICAL | 普通漏洞置信度不足(组合漏洞有豁免规则) |
最终判定标准:
| 通过轮次 | 判定状态 | 处理方式 |
|---|---|---|
| 4/4 通过 | passed — 确认漏洞 | 写入最终报告 |
| 2-3/4 通过 | partial — 保留观察 | 写入报告并标注待验证 |
| 0-1/4 通过 | failed — 误报 | 过滤移除,不进入最终报告 |
组合函数漏洞(涉及跨文件数据流的漏洞)在第 3 轮享有特殊豁免规则——只要置信度不为 LOW 即可通过,因为跨文件漏洞天然更难确认但危害往往更大。
| 漏洞类型 | CWE 编号 | 默认等级 | 描述 |
|---|---|---|---|
| SQL 注入 | CWE-89 | HIGH | 检测 SQL 语句拼接漏洞,区分参数化查询(安全)和字符串拼接(危险) |
| XSS 跨站脚本 | CWE-79 | HIGH | 检测反射型、存储型、DOM 型 XSS,覆盖 innerHTML/v-html/dangerouslySetInnerHTML |
| 硬编码密钥 | CWE-798 | HIGH | 检测 API Key/Token/密码/私钥/连接字符串,自动排除占位值和环境变量引用 |
| 命令注入 | CWE-78 | CRITICAL | 检测 eval/exec/system/child_process 等危险调用 |
| 路径遍历 | CWE-22 | HIGH | 检测文件路径操控漏洞 |
| SSRF | CWE-918 | HIGH | 检测服务端请求伪造漏洞 |
| 不安全反序列化 | CWE-502 | HIGH | 检测 pickle.loads/ObjectInputStream/unserialize 等 |
| 认证缺陷 | CWE-287 | HIGH | 检测认证/授权实现缺陷 |
| 敏感数据泄露 | CWE-200 | MEDIUM | 检测错误信息泄露、日志中的敏感数据 |
| XXE | CWE-611 | HIGH | 检测 XML 外部实体注入 |
| 不安全随机数 | CWE-330 | LOW | 检测在安全场景中使用弱随机数生成器 |
| 原型污染 | CWE-1321 | HIGH | 检测 JavaScript 原型链污染 |
| CSRF | CWE-352 | MEDIUM | 检测跨站请求伪造 |
| IDOR | CWE-639 | MEDIUM | 检测不安全的直接对象引用 |
系统特别关注跨函数、跨文件的组合型安全问题:
| 模式 | 说明 |
|---|---|
| 跨函数数据流污染 | 函数 A 接收用户输入但不做清洗 → 传递给函数 B → 函数 B 将其用于危险操作 |
| 权限提升链 | 普通用户通过调用函数 A 修改状态 → 绕过函数 B 的权限检查 |
| 竞态条件 (TOCTOU) | 函数 A 检查权限 → 函数 B 在检查后、操作前修改数据 |
| 错误处理泄露链 | 函数 A 的异常被函数 B 捕获 → 函数 B 将错误详情返回客户端 |
| 认证/授权绕过组合 | 某些函数组合调用时跳过了中间的认证/授权检查 |
| 原型污染传播 | 函数 A 中的对象合并操作被污染 → 影响函数 B 的逻辑判断 |
| 二阶注入 | 函数 A 存储未过滤的用户输入到数据库 → 函数 B 读取并用于危险操作 |
| 回调/事件驱动漏洞 | 事件处理函数之间的数据传递缺乏验证 |
┌──────────────────────────────────────────────────────┐ │ Nginx (端口 80) │ │ 静态资源服务 + API 反向代理 │ ├────────────────────┬─────────────────────────────────┤ │ React 前端 SPA │ Express 后端 API (端口 3001) │ │ TypeScript + Vite │ Node.js 20 + MongoDB 驱动 │ │ Tailwind + DaisyUI│ AI 模型调用 (OpenAI 兼容格式) │ └────────────────────┴──────────┬──────────────────────┘ │ ┌────────┴────────┐ │ MongoDB 7 │ │ 数据持久化 │ └─────────────────┘
| 层级 | 技术选型 |
|---|---|
| 前端框架 | React 19 + TypeScript |
| 构建工具 | Vite 6 |
| UI 样式 | Tailwind CSS 3 + DaisyUI 4 |
| 路由 | React Router 6 |
| 后端 | Node.js 20 + Express 4 |
| 数据库 | MongoDB 7 |
| AI 模型 | OpenAI 兼容 API(Claude / GPT / DeepSeek / Qwen / 混元等) |
| 部署 | Docker Compose(Nginx + Node.js + MongoDB) |
AI_code_review_agent/ ├── src/ # 前端源码 │ ├── components/ # 可复用组件 │ │ ├── FileUpload.tsx # 文件上传(ZIP 拖拽/选择) │ │ ├── TaskProgress.tsx # 任务进度与实时日志 │ │ ├── ReportViewer.tsx # 审计报告查看器 │ │ ├── VulnerabilityCard.tsx # 漏洞详情卡片 │ │ ├── CodeHighlight.tsx # 代码高亮展示 │ │ ├── Navbar.tsx # 顶部导航栏 │ │ └── Footer.tsx # 页脚 │ ├── pages/ # 页面组件 │ │ ├── HomePage.tsx # 首页(上传入口) │ │ ├── TaskPage.tsx # 任务详情(进度/日志/报告) │ │ ├── HistoryPage.tsx # 审计历史记录 │ │ └── SettingsPage.tsx # 模型配置管理 │ ├── types/audit.ts # TypeScript 类型定义 │ ├── utils/api.ts # API 请求封装 │ ├── App.tsx # 应用路由入口 │ └── index.css # 全局样式 ├── server/ # 后端 API 服务 │ ├── src/ │ │ ├── index.js # Express 入口 + 路由挂载 │ │ ├── routes/ │ │ │ ├── tasks.js # 任务 CRUD + 报告数据 │ │ │ ├── audit.js # 触发安全审计 │ │ │ ├── report.js # 触发报告生成 │ │ │ └── model-configs.js # 模型配置管理 │ │ ├── services/ │ │ │ ├── ai.js # AI 模型调用(OpenAI 兼容) │ │ │ ├── analyzeCode.js # ZIP 解压 + 代码分块 │ │ │ ├── securityAudit.js # 审计引擎(并发/重试/续审) │ │ │ └── generateReport.js # 报告生成(Markdown + JSON) │ │ └── utils/db.js # MongoDB 连接与索引 │ ├── Dockerfile # 后端容器配置 │ ├── .env.example # 环境变量模板 │ └── package.json ├── shared/prompts/ # AI 审计 Prompt 模板 ├── docker-compose.yml # Docker Compose 编排 ├── Dockerfile # 前端多阶段构建(Vite → Nginx) ├── nginx.conf # Nginx 反向代理配置 ├── .env # 前端环境变量 └── package.json # 前端依赖
# 克隆项目
git clone <repo-url>
cd AI_code_review_agent
# 构建并启动所有服务
docker compose up -d
# 查看运行日志
docker compose logs -f
启动后访问 http://localhost:8080
自定义端口:
APP_PORT=3000 docker compose up -d
停止服务:
docker compose down
适用于需要修改代码并热重载调试的场景。
1. 启动 MongoDB
docker run -d --name mongo -p 27017:27017 mongo:7
2. 启动后端
cd server
npm install
# 创建 .env(或复制 .env.example)
cat > .env << EOF
MONGODB_URI=mongodb://localhost:27017/ai_code_review
PORT=3001
DATA_DIR=./data
EOF
npm run dev
3. 启动前端(新终端)
# 回到项目根目录
npm install
npm run dev
前端开发服务器默认在 http://localhost:5173 启动,API 请求自动代理到后端 localhost:3001。
首次使用前需配置模型:
在「历史记录」页面查看所有审计任务,支持分页浏览和删除。
前端 (.env):
| 变量 | 默认值 | 说明 |
|---|---|---|
VITE_API_BASE_URL | /api | API 请求路径前缀 |
后端 (server/.env):
| 变量 | 默认值 | 说明 |
|---|---|---|
MONGODB_URI | mongodb://mongo:27017/ai_code_review | MongoDB 连接地址 |
PORT | 3001 | 后端服务端口 |
DATA_DIR | /app/data | 上传文件和报告存储路径 |
Docker Compose:
| 变量 | 默认值 | 说明 |
|---|---|---|
APP_PORT | 8080 | 对外暴露的访问端口 |
| 参数 | 值 | 说明 |
|---|---|---|
| 批次并发数 | 2 | 每批同时审计的代码块数量 |
| 单次执行上限 | 100 块 | 单次执行的最大代码块数 |
| AI 请求超时 | 150s(递增至 210s) | 首次 150s,每次重试增加 30s |
| 最大重试次数 | 2 | 单个代码块失败后的重试次数 |
| 大代码块阈值 | 120 行 | 超过此行数自动拆分 |
| 安全退出阈值 | 540s | 超时后保存进度,下次续审 |
内置 10 种预设模板,也可自定义任何兼容 OpenAI API 格式的模型:
| 模型 | 说明 |
|---|---|
| GPT-4o | OpenAI 旗舰模型 |
| GPT-4o Mini | OpenAI 轻量模型 |
| Claude Opus 4 | Anthropic 旗舰模型 |
| Claude Sonnet 4 | Anthropic 高性价比模型 |
| DeepSeek V3 | DeepSeek 通用模型 |
| DeepSeek R1 | DeepSeek 推理模型 |
| Qwen Max | 通义千问旗舰模型 |
| Hunyuan Turbo | 腾讯混元高性能推理模型 |
| Hunyuan Pro | 腾讯混元效果最优模型 |
| 自定义模型 | 任何兼容 OpenAI Chat Completions API 的端点 |
| 集合名 | 用途 |
|---|---|
audit_tasks | 审计任务信息(状态、文件路径、技术栈等) |
audit_results | 审计结果(按文件存储漏洞列表) |
audit_logs | 审计日志(实时进度、思考过程等) |
audit_code_files | 解压后的代码块 |
audit_vulnerabilities | 临时漏洞数据(报告生成后清理) |
model_configs | AI 模型配置 |
# Docker 操作
docker compose up -d # 启动服务
docker compose down # 停止服务
docker compose logs -f # 查看日志
docker compose up -d --build # 重新构建并启动
# 本地开发
npm run dev # 启动前端开发服务器
npm run build # 构建前端
npm run lint # ESLint 检查
npm run format # Prettier 格式化
cd server && npm run dev # 启动后端开发服务器
本项目采用 Apache License 2.0 许可证。