AI 写的代码安全吗？2026 审查清单与实操

AI 写的代码安全吗？残酷的答案是：功能对，安全不一定。Veracode 持续两年多的跟踪测试给出了一个让人不太舒服的结论——模型写出语法正确、能跑的代码的比例已经超过 95%，但安全通过率始终卡在 55% 左右，两年几乎没有改善。也就是说，模型越来越会写代码，却没有越来越会写安全的代码。更麻烦的是，AI 生成代码不像新手代码那样一眼看得出粗糙，它排版整齐、命名规范、注释齐全，能轻松骗过肉眼审查。这篇文章讲清楚 AI 生成代码的安全风险到底在哪、怎么系统性地审。

先看数据：问题有多严重

Veracode 的 GenAI 代码安全报告累计测试了 150 多个大模型，用固定的编码任务观察模型在「有安全写法和不安全写法可选」时会选哪个。2026 年春季的更新结论如下：

另一组数据来自实际线上产品：2025 年 5 月有安全研究者扫描了用某 vibe coding 平台生成并部署的 1645 个 Web 应用，其中 170 个存在会泄露个人信息的漏洞，约 10% 的严重漏洞率。这些不是练习项目，是真实上线、真实收集用户数据的站点。

AI 代码最常出问题的六类

1. 1输出未转义导致的 XSS：把用户输入直接拼进 HTML、直接 innerHTML、React 里随手用 dangerouslySetInnerHTML。这是通过率最低的一类，AI 几乎不会主动防。
2. 2鉴权与越权：接口写出来了，但只检查「登录了没」，不检查「这条数据是不是你的」。AI 很擅长写业务逻辑，很不擅长想「别人改个 id 会怎样」。
3. 3密钥硬编码：把 API key、数据库密码直接写进源码或前端代码。AI 为了让示例能跑，天然倾向于填真实值而不是读环境变量。
4. 4日志注入与敏感信息落日志：把未经处理的用户输入或者整个请求体打进日志，既能被伪造日志，又可能把密码、token 写进磁盘。
5. 5依赖问题：AI 凭记忆推荐的库版本往往是训练时的旧版，可能带着已知 CVE；更糟的是推荐了根本不存在的包（见下一节）。
6. 6错误处理过度暴露：直接把异常栈、SQL 语句、内部路径返回给前端。开发时方便，上线就是给攻击者递地图。

新型风险：幻觉包名与 slopsquatting

这是 AI 编程时代独有的一类供应链攻击，值得单独讲。USENIX Security 2025 的一项研究测试了 16 个大模型、57.6 万个样本，发现约 19.7% 的 AI 推荐的依赖包在包管理器里根本不存在——模型把包名编出来了。更关键的是，这些幻觉不是随机噪声：同一个提示词重复跑十次，43% 的幻觉包名每次都会出现。

攻击者据此发明了 slopsquatting：批量拿常见提示词去问各家编程 agent，收集模型反复编造的包名，然后抢先把这些名字注册到 npm、PyPI 上，塞进恶意代码。等你的 AI 助手再一次推荐这个包、你顺手 npm install，恶意代码就进来了。它和传统的 typosquatting（抢注拼错的名字）本质不同——攻击者不需要模仿一个真包的名字，只需要一个 AI 会稳定编出来的名字。

三层防线：写之前、写之中、合并前

第一层：写之前——把安全要求写进上下文

模型在「安全写法」和「省事写法」之间随机选，那就别让它随机。把安全约束固化进 CLAUDE.md 或 AGENTS.md，让每次任务都自带这些前提，比每次单独提醒有效得多。

## 安全约束（每次写代码都必须遵守）

- 所有用户输入在输出到 HTML 前必须转义；禁止 innerHTML / dangerouslySetInnerHTML
- 所有数据库查询使用参数化查询，禁止字符串拼接 SQL
- 任何涉及数据读写的接口，除了校验登录状态，必须校验「资源属于当前用户」
- 密钥、token、数据库密码一律从环境变量读取，禁止出现在源码或前端
- 日志中禁止打印完整请求体、密码、token；用户输入入日志前先做换行转义
- 返回给前端的错误信息不得包含异常栈、SQL 语句、文件路径
- 新增依赖前先说明：包名、用途、周下载量，等我确认后再安装

第二层：写之中——让 AI 审自己的代码

AI 审代码比 AI 写代码靠谱，因为审查时它不需要「让功能跑起来」这个压力，可以专心挑毛病。Claude Code 内置了 /security-review 命令（付费计划可用），在提交前直接跑一次，它会扫描改动并给出漏洞说明。这个命令的提示词是可定制的：把官方仓库里的 security-review.md 复制到项目的 .claude/commands/ 目录下改成你自己的规则即可。

没有内置命令的工具，用一段固定提示词也能达到类似效果。关键是别问「这段代码有问题吗」——那样它多半回答「看起来不错」。要给它明确的攻击者视角和清单：

以攻击者视角审查这次改动，逐项回答，不要笼统地说「看起来没问题」：

1. 未转义输出：哪些地方用户输入会进入 HTML / 日志 / 命令行？
2. 越权：每个新增接口，换成另一个用户的 id 会发生什么？
3. 密钥：有没有硬编码的 key、密码、token？前端能看到什么？
4. 输入校验：哪些参数没做类型/长度/范围校验？
5. 错误处理：出错时返回给前端的内容会泄露什么内部信息？
6. 依赖：新增了哪些包？分别是干什么的、周下载量多少？

对每一条，要么指出具体文件和行号，要么明确说「本次改动不涉及」。

第三层：合并前——自动化扫描兜底

人工审查会疲劳，尤其是 AI 产出速度远超人类审查速度的时候。真正的兜底必须是自动化的，挂在 CI 上，不通过就不许合并。

推荐的最小组合：gitleaks（防密钥泄露）+ Semgrep 或 CodeQL（防注入类）+ 依赖审计。这三样都免费，配一次管很久。传统 SAST 工具擅长找已知模式，AI 审查擅长理解业务逻辑上的越权问题，两者互补，不要只用一种。

不写代码的人，最少要做哪几件事

如果你是用 AI 做产品但不懂代码的人，上面那套 CI 流程可能太重。以下是投入产出比最高的五件事，做完能挡掉绝大部分真实事故：

• 把密钥全部搬进环境变量，并确认前端代码里搜不到任何 key（浏览器里按 F12 搜一下你的 key 前几位）
• 让 AI 逐个接口回答「换一个用户的 id 会怎样」，这一条能挡掉最常见的数据泄露
• 上线前把仓库设为私有，并用 gitleaks 扫一遍历史提交，密钥一旦提交过就必须作废重发
• 数据库开只读账号给查询用，写权限的账号只给应用本身，绝不给 AI agent
• 新增的每个依赖包都自己去 npm 或 PyPI 页面看一眼：发布时间、下载量、有没有 GitHub 仓库

AI 把写代码的成本降到了几乎为零，于是瓶颈就整体挪到了「判断代码对不对、安不安全」这一侧。这个能力恰恰不是靠工具能自动获得的——它需要你理解常见漏洞长什么样、知道该问 AI 什么问题、能看懂扫描结果。这也是 AI 时代开发者真正的护城河所在。想系统地补上从需求拆解、AI 协作到交付验收的完整链路，欢迎来 IMAI 看看我们的实战课程。