文章总结： 本文探讨AI生成代码的安全风险，指出AI代码漏洞密度是人写代码的2.74倍，且开发者对AI代码过度自信。文章提供可操作的复查清单，包括三个必问、四个必看和两道机器关卡，强调将AI输出视为第一稿而非最终合并代码，人工复核不可外包。 综合评分： 85 文章分类： 安全开发,漏洞分析,安全意识,安全工具,安全建设

让 AI 改了五遍，漏洞多了 37.6%：一份 AI 编码安全复查清单

原创

奋斗的小浪 奋斗的小浪

船山信安

2026年9月17日 00:00 湖南

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

安全开发 · SECDEV

本篇核心：这篇文章我拖了很久才写。不是没得写，是不知道该怎么说才不像在唱衰。直到把这一年评审过的、有 AI 参与的代码重新翻了一遍，我才想清楚一件事——问题从来不在 AI 写得好不好，而在于它写完之后，我们看它的眼神变了。

01那个四十行的接口，写得比我工整

这类提交递到眼前的时候，人是很容易直接点头的。

四十来行，变量命名讲究，注释一句一句排着，异常捕获了，分页也考虑了，单元测试全绿。写它的人多半还会补一句：基本是 AI 生成的，自己就调了两个参数。说实话，它比我见过的大部分手写代码要体面。

但这类代码我见过的次数不算少了。它们的破绽往往出现在同一个位置。

问题出在接口的主体逻辑上。它先查了「请求的人是谁」——查得很规范，token 校验、过期判断、失效重登，一样不少。然后它拿着这个用户的身份，直接去数据库取数据了。中间没有任何一行问过：这条数据是这个人的吗。

前半句它想到了，后半句没有。

登录了，不等于你能看。这两件事在代码里差着一整个 鉴权 层，而在人类的直觉里，它们常常被当成一件事。因为这个错觉，它在今年的 OWASP Top 10 里排第一——不是存文档里，是实战里被反复打穿。

一句话：AI 最大的本事是写出「很像那么回事」的代码。而安全检查恰恰是反直觉的——它关心的不是这段代码顺不顺眼，是它缺的那半句话。

02数字在这，不用形容词

这类故事讲多了容易被认为是挑刺。所以把数据摆出来。

安全厂商 Veracode 测了一百多个大模型在安全敏感编码任务上的表现，结果45% 的 AI 生成代码至少命中一项 OWASP Top 10。分语言看差距很吓人：Java 的失败率到了 72%，C# 45%，JavaScript 43%，Python 38%。其中 XSS 相关的不安全生成率 86%，日志注入 88%。

另一组常被引用的是470 个开源 Pull Request 的对照分析：AI 生成代码的漏洞密度，是人写代码的 2.74 倍。

再往前，纽约大学团队那篇《Asleep at the Keyboard?》（IEEE S&P 2022）是这一行的老底子：对着 MITRE 的 CWE Top 25 设计 89 个场景，让 Copilot 生成 1689 个补全，39.33% 的首选建议带洞，把全部建议算进去是 40.73%。扎的是最朴素的几类：字符串拼接的 SQL、没做边界检查、随机数用得不安全。

到 2026 年 2 月，有人重做了类似实验——87 个相同 prompt 发给 6 个模型，522 份样本用 5 个 SAST 工具扫，每条结论人工验证，总漏洞率降到 25.7%。最好的模型 19.5%。

看出来了吗：趋势在变好，但从来没有归零。

| 研究 | 样本 | 漏洞比例 | | — | — | — | | NYU / IEEE S&P 2022 | 1689 个补全 / 89 场景 | 39.3%（首选） | | Veracode 2025 | 100+ 大模型 | 45%（OWASP Top 10） | | 470 个 PR 对照分析 | AI 代码 vs 人写代码 | 密度 2.74 倍 | | 多模型复测 2026-02 | 522 样本 / 6 模型 | 25.7% |

表 ｜ AI 生成代码漏洞率的主流测量（来源见文末）

03真正危险的一半，还没说

