斯坦福 CS146S 精读（四）：Secure Vibe Coding——AI 代码安全攻防全指南

本文是「斯坦福 Vibe Coding 课程精读」系列第 4 篇。系列导航见文末。

CS146S 的 Week 6 和 Week 7 是整门课最让人"脊背发凉"的两周。

Week 6 讲安全：当 AI 帮你写代码时，谁来保证代码不被攻击？更可怕的是——当 AI 本身就是攻击面呢？

Week 7 讲审查：AI 产出的代码，我们到底能信任到什么程度？

很多 AI 编程课只教你怎么写得快。CS146S 把交付的底线拉了出来：可测、可审、可防。这两周的内容，是从"Vibe Coder"升级为"Professional Vibe Coder"的必经之路。

真实案例：Prompt Injection 导致远程代码执行

让我们从一个真实的安全漏洞开始。

2025 年，安全研究员发现了 GitHub Copilot 的一个严重漏洞（CVE-2025-53773）：攻击者可以通过 Prompt Injection，让 Copilot 在你的电脑上执行任意命令。

攻击链条

1. 植入恶意指令：攻击者在源代码文件、网页或 GitHub Issue 中嵌入隐藏的指令。这些指令对人类不可见或不引人注意，但 AI 会读取并执行。

2. 操控配置文件：Copilot Agent Mode 在读取这些内容后，被操控去修改 VS Code 的配置文件 .vscode/settings.json。具体来说，添加一行：

   {
     "chat.tools.autoApprove": true
   }
   

3. 激活 YOLO 模式：这个配置项会禁用所有用户确认提示。从此以后，Copilot 执行任何操作——包括在终端运行命令——都不需要你点"确认"。

4. 执行任意命令：攻击者的后续指令通过同样的 Prompt Injection 传入，Copilot 在无人监督的情况下执行终端命令——下载恶意软件、窃取凭证、加入僵尸网络。

最让人不安的细节：配置文件的修改是即时写入磁盘的，不是以 diff 形式让你审查。 也就是说，当你看到修改时，为时已晚。

影响范围

• 跨平台：Windows、macOS、Linux 全部受影响
• 潜在后果：勒索软件、信息窃取、僵尸网络招募
• 攻击向量多样：可通过代码仓库、网页内容、Issue 评论等多种渠道植入

微软在 2025 年 8 月修补了这个漏洞，但它揭示了一个根本性的问题：AI 编程工具天然就是一个攻击面。它们读取外部输入（代码、文档、网页），并且有修改文件和执行命令的能力。这两个特征的组合，恰恰构成了 Prompt Injection 攻击的完美条件。

对所有 AI 编程工具的警示

这不只是 Copilot 的问题。任何具有以下特征的 AI 编程工具都面临类似风险：

• 能读取外部内容（代码库、网页、文档）
• 能修改文件
• 能执行 shell 命令
• 有"自动批准"模式

Claude Code 通过权限模型来缓解这个风险——高风险操作需要明确授权，而且操作会显示给用户确认。但这也意味着：作为用户，你不能无脑批准 AI 的每个操作。 每次点"确认"之前，你需要理解它要做什么。

OWASP Top 10 在 Agent 时代的新威胁

OWASP Top 10 是 Web 应用安全的经典框架。但在 AI Agent 时代，这些传统威胁有了新的表现形式。

注入攻击的进化

传统的 SQL 注入、XSS 等注入攻击依然存在，但现在有了一个新成员：Prompt Injection。

Prompt Injection 特别危险，因为它攻击的不是你的应用，而是帮你写应用的 AI。一旦 AI 被操控，它生成的所有代码都可能带有后门。

AI 生成代码的系统性安全盲区

Palo Alto Networks Unit42 的研究揭示了 AI Agent 在安全方面的几个系统性弱点：

1. 身份欺骗和冒充：攻击者可以伪装成合法服务，通过 MCP 等协议与你的 AI Agent 交互。
2. 过度信任外部数据：AI Agent 倾向于信任它读取的所有内容，包括可能被篡改的文档和配置。
3. 权限边界模糊：当 AI Agent 连接了多个 MCP Server 时，一个被攻破的 Server 可能影响整个系统。

AI 发现安全漏洞的能力与局限

让我们换个角度——AI 不仅可能引入安全漏洞，也可以用来发现安全漏洞。

Week 6 的阅读材料中，Semgrep 的研究 对此做了迄今为止最系统的评估。

实验设计

• 对象：11 个大型、活跃维护的开源 Python 项目（Django、Flask、FastAPI 框架）
• 代码量：共 800+ 万行代码
• 工具：Claude Code 和 OpenAI Codex
• 目标漏洞：身份认证绕过、IDOR、路径遍历、SQL 注入、SSRF、XSS

