100多个模型测了一年，44%的AI代码有漏洞：问题出在哪

先说一个测试结果。

安全厂商Veracode在过去一年里做了四次测试，覆盖100多个模型版本。结论是：AI生成代码的平均安全通过率，几乎没有提升。44%的AI生成代码里，至少包含一个OWASP Top 10级别的漏洞。

同一份报告里还有另一组数字：这些代码的语法正确率，接近满分。

把两句话放在一起看，意思很清楚——AI写的代码越来越像"能跑的代码"，但"能跑"和"安全"之间的距离，一年下来基本没动。

你的CI在绿灯放行什么

先说一个场景，你可能经历过。

团队里有人用AI写了一个文件上传接口，本地跑通，测试通过，PR合并，CI一路绿灯。上线之后被安全扫描揪出来：没有校验文件类型，没有限制目录，上传路径可以被参数控制。

代码是"对的"。功能是好的。漏洞也是真的。

这不是个别现象。Veracode测的那100多个模型，有不少是市面上最主流的选择。它们能写出结构清晰、命名规范、注释齐全的Java代码，但安全缺陷不影响编译，也不影响单测通过。所以这一层问题，会被CI里每一道自动检查放过去。

为什么语法能满分，安全却不动

原因不复杂。

模型被训练和优化的目标是"写出像样的代码"。像样，指的是结构、命名、常见用法符合人类习惯。安全是另一个维度：它要求你在"能实现功能"之外，多想一层"如果输入是恶意的会怎样"。

后者是一种对抗性思维，不是语法能力。它需要的是判断，不是熟练度。

所以会出现一种很反直觉的现象：**模型越强，写出来的代码越顺，反而越容易被直接合并。**代码看起来太干净了，干净到没人愿意再逐行挑刺。

Java项目里，漏洞常常不在业务逻辑

Java团队还有个特殊情况：这类项目是重生态、重框架、重配置的。

OWASP Top 10在Java工程里的落点，很多并不在Service里那几行业务代码上：

• 依赖本身带的漏洞。一个三年没升过的第三方包，可能就是入口
• 反序列化。老代码里的对象序列化链路，是最典型的利用面
• SQL拼接。MyBatis的 ${} 写顺手了就是注入
• XML解析。没关外部实体，就是XXE
• 随机数。用 Random 生成令牌而不是 SecureRandom
• 日志。把用户输入原样打进日志，会带来日志注入

这些点的共同特征是：**它们大多不在"这周新写的代码"里，而在项目的老习惯里。**AI会顺着项目既有的写法往下写——项目里怎么拼SQL，它就怎么拼。

这种散在项目各处的漏洞，怎么处理才划算

前面那份清单里，最难处理的是它的形态：同一个问题模式，往往在项目里有十几处相似写法。SQL拼接散在几个Mapper里，日志拼接散在几个Service里，老接口里的 Random 用了不止一处。按文件逐处排查，看全的成本极高；只改被报出来的那一处，剩下的还在。

拿飞算JavaAI的Java安全修复器来说，它的做法和逐个文件报错不一样。它对着OWASP Top 10的分类维度做检测，输出的是按漏洞类别聚合的清单，而不是按文件罗列的问题点；对检测出来的问题，能直接给出修复。

这个输出形式，正好对上前面说的成本结构。修一处漏三处的根源，是人不知道同类写法还散落在哪些文件里；只要有一份按类别拉平的清单，同一类问题就能一次过完，起点也就从"凭经验猜哪里还有"变成了"按清单逐条对齐"。省下的不是打字时间，是"找全"这一步。

它管不到的地方也清楚：能被静态识别的模式它覆盖得到，业务语义层面的漏洞判不出来——比如"这个用户该不该看到这条订单"，属于业务规则，工具没有判断依据。依赖包里带的漏洞也不在它这一层，那是另一条路径的事。

最危险的一句话：我们有AI帮忙做代码审查

报告里还有一段值得注意的判断。参与测试的专家给出的共识是：企业应该保留现有的安全控制，而不是把AI代码审查当成替代品。

这句话背后的道理很朴素。AI能高效地找出已知模式的问题，但它无法替你决定"这个项目的安全底线在哪"。前者是模式匹配，后者是风险判断。

而且1Password做过一个补充测试：让六种主流模型针对已知漏洞生成修复补丁，要求既不改变应用行为、又真正修掉漏洞。平均成功率只有26%——超过一半的补丁没把漏洞修掉，或者顺手改坏了别的东西。

把安全门设在三个位置

如果团队已经在用AI写Java，有三件事比"以后注意点"更有用。

**第一道，生成之后立刻扫。**不要等发布前统一扫。AI一次生成几百行，越早发现，修的成本越低；等到整合进主分支再发现，改一处要连带回归一片。

**第二道，盯依赖。**AI写的业务代码你可以review，但它引用进来的依赖版本、以及项目里那些过期了很久的Jar包，靠人眼看不动。这一层要归到依赖巡检里定期过一遍，不能等到出事再查。

**第三道，改完之后按类别回扫。**修完报出来的那一处，不等于这一类清完了。前面说过，同一个模式往往散在十几处，改完之后要按漏洞类别再走一遍，确认这一类里没有剩下的。

写在最后

AI把写代码这件事变便宜了，但安全的成本没有被一起打下来。

它只是从"人会不会写错"，转移到了"人会不会在AI写完之后，认真检查一遍"。

一个值得拿来讨论的问题：你团队现在的流程里，AI生成的代码和手写代码，走的是同一道安全门吗？还是说，因为"AI写的看起来挺规范"，实际上少走了一道？