上面这些数字，都还不是最麻烦的。

斯坦福那项由密码学家 Dan Boneh 参与的对照实验，一共找了 47 名开发者。用 AI 助手的那一组，写出来的代码确实更不安全——这没什么意外。

意外的是后半段：这一组人，同时还更倾向于认为自己的代码是安全的。

我把这句话读了两遍。它不是说 AI 让人变笨了，而是说 AI 让人变更敢了。

为什么会这样？因为 AI 的输出有一种非常强的「完成感」。命名规整、注释齐全、格式漂亮，读起来像成品。而人类写代码的草稿阶段，往往是丑的——变量乱起、函数名带 test2、中间还留着几个 print。那种丑陋其实是个提醒：这段代码还没完工。

AI 把这个提醒抹掉了。

注意：知道自己写的是危险代码的团队，会用加倍的代码评审去补偿；觉得自己写得挺好团队，什么都不会加。confidently wrong，比 unsafe 更贵。

04别让它给自己当医生

发现 AI 写的代码有安全问题，最自然的操作是什么？把报错贴回去，说「这里不安全，改一下」。

这个动作看起来天经地义，但有人专门做了实验。

2025 年一项研究（发表于 IEEE-ISTAS 2025）拿 400 份代码样本，用 GPT-4o 反复迭代改进，跑了 40 轮。结论是：迭代五轮之后，严重漏洞的数量上升了 37.6%。

不是修不好，是修着修着又添新的。

原因其实很好理解。模型每次改的是一个局部函数，它优化的目标是「让眼前这段看起来没问题」，而不是「让整个调用链安全」。你让它补一个输入校验，它可能顺手把错误信息打得更详细了一点；你让它修复 SQL 拼接，它可能换了套 ORM 但把查询权限放大了一圈。每一轮单看都更专业，叠起来却在往副作用走。

企业侧的统计也印证了这种「没人看全局」的代价。对 Fortune 50 企业内部 AI 生成代码的抽样分析发现：权限提升路径多了 322%，设计缺陷多了 153%，密钥暴露增加了 40%。

还有一组更生活化的数字：有人扫了大约 5600 个「纯 vibe coding」做出来的应用，找出 2000 多个漏洞和 400 多个明文暴露的密钥。密钥不是被攻破的，是写死然后被提交的。

所以这条我要说得直白一点：让 AI 审 AI，等于让一个人给自己批改卷子。 它可以当助手查一遍，但不能当终审。

05它在让你下载不存在的东西

这一节可能是全文最值得你记住的。

USENIX Security 2025 上有一项很扎实的研究：研究者让 16 个不同的模型生成了 57.6 万份 代码样本，然后去核对它们推荐的第三方包名称是否真实存在。

结果是 19.7% 的包名压根不存在——累计超过 20.5 万个不存在的包名字。开源模型幻觉率 21.7%，商业模型 5.2%。

到这一步还只是「跑不通」的麻烦。真正让它变成安全问题的，是下一个发现：研究者把这些 prompt 重复跑了十次，43% 的幻觉包名，十次里次次出现。

可预测，就意味着可以被提前占位。

攻击者不需要攻破模型，不需要攻破你的机器，只需要把那些模型大概率会「想起来」的包名，提前去 npm 或 PyPI 上注册一遍，里面放点东西。下一个把这些 pip install 命令原样复制进终端的开发者，就成了那个执行者。这个手法现在有个名字，叫 slopsquatting（垃圾抢注）。

2026 年的复测里，新一代模型的幻觉率降到了 4.6%–6.1%。降得很好，但没到零，而在 CI 每天成千上万次的安装建议里，这个值依然足够撑起一次成功的投毒。

要点：模型记不住的包名，和模型写不出的鉴权判断，是同一件事的两面——它在补全「常见的样子」，而不是在验证「真实的存在」。

06能今天就用的复查清单

说完了问题，给点能落地的。下面这些不依赖任何付费工具，今天下午就能开始做。

三个必问（合并 AI 生成代码之前，问完这三个问题再点按钮）

