AI 生成的代码本身并不比人手写的更不安全，但它会以更快的速度把”看起来合理”的写法铺满整个仓库，让人工审查来不及逐条看。结论：把安全检查固化成一条上线前的清单，而不是依赖审查者的临场记忆。
AI 生成代码的高频风险点
GitHub 官方博客在讨论 AI 代码安全性时的判断是：AI 生成代码并不天然更不安全，但”永远要跑漏洞扫描器”这条结论不变。落到工程实践，风险集中在几处：
- 输入校验缺失：生成的代码常假设入参可信，直接拼进 SQL 、命令或模板。
- 密钥硬编码：为了跑通示例，把 API Key 写进源码或配置文件并提交。
- 权限过度：CI 工作流里给足权限，图省事写成
write-all。 - 依赖污染：引入陌生包，未检查是否在漏洞库里。
- 提示词注入：把外部网页、 issue 内容直接拼进提示词并执行模型输出。
GitHub 对代理生成的 PR 给出的硬止损是：任何削弱 CI 的改动直接拒绝。工作流 YAML 建议默认
permissions: read-all，分析步骤与执行步骤分离，涉及生产的动作必须留人工审批门。上线前审查清单
- 扫文件清单：先看改动文件数和 diff 规模，超过五个不相关文件或一句话说不清目的，直接要求拆小。
- 先查 CI 与配置文件：任何触及
.github/workflows、测试配置、构建脚本的改动优先看，权限是否被放大、检查是否被跳过。 - 查密钥与输入：全局搜索 key 、 token 、 secret 、 password 字面量，确认密钥走环境变量；所有外部输入必须校验后再使用。
- 查新依赖：新增的第三方包逐个对照漏洞库，确认维护活跃度与许可证。
- 跑自动化扫描：开启代码扫描与密钥扫描，让工具先过一遍机械问题，人只做判断部分。
- 要证据：任何非平凡的逻辑改动，必须有测试；高风险改动必须有回滚方案。
把自动化放在人前面
自动审查擅长机械问题：风格不一致、明显逻辑错误、缺失错误处理、类型不匹配。把这些交给工具先跑一轮，人只负责判断：这条改动是否符合系统的隐含约束、是否触碰了没写进文档的边界。 GitHub 的建议也是这个顺序——让 Copilot 先审，人再介入，把自动审查当前置条件而不是替代品。
执行环境的隔离
代理会真的执行代码，所以它运行的容器权限就是你的安全边界。相关做法见 编码代理沙箱环境搭建；外部内容进入提示词的风险与拦截方式见 提示词注入防御。若你的代理通过工具调用外部服务，还建议读一遍 MCP 安全风险与防护。
模型输出是数据不是代码。一旦把输出直接 eval 或当作命令执行，就等于把提示词注入的入口敞开给了任何能影响输入的人。正确做法是：模型输出结构化数据，代码按 schema 解析后再决定动作，解析失败就报错而不是尝试执行。
AI 生成的代码需要额外做安全审查吗？
需要，但原因不是它更危险，而是它产量更大。同样的审查标准，用自动化工具固化成流水线，才能匹配生成速度。
扫描工具报了很多问题，怎么判断优先级？
优先处理三类：权限放大、外部输入未校验、密钥泄露。其余风格和低危问题批量交给自动修复，人不逐条看。
审查 AI 的 PR 大概要花多久？
GitHub 博客给过一个十分钟分配法：两分钟分类、三分钟看 CI 、五分钟追主路径、剩余时间查安全边界并要求证据。复杂 PR 再叠加红 flag 检查。
是不是应该禁止 AI 改配置类文件？
不必完全禁止，但应设为高风险：工作流文件、依赖清单、部署脚本的改动必须人工显式确认，并在评审模板中单独列出。
评论 (0)