AI 写代码，你来守安全：一套能落地的五层防线

fei飛fei飞

5239人浏览 · 2026-06-18 10:29:39

fei飛fei飞 · 2026-06-18 10:29:39 发布

AI 生成的代码安全漏洞多 15%？别慌，这篇教你如何守住底线

上篇《Copilot、Cursor、CodeBuddy 到底选哪个？》里我提到一个扎心的数据：AI 生成的代码，安全漏洞比手写多 15-18%（Opsera 2026）。评论区一堆人问"那我还用不用了？"——用，当然用，但得带脑子用。今天这篇就专门聊聊，怎么让 AI 写的代码更安全。

先认清现实：AI 代码为什么漏洞更多？

这个问题其实不难理解。换个角度想：

1. AI 学的是"平均代码"，不是"安全代码"

大模型训练数据来自 GitHub、Stack Overflow 等公开代码库。问题是——这些代码库里本身就有大量有安全漏洞的代码。AI 分不清哪些是"好的但有漏洞的代码"和"刻意写的安全代码"，它只会学统计规律。结果就是：AI 学会了最常见的写法，而最常见的写法往往不安全。

举个最简单的例子——SQL 注入：

python

# AI 大概率会生成的写法（不安全）
query = f"SELECT * FROM users WHERE name = '{user_input}'"

# 安全的写法（AI 不一定优先生成）
query = "SELECT * FROM users WHERE name = ?"
cursor.execute(query, (user_input,))

第一种写法在 GitHub 上出现频率远高于第二种。AI 只是忠实地反映了这个现实。

2. AI 没有"安全意识"，只有"完成意识"

你让 AI"写一个用户登录接口"，它的目标是把功能跑通。至于密码有没有哈希、Session 有没有过期时间、接口有没有限流——这些不是你明确要求的，它就不会主动加。

这不是 AI 不聪明，而是它的默认行为模式就是"最小化满足需求"。

3. AI 不了解你的安全上下文

企业内部通常有自己的安全基线：哪些库能用、哪些加密算法是合规的、密钥怎么管理。AI 完全不了解这些。它会给你生成一段功能正确但用了一个"已被内部禁用"的库的代码。

方法论：五层防线，让 AI 代码更安全

我自己尝试了一套方法，半年下来效果不错。不是让你不用 AI，而是让你用得更有章法。

第一层：Prompt 里就把安全要求写清楚

这是最简单也最容易被忽略的一步。大多数安全问题，在 Prompt 阶段就能避免。

对比一下两种 Prompt：

❌ 差的 Prompt：

帮我写一个文件上传接口

✅ 好的 Prompt：

帮我写一个文件上传接口，要求：

限制文件类型为 jpg/png/pdf，大小不超过 10MB

文件名校验，防止路径穿越

上传后的文件重命名为 UUID，不保留原始文件名

不在响应中暴露服务器内部路径

使用参数化查询，不要拼接 SQL

你看，差的 Prompt 就是让 AI"自由发挥"，而 AI 自由发挥的结果往往不考虑安全。好的 Prompt 把安全要求前置，AI 生成的代码质量完全不同。

实操建议：做一个 Prompt 模板库，把常见场景的安全要求固化下来。

比如：

场景	必加的安全要求
SQL 操作	参数化查询、输入校验
文件上传	类型白名单、大小限制、路径穿越防护、重命名
用户输入	XSS 过滤、长度限制、格式校验
API 接口	认证鉴权、限流、敏感信息脱敏
密码处理	bcrypt/argon2 哈希、禁止明文存储
第三方库	使用团队白名单内的库

第二层：AI 辅助代码评审（AI Review AI）

这可能是最有效的组合技——用 AI 去审查 AI 生成的代码。

听起来像个套娃，但实际上非常管用。原因在于：

生成代码的 AI 目标：把功能做出来
审查代码的 AI 目标：找出潜在问题

两个目标天然互补。你可以在 CodeBuddy/Cursor 里直接把 AI 生成的代码贴回去，然后问：

请从安全角度审查这段代码，重点检查：SQL 注入、XSS、敏感信息泄露、不安全的加密算法、权限校验缺失

你会发现 AI 经常能找出自己刚才生成代码中的问题。这就是"生成-审查"循环的力量。

我在上一篇文章里提到过，CodeBuddy 的智能评审帮团队发现了一个跑了三个月都没人发现的支付回调 bug。这种"AI 比你更细心"的能力，用在安全检查上同样有效。

实操建议：把安全审查作为固定步骤嵌入开发流程。每段 AI 生成的代码提交前，必须经过一次 AI 安全审查。

第三层：自动化安全扫描融入 CI/CD

靠人肉检查不靠谱，必须上自动化工具。这一步跟上一篇文章里提到的 CodeBuddy CLI 模式可以很好结合。

推荐的工具链：

