AI代码能编译，安全审查仍不能省

AI 写出的代码能编译、能跑通，并不代表可以放心上线。原文汇总了多项研究：模型完成功能的能力很强，安全表现却没有同步改善。作者的结论是，继续用 AI，但要把它的输出当作尚未建立信任的外包代码，经过审查、扫描和测试再交付。

对前端和全栈开发者，最有用的不是记住某个失败率，而是分清模型容易漏掉什么，以及哪些检查必须进入每次提交的流程。研究数字也有边界：安全专项测试的结果，不能直接当成你项目的漏洞比例。

几乎都能编译，为什么安全通过率只有 56%

原文引用的 Veracode 2025 年报告，用 80 道精选编程任务测试了超过 100 个大语言模型。当安全与不安全的实现都可行时，模型有 45% 的概率选择后者。Java 的安全失败率超过 70%，Python、C# 和 JavaScript 则在 38% 至 45% 之间。

到 2026 年，生成代码几乎 100% 能编译，平均安全通过率却只有 56%，接近 44% 的任务未通过安全检查，与上一年基本持平。夏季榜单中表现最好的模型也只达到 68%，仍接近每三道安全任务失败一道。

换模型能解决多少？这组测试没有给出特别乐观的答案。编程专用模型的通过率为 51%，通用模型为 52%；模型规模没有显示出明确优势，推理模型有一定领先，为 56% 对 51%。语言之间也有差异：Python 通过率为 63%，Java 只有 30%。

学术研究补上了两个风险。IEEE S&P 2022 的「Asleep at the Keyboard?」研究，在 89 个安全相关场景中生成了 1,689 个程序，约 40% 存在漏洞。ACM CCS 2023 的用户研究则发现，使用 AI 助手的参与者写出了显著更不安全的代码，却更容易相信代码是安全的。

危险的不只是漏掉漏洞，还有功能跑通后过早停止怀疑。

这些数字来自不同任务和研究设计，不能拼成一条连续趋势，也不能推出「AI 写的代码有四成存在漏洞」。它们共同支持的是：功能正确与安全可靠，需要分别验证。

模型最容易漏掉的，是项目里的权限和信任边界

作者认为，安全往往依赖模型没有拿到的上下文：哪些输入来自陌生用户，谁有权读取某条记录，环境里有哪些密钥，以及数据最终会显示在哪里。

例如，一个接口检查了登录状态，却没有检查当前用户是否拥有目标记录，功能测试仍可能通过。对正常账号而言，一切看起来都对；换一个账号访问同一条数据，问题才暴露。认证回答「你是谁」，授权回答「你能操作什么」。

前端也有类似问题。字符串能显示在页面上，不代表它适合直接作为 HTML 渲染。Veracode 2025 年测试中，跨站脚本攻击（XSS）防护失败率达到 86%，日志注入防护失败率达到 88%。作者把用户输入流向页面、数据库查询和日志的路径，列为重点检查对象。

另外几类问题同样常见：API key 被写进源码或前端产物，CORS 配置过于宽松，生产环境开启 debug，错误信息暴露内部细节，以及绕开框架工具自行实现加密或认证。

依赖则有一条更隐蔽的攻击路径。USENIX Security 2025 的论文分析了 16 个模型生成的 576,000 个代码样本，发现商业模型推荐的包至少有 5.2% 不存在，开源模型为 21.7%，累计出现 205,474 个不同的虚构包名。

攻击者可以抢先发布模型经常编造的包名，等待开发者安装。这不是普通的「包名写错了」，而是模型建议可能成为恶意依赖的入口。上述比例描述的是不存在的包，不能误读成恶意包比例。

安全清单要变成每次变更都会触发的流程

原文给出了 12 项检查，覆盖合并前审查、依赖与密钥、测试与生产配置。对开发团队，可以按执行位置组织。

首先是代码审查。理解业务的人逐行检查 AI 生成的变更，重点确认每个接口的授权规则、服务端输入校验、框架输出转义，以及数据库是否使用查询构建器或参数化查询。客户端做过校验，不能替代服务端检查；登录成功，也不能替代记录级权限判断。

其次是依赖和密钥。新增包要核对是否存在、是否维护、是否确实是打算安装的那个包；自动运行 npm audit、composer audit 或 GitHub Dependabot，并启用密钥扫描，避免凭据进入仓库和浏览器。

最后是持续集成（CI）与运行环境。每次变更运行登录、权限和支付流程测试，每个拉取请求（PR）运行静态应用安全测试（SAST）。作者提到他们使用 Playwright 端到端测试尽早发现访问规则被破坏，但没有提供效果对照数据。

生产环境还要关闭 debug、限制 CORS、使用通用错误页，并禁止 AI agent 直接接触生产数据和凭据。安全决策必须有明确负责人。

Google 的 2025 DORA 报告为这套流程提供了团队层面的提醒：AI 采用与更高交付吞吐量相关，但与交付稳定性仍呈负相关。作者据此强调，变更多了，自动化测试和快速反馈也得跟上。不过，这项关联不能单独证明 AI 导致了安全事故。

我的判断

我认同作者把重点放在交付流程上。对于权限、密钥和依赖来源，要求模型「写得安全一点」很难替代明确规则和可执行检查。让 AI 再审查一次可以增加发现问题的机会，但同样会遗漏问题的模型，不适合独自承担最终验收。

逐行人工审查也有前提：审查者必须懂业务，有时间追踪数据流，并且知道权限规则。原文没有给出这份清单实施前后的漏洞率或成本数据，因此它是一套合理实践建议，尚不能视为效果已被量化验证的方案。

另一处需要收紧的是输出处理。服务端校验与框架转义都有用，但不能据此认为所有输出位置都安全。原文自己强调上下文的重要性，审查时仍应追踪用户数据最终进入哪里。

相比单纯升级更大的模型，这套多层检查更贴近团队能控制的环节。不过，扫描通过也不等于业务授权正确。工具擅长发现的风险，与需要人理解的业务规则，应当同时覆盖。

能拿来做什么

• 给 AI 修改的 Node 接口补上权限测试，至少验证资源所属账号可以访问，另一个已登录账号不能访问，把授权要求写成可执行断言。
• 审查前端用户内容渲染和构建产物，确认没有直接渲染未经处理的 HTML，也没有把服务端密钥打进浏览器代码。
• 每次接受 AI 推荐的新依赖，都核对包名、维护状态和来源，再将依赖审计、SAST、密钥扫描接入 PR 检查。
• 为 AI agent 划定可访问环境，让它在受限数据和凭据下工作；涉及登录、支付或个人数据的 MVP，上线前逐项完成原文清单。