关键发现

Claude Code 报告了 329 个发现，其中 46 个是真实漏洞——真正例率 14%，误报率 86%。

OpenAI Codex 报告了 116 个发现，其中 21 个是真实漏洞——真正例率 18%，误报率 82%。

两者共计发现约 20 个高严重性漏洞。

更细分的数据揭示了各自的强项和弱点：

最可怕的发现：非确定性

同一段代码、同一个 AI、同一个 prompt，三次运行得到 3、6、11 个完全不同的发现。

这源于 AI 的"上下文衰退"——在分析大型代码库的过程中，AI 会逐渐丢失早期的上下文细节。第一次运行时注意到的漏洞，第二次运行时可能因为上下文压缩而被忽略。

这个发现的实践意义巨大：不要用 AI 做一次性的安全扫描就认为万事大吉。 多次运行、交叉验证、结合传统静态分析工具，才是可靠的安全策略。

结论

AI 安全扫描的现状可以类比为：一个有直觉但不太靠谱的初级安全研究员。它能发现一些人类容易忽视的问题，但误报率高、结果不稳定。正确的用法是把它作为安全工具链中的一环，而不是唯一手段（关于 Claude Code 内置的安全扫描能力，可参考 Claude Code Security 深度解析）。

Context Rot 与安全的隐秘关联

Week 6 还引用了 Chroma 团队关于 Context Rot 的研究。这项研究看似与安全无关，实际上揭示了一个关键的安全隐患。

Context Rot 指的是模型性能随输入长度增加而持续退化的现象。在安全领域，这意味着：

1. 安全规则在长对话中被"遗忘"：你在对话开头强调"不要使用 eval()"，但经过 50 轮对话后，AI 可能在某个角落用了 eval()——因为早期的安全约束在上下文压缩中被降权了。

2. 复杂代码库中的漏洞更难被发现：当 AI 需要分析大量代码时，它对每个文件的"注意力"会被稀释。一些隐藏在边角的安全问题更容易被忽略。

3. AI 的安全意识不是恒定的：同一个模型在短上下文中可能正确拒绝不安全的操作，但在长上下文中可能因为"注意力衰减"而放过。

对策：安全相关的约束应该放在上下文中最显著的位置（如 CLAUDE.md 的开头），并且定期在新会话中重申。不要指望 AI 在 100 轮对话后还能记住第 1 轮的安全要求。

AI Code Review：信任边界在哪里

Week 7 转向另一个关键问题：AI 生成的代码，应该怎么审查？

传统的 Code Review 有成熟的方法论，但 AI 代码有其独特的"味道"，需要不同的审查策略。

AI 代码的特征

通过百万次 AI Code Review 的经验（Graphite 分享），可以总结出 AI 生成代码的几个典型特征：

1. 表面正确，深层有坑：AI 擅长生成语法正确、看起来合理的代码，但在边界条件、错误处理、并发安全等方面可能有隐患。

2. 过度工程化：AI 倾向于添加不必要的抽象层、多余的错误处理、过度的类型注解。代码看起来"专业"，但实际上增加了复杂度。

3. 拷贝式学习的痕迹：AI 会从训练数据中"记住"某些模式，即使这些模式在当前场景不适用。比如在一个简单的工具脚本中使用企业级架构模式。

4. 安全处理不一致：AI 可能在某些地方做了完美的输入验证，但在另一些类似的地方完全忽略。这种不一致性比完全不做更危险——它给人一种"已经处理好了"的错觉。

5. “幻觉"API 和库：AI 可能调用不存在的函数或使用已废弃的 API。这些在编译时可能会被发现，但在动态语言中可能直到运行时才暴露。

AI Code Review 的七步方法

基于 CS146S 的材料和 GitHub 工程师的 Code Review 哲学，我总结了一套适用于 AI 生成代码的审查方法：

1. 意图验证

问：这段代码做的是不是我想要的？

AI 可能完美地实现了一个你没要求的功能，或者对你的需求做了不符合预期的"创造性解读”。先确认方向对，再看细节。

2. 安全扫描

查：有没有常见的安全问题？

重点检查：

• 用户输入是否做了验证和转义
• SQL 查询是否使用参数化
• 文件操作是否有路径遍历风险
• HTTP 请求是否容易被 SSRF
• 认证和授权逻辑是否完整
• 敏感信息是否泄露到日志或响应中

3. 边界条件

测：极端情况下会怎样？

AI 倾向于处理 happy path，对以下场景的处理经常不够：

• 空值、null、undefined
• 超大输入、超小输入
• 并发访问
• 网络超时、服务不可用
• 磁盘满、内存不足

4. 依赖审计

验：引入的依赖是否可靠？

