能跑，不代表安全：委托定制开发前，该问的四个 AI 代码安全问题
现在几乎每一个开发团队都在用 AI 写代码，报价变快、交付也变快。但有一件事没有跟着变好：AI 代码安全。今年夏天的实测显示，AI 写出来的代码几乎都能顺利运行，却有将近一半带着已知的安全漏洞，而且这个比例一年来几乎没动。对委托开发的企业主来说，这不是工程师才需要懂的技术细节，而是签约前就该问清楚的事，因为系统一旦出事，要面对客户的是你的品牌。
能跑不等于安全：两份报告的同一个结论
安全公司 Veracode 在 2026 年 7 月底发布年度《GenAI Code Security Report》。结果很直接：各家模型产出的代码，语法正确率已经接近 100%，但通过安全检测的平均比例只有 56%，去年是 55%。也就是说，大约 44% 的代码生成任务会带进一个已知漏洞。表现最好的模型也只有 68%，超过半数的模型落在 50% 到 53% 之间；大型模型平均 53%，中小型模型 51%，差距微乎其微。报告的结论是：语法问题基本上解决了，安全却没有走在同一条曲线上。
另一家安全公司 IOActive 在 2026 年春天做了规模更大的测试：27 个模型与 AI 编程工具、730 个贴近实务的需求、横跨 27 种编程语言。平均安全表现是 59%，有 31.6% 的代码样本可以被直接攻击利用，没有任何一个模型做到完全安全。
两份报告出自不同团队、用不同方法，数据却落在同一个区间：每十段 AI 写的代码，大约有四段需要有人把关。
AI 最常写错的地方，刚好是最要命的地方
不是所有类型的漏洞都一样严重。Veracode 的数据显示，AI 在防范 SQL 注入与选用加密算法上表现不错，通过率分别是 83% 与 87%；但面对跨站脚本攻击（XSS）只有 15%，日志注入更只有 12%。
IOActive 则指出几个几乎所有模型都会失手的区域：
- 登录验证与权限：谁能看到什么数据、谁能改什么设置。
- 流量限制：有没有挡住暴力尝试密码或大量涌入的请求。
- 部署与基础设施配置：这类代码的漏洞比例高达 70% 到 97%。
这些刚好是会员系统、订单后台、支付对接最核心的部分。一个表单字段没有过滤、一个管理界面没有验证身份，就足以让客户数据外泄。
「请写安全一点」没有用，有用的是流程
很多人以为只要在指令里加一句「请写安全的代码」就好。IOActive 的测试发现，这种简单的提醒经常无效，有时甚至适得其反；真正有效的是把安全规范写进系统层级的配置与工具里，最多能把安全表现提高 25 个百分点。
Veracode 给企业的建议也集中在流程，而不是期待模型变聪明：选模型时把安全表现列入评估、在写代码的当下就验证而不是等上线前才扫描、先修最容易被利用的高风险漏洞，以及把 AI 编程当成正式的软件来源来管理，定出用哪些模型、用在哪里、怎么检查、谁负责。
换句话说，AI 写代码的安全性，取决于开发团队的纪律，而不是他们用了哪个最新的模型。
委托定制开发前，该问的四个 AI 代码安全问题
你不需要看得懂代码，只需要问对问题，并且把答案写进合同或验收条件。
1. 你们用哪些 AI 工具写代码？安全规范是怎么设置的？
好的回答会提到固定的工具清单、写进工具配置的安全规则，以及哪些情况不使用 AI。只回答「我们用最新的模型」，等于没有回答。
2. 代码上线前，会经过哪些安全检查？
至少应该包含自动化的漏洞扫描，以及人工的代码审查。可以要求在验收文件中附上扫描结果摘要，而不只是一句「已测试」。
3. 登录、权限、支付与部署配置，是谁写、谁审的？
这些高风险区域应该有资深工程师逐行审查并签字确认。AI 可以起草，但必须有具名的人负责。
4. 上线后发现漏洞，谁修、多久修好、费用怎么算？
漏洞不一定在验收时就会被发现。保修期内的安全修补、通报时限与后续维护费用，都应该在签约前谈清楚。
如果你公司内部已经有员工用 AI 做出来的小工具，同样的问题也适用，可以参考我们此前写的〈员工用 AI 做出来的工具，什么时候该交给专业开发？〉。
结语：AI 负责写得快，人负责守得住
AI 让定制开发变得更快、更负担得起，这是好事。但速度省下来的时间，有一部分必须花在把关上。一套系统值不值得信任，看的不是它多快做出来，而是出事的时候有没有人说得清楚每一道防线在哪里。
TitApeX 在承接定制系统时，会把安全检查与责任归属写进流程与交付文件。如果你正在评估开发项目，欢迎看看我们的服务内容，或直接与我们聊聊。
评论