工具	作用	适用场景
Semgrep	静态分析，规则灵活	通用安全扫描，社区规则库丰富
CodeQL	深度语义分析	发现复杂的逻辑漏洞
Snyk	依赖库漏洞扫描	检查第三方库的已知漏洞
Trivy	容器/基础设施扫描	检查镜像和 IaC 安全问题
OSV-Scanner	开源漏洞数据库	轻量级依赖检查

关键是把这些工具嵌入 CI/CD 流水线，做到"不扫描不过关"。

yaml

# 示例：GitHub Actions 中的安全扫描配置
security-scan:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - name: Semgrep SAST
      run: semgrep ci --config=auto --error
    - name: Dependency Check
      run: snyk test --severity-threshold=high
    - name: Secret Detection
      run: gitleaks detect --verbose

AI 生成的代码在 CI 流水线里跑一遍这些扫描，大部分常见漏洞都能被拦下来。

第四层：安全编码规范 + AI 规则注入

与其每次都手写安全要求，不如把它们固化到规则里。

对于 CodeBuddy 用户：

CodeBuddy 支持自定义规则（Rules），你可以创建团队级别的安全规则文件，让 AI 在生成代码时自动遵守。比如：

markdown

复制

# 团队安全编码规则

## SQL 操作
- 必须使用参数化查询，禁止字符串拼接
- 动态表名/列名必须使用白名单校验

## 敏感信息
- 密码必须使用 bcrypt 或 argon2 哈希
- 禁止在日志中输出密码、Token、身份证号
- API 密钥和数据库连接串必须使用环境变量

## 输入校验
- 所有用户输入必须在服务端再次校验
- 文件上传使用 MIME 类型白名单，而非扩展名黑名单

对于 Cursor 用户：

可以在 .cursorrules 文件中定义类似的安全规则，Cursor 会在生成代码时自动参考。

这样做的效果是：安全要求从"每次手动提醒"变成了"默认内置行为"。

第五层：最小权限 + 安全隔离

最后一道防线是运行环境层面的。

AI 生成的代码在"不确定是否安全"的时候，应该运行在受限环境中：

Docker 容器：限制网络访问和文件系统权限
沙箱测试：先在隔离环境跑，确认安全再放开
最小权限原则：数据库账号只给必要权限，AI 生成的代码用的连接串不要给 DROP/ALTER 权限

落地实操：一个完整的工作流

把这些串起来，就是一套可落地的安全开发流程：

┌─────────────────────────────────────────────────────┐
│  1. 写好 Prompt（内嵌安全要求）                       │
│     ↓                                               │
│  2. AI 生成代码                                      │
│     ↓                                               │
│  3. AI 安全审查（用 AI 审 AI）                        │
│     ↓                                               │
│  4. 自动化扫描（Semgrep + CodeQL + Snyk）             │
│     ↓                                               │
│  5. 人工 Review（重点关注安全相关改动）                 │
│     ↓                                               │
│  6. 沙箱环境验证                                      │
│     ↓                                               │
│  7. 合入主干                                         │
└─────────────────────────────────────────────────────┘

每一步都不可或缺。尤其是第 5 步人工 Review——不管 AI 多强，最终拍板的必须是人。

回到数据：15-18% 的差距是可以被消灭的

Opsera 那个"AI 代码漏洞多 15-18%"的数据，测的是裸用 AI、不做任何安全措施的场景。

如果你做到了上面说的五层防线，这个差距可以被大幅缩小，甚至在某些指标上，AI 辅助 + 安全流程的代码会比纯手写更安全——因为自动化工具有不会疲劳、不会遗漏的优势。

上一篇文章的结尾我说过一句话，这里再强调一遍：

AI 编程工具很强大，但它不是你偷懒的理由。代码评审、安全扫描、人工验证，一步都不能少。

这篇文章就是这句话的具体展开。

几个常见误区

误区一："我用的是最新模型，应该没问题"

模型再新，训练数据里的安全漏洞也不会自动消失。GPT-5、Claude-4 不会让 SQL 注入从互联网上消失。安全是架构和流程问题，不是模型版本问题。

误区二："我是内部系统，不对外，不用管安全"

内部系统才是重灾区。因为没有外部攻击压力，内部系统的安全投入往往最少，一旦被突破就是灾难性的。

误区三："我们团队有代码 Review，够了"

人工 Review 会疲劳、会遗漏、会有人情压力（同事写的代码不好意思太挑剔）。自动化扫描 + AI 审查 + 人工 Review 三者结合，才是真正的"够了"。

总结

防线	做什么	核心价值
Prompt 安全要求	写清楚安全约束	从源头减少漏洞
AI 审查 AI	用 AI 检查 AI 生成的代码	低成本、高覆盖率
CI/CD 自动扫描	Semgrep / CodeQL / Snyk	不扫描不过关
安全规则注入	团队级 Rules / .cursorrules	一次配置，持续生效
最小权限隔离	沙箱运行 + 最小权限	兜底防线