1它验证了谁要看，还是验证了能不能看？（认证不等于授权）

2新引入的包，真的存在吗？去 npm / PyPI 看一眼发布时间和维护者。

3失败的时候，它往哪里走？很多AI写的代码，错误处理是「打印堆栈然后继续」。

四个必看（评审时优先翻这四个位置，其余可以后看）

| 位置 | AI 最常在这里漏什么 | | — | — | | 接口入口 | 校验了登录态，没校验资源归属（越权） | | 配置文件 | 默认密码、全开端口、调试开关忘了关 | | 依赖清单 | 包名拼错或根本不存在，可被抢注 | | 异常分支 | catch 里吞掉异常继续执行，或把堆栈返回给前端 |

两道机器关卡（拦住绝大多数问题，且不会拖慢团队）

第一道，放在 IDE 里。 用安全插件在本地编辑器里做提示，让开发者写代码那一刻就看到——而不是等到流水线报错。这是降低抵触感最有效的做法，因为它不打断任何人，也不需要任何人等。

第二道，放在 CI 里，但要分等级。 这是大多数 SDL 落地失败的关键点：不是扫描不好，是一上来所有问题都阻断发布。

可行的分法是三层：

| 等级 | 处置 | | — | — | | 暴露面的严重漏洞 / 密钥泄露 | 直接阻断，不过 CI | | 高风险 | 要求有修复计划 + 负责人 + 期限 | | 中低风险 | 进 backlog，不拦人 |

配套还要有一条：误报要能快速申诉。安全负责人半小时内响应，确认无误报就进全局白名单。 少了这条通道，开发者会先学会关通知，然后学会跳过扫描——那时你有再好的门禁也没用了。

最后补一句容易忽略的：优先覆盖核心资产就好。 不可能每个仓库都做全，先分清哪些系统值得上强制门禁，其余走自动化加事后兜底。贪全会让整套流程死在第一个季度。

07它可以写第一稿，但不能替你签字

写到最后，我其实一点都不反对用 AI 写代码。

我自己每天都在用。它把那些重复、琐碎、容易手滑的活干得又快又好，让我能把精力留给真正要想清楚的地方。这没什么可纠结的。

我想说的是另一件事：以前我们写一段粗糙的草稿，心里是清楚的——这是草稿。现在 AI 递过来一份「像成品」的东西，我们心里的那个刻度悄悄挪了位。

技术一直在变，工具一直在变，但有些东西一直没变：最终为这段代码负责的，是那个按下合并按钮的人。

AI 最大的风险不是写出漏洞， 是它把代码打磨得太体面， 体面到我们忘了多看一眼。

所以这篇不劝你少用 AI，只劝你一件事：把 AI 的输出当成第一稿，而不是待合并的 diff。

签字之前，那三十秒的手工复核，是你唯一不能外包给它的东西。

参考来源      · Pearce et al.《Asleep at the Keyboard?》，IEEE S&P 2022（arXiv:2108.09293，Copilot × CWE Top 25）      · Perry, Srivastava, Kumar, Boneh《Do Users Write More Insecure Code with AI Assistants?》，斯坦福大学      · Veracode《GenAI Code Security Report》，100+ 大模型安全编码评测      · Spracklen et al.，USENIX Security 2025（576,000 样本 / 16 模型包名幻觉）      · 《We Have a Package for You! A Comprehensive Analysis of Package Hallucinations》，发表于 IEEE-ISTAS 2025      · Pearce et al.，arXiv:2310.02059（真实 GitHub 仓库 Copilot 片段 CWE 分布）      · OWASP Top 10 2026（第八版）：A01 失效的访问控制、A02 安全配置错误、A03 软件供应链失效      · 多模型 AI 代码安全复测，2026 年 2 月（87 prompts × 6 模型 / 5 款 SAST 交叉验证）

· 安全开发 · AI 编码 · 代码评审 · DevSecOps ·

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：船山信安 奋斗的小浪 奋斗的小浪《让 AI 改了五遍，漏洞多了 37.6%：一份 AI 编码安全复查清单》