AI 生成代码的安全风险：数据、机理与治理 · 行业洞察

AI 已经在写你公司相当比例的代码——这不是预测，是现状。真正的问题是：这些代码的安全水位如何？实证研究给出的答案并不乐观。

数据怎么说

早在 2021 年，纽约大学团队的《Asleep at the Keyboard》就发现：在高风险场景下，GitHub Copilot 生成的程序约 40% 存在可利用漏洞。
2025 年 Veracode 对 100 余个模型、80 个编码任务的横向测试显示：约 45% 的任务中 AI 引入了 OWASP Top 10 级别的安全缺陷，且这一比例并未随模型迭代明显下降——模型写的代码能跑得更好，却没有更安全。
斯坦福的对照实验则揭示了更危险的一层：使用 AI 助手的开发者写出的代码更不安全，但他们对自己代码安全性的信心反而更高。

安全缺陷率没有质变，代码产量却在数量级增长。固定的漏洞率乘以暴涨的分母，等于漏洞绝对数量的洪水。

训练语料带病。模型从海量公开代码中学习，也把其中的老旧写法、弃用 API 和典型漏洞模式一并学了进去。

上下文缺失。模型看不到你的威胁模型：这段输入来自不可信用户吗？这个接口暴露在公网吗？缺少这些语境，它会默认“乐观场景”。

提示不含安全约束。开发者的指令几乎总是“实现这个功能”，而不是“安全地实现这个功能”。研究反复证明，不明确要求，模型就不会主动加固。

幻觉依赖（slopsquatting）。模型会以可观比例虚构不存在的包名，攻击者批量抢注这些名字即可守株待兔——AI 时代特有的仿冒包攻击，我们在供应链投毒的演化一文中有更多案例。

如果代码在秒级产生，安全就不能停留在“上线前扫一遍”。四个可落地的动作：

实时检测：在代码写下的同刻完成分析——无论作者是人还是 AI。这要求引擎理解业务语义与数据流，而不是逐条匹配规则，否则误报会在 AI 的产量下把团队淹没。安势 CleanCode Security Agent 将误报率控制在 15% 以下、增量扫描小于 60 秒，正是为这个节奏设计的。
修复闭环：检测、研判、修复收敛进同一个回合，让 AI 引入的问题由 AI 当场修掉，而不是进入积压队列。
依赖准入：对 AI 建议引入的每一个依赖做存在性与信誉校验，掐断幻觉包与仿冒包。
CI 卡点兜底：流水线上保留最终关卡，让绕过实时检测的代码在合入前被拦下。

没有度量的治理只是姿态。建议把三个指标纳入研发效能看板：

AI 代码占比与漏洞密度分开统计：知道 AI 写了多少，还要知道 AI 写的那部分每千行引入多少缺陷，两条曲线分开看才能定位问题。
检测时延：从代码写下到问题被发现的时间。目标是从“天”压缩到“秒”，这直接决定修复成本——上下文还在开发者脑子里时修复，与两周后从积压队列里捞出来修复，成本差一个数量级。
修复闭环率：检出的问题有多少在同一开发回合内被修掉。这是衡量“检测工具”与“安全能力”差距的唯一指标。

相应地，安全团队的角色也在变：从逐行审查代码的“守门人”，转为规则与上下文的供给者——把企业的威胁模型、安全编码规范、可用组件白名单编码进 AI 的工作上下文与流水线卡点，让每一次生成都在约束内进行。管一个水龙头的时代结束了，现在要管的是水厂。

AI 不会放慢速度等安全。团队能选择的，只是让安全跑进生产时刻，还是留在事后追赶。