AI 可能推荐一些不可靠的第三方包——star 很少、长期未维护、存在已知漏洞，甚至根本不存在（幻觉包名）。每个新依赖都应该手动验证。

5. 性能评估

估：在真实负载下性能如何？

AI 可能写出在小数据集上正常、但在生产数据量下会崩溃的代码。特别注意：

• N+1 查询
• 无限循环的可能性
• 内存泄漏（特别是在长期运行的服务中）
• 不合理的全表扫描

6. 一致性检查

比：与现有代码风格一致吗？

AI 生成的代码可能在命名、错误处理、日志格式等方面与项目的既有风格不一致。一个项目里混用多种风格会大幅降低可维护性。

7. 可维护性评估

想：三个月后的你能看懂吗？

AI 倾向于生成"一次性"代码——能跑就行，但不考虑后续维护。检查：

• 关键逻辑是否有注释
• 函数职责是否单一
• 代码结构是否易于修改
• 测试是否覆盖了核心逻辑

自动化辅助手段

纯手工 Review 效率太低。以下工具可以作为辅助：

Graphite 的 CPO Tomas Reimers 在 Week 7 的演讲中分享了百万次 AI Code Review 的经验——AI Review 工具不是替代人工审查，而是作为第一道过滤网，让人类审查者可以把精力集中在更高层次的问题上。

构建安全的 Vibe Coding 工作流

综合 Week 6-7 的内容，一个安全的 Vibe Coding 工作流应该包含以下防线：

第一道防线：安全的上下文

在 CLAUDE.md 或项目配置中明确安全规则：

## 安全规范
- 所有用户输入必须做验证和转义
- SQL 查询必须使用参数化查询，禁止字符串拼接
- 文件操作必须验证路径，防止目录遍历
- API 响应禁止包含敏感信息（密码、token、密钥）
- 新依赖需要检查安全性和维护状态
- 不要使用 eval()、exec() 或类似的动态代码执行

把安全规则写在上下文中，AI 在生成代码时就会自动遵守。这不能保证 100% 安全，但能消除大部分低级安全错误。

第二道防线：自动化检查

在 CI/CD 流程中集成自动化安全检查：

• Pre-commit hook：运行 lint 和基础安全检查
• CI Pipeline：运行完整的测试套件 + 静态分析 + 依赖扫描
• PR Review：自动运行 AI Code Review 工具

第三道防线：人工审查

对于涉及安全的代码变更，人工审查不可跳过。重点审查：

• 认证/授权逻辑的变更
• 数据库 schema 的变更
• 新的外部服务集成
• 配置文件的变更（特别是权限相关）

第四道防线：权限最小化

• 不要给 AI Agent “root 权限”。限制它能访问的文件和目录。
• 不要使用"自动批准所有操作"模式。
• 定期审查 AI Agent 的操作日志。
• 敏感凭证不要放在代码仓库或 AI 能访问的位置。

第五道防线：纵深防御

假设上面的防线都可能被突破。部署运行时安全措施：

• WAF（Web 应用防火墙）
• 运行时应用自我保护（RASP）
• 异常行为检测
• 定期安全审计和渗透测试

安全与速度的平衡

可能有人会说：这么多安全检查，不是拖慢了 Vibe Coding 的速度吗？

CS146S 的回答是：不安全的快，是假的快。

一个安全漏洞造成的损失——数据泄露、法律风险、声誉损害——远超你用 Vibe Coding 省下的那些时间。而且，大部分安全措施（上下文配置、CI 自动检查、AI Review）一旦建立就是零边际成本的——它们自动运行，不需要你每次都手动介入。

真正的 Professional Vibe Coding 不是放弃速度选择安全，而是建立一次性的安全基础设施，然后在安全的框架内快速前进。

这就是 CS146S 这两周最有价值的教训：快速原型只是起点，可测、可审、可防才是终点。

相关阅读

• Claude Code Security 深度解析 — Claude Code 内置的安全扫描能力详解
• Claude Code Hooks 实战指南 — 用 Hooks 自动化安全检查流程
• MCP 协议全面解析 — 理解 MCP 安全边界的前提
• MCP 安全指南 — MCP Server 的安全最佳实践
• 从零手搓一个 Claude Code — 亲手实现安全检查机制，理解更深

系列文章导航

本文是「斯坦福 Vibe Coding 课程精读」系列第 4 篇：

1. 斯坦福 CS146S 精读（一）：Vibe Coding 如何成为正式学科
2. 斯坦福 CS146S 精读（二）：上下文工程（Week 3）
3. 斯坦福 CS146S 精读（三）：Agent Manager（Week 4）
4. 本文：斯坦福 CS146S 精读（四）：Secure Vibe Coding（Week 6-7）
5. 斯坦福 CS146S 精读（五）：从原型到生产（Week 8-9）