在让AI动笔之前先做决定。用Forrester提出的"Secure Vibe Coding"三大实施原则，为三部曲对答案

来为三部曲对答案吧

Vibe Coding的170个后门。Lovable生成的应用中10.3%被发现安全缺陷，挫折过的前工程师认真调查了一番中，我写了从1645个Lovable（Lovable）生成的应用中发现170个安全缺陷的事。AI生成的”代码”有漏洞的事件。

Cursor CEO承认”我们自家工具会构建脆弱的基础”的那一天。零点击漏洞CurXecute向我们抛出的，Vibe Coding的下一个问题中，我写了Cursor（Cursor）本体被发现存在零点击远程代码执行漏洞”CurXecute（CurXecute）“的事。AI编码”工具本身”成为攻击路径的事件。

代码危险。工具也危险。那么Vibe Coding应该放弃吗？

答案是No。不是放弃，而是改变方法。这次我就来写写具体的方法。

Forrester（Forrester）的分析师Janet Worthington（Janet Worthington）女士在官方博客上提出了一个概念。“Secure Vibe Coding”。安全的Vibe Coding不是Paradox（矛盾），而是Paradigm（新常识）。

这句话就是三部曲的结论。比起找凶手，不如改变设计。不是事后做安全审查，而是把安全嵌入到生成过程本身。

数字揭示的”能跑但不安全”的现实

首先准确把握现状。不靠感觉，靠数据。

Veracode（Veracode）的2025年报告给出了令人震惊的数字。评估了100多个LLM（大语言模型）的结果是，生成出安全代码的只有55%。剩下的45%包含已知的安全缺陷。

将近一半都是漏洞。而且2026年春季的更新显示趋势也没变。即便是GPT-5和Claude 4.6一代，也没能突破”安全天花板”。模型变聪明就会变安全的期待，被狠狠辜负了。

还有一个。斯坦福大学的SVIBES基准的结果更加犀利。SWE-Agent与Claude 4 Sonnet的组合下，功能测试答对的是61%。其中安全的只有10.5%。

哪怕通过了功能测试的代码，6条里也只有1条是安全的。我一直奉为信条的”能跑就OK”，在安全方面完全错了。我诚实承认。

然后Forrester的2025年预测中预测，到2026年75%的技术决策者将感受到中至高严重程度的技术债务。AI大量生成代码的结果是，安全债务正在堆积。在75%的人感到”不妙”的状态下，事后审查根本追不上。

Forrester提倡的”Secure Vibe Coding”是什么

Worthington女士在自己用Cursor尝试Vibe Coding之后，在博客文章中这样写道。

生成出来的代码缺少输入清理（用户输入的安全处理）。也没有速率限制（连续访问的控制）。API密钥以明文嵌入。

这我也在Claude Code里有过经验。能跑的东西很快就能做出来。但是安全设置都漏掉了。和第一弹的Lovable事件是同样的结构。

Worthington女士的结论是这样。即便在AI辅助开发的时代，DevSecOps（开发、安全、运维的一体化）的基本也不可豁免。不过开发者的角色会改变。从”程序员”变为”Agent Orchestrator（AI代理的指挥者）”。

从写代码的人，变为设计让AI写什么的人。这个转变就是”Secure Vibe Coding”的核心。

Forrester的2026年预测报告中预测，Vibe Coding会进化为”Vibe Engineering”。超越编码的框架，进入与AI协作设计、测试、运维等整个工程的时代。如果根基没有安全就不成立。

三层框架: Spec / Agent / Gate

那么具体怎么实施呢？整理眷属的研究和各机构的提议后，我看清楚了分成三个层来思考会更清晰。

Spec Layer（规格层）: 在让AI动笔之前先定下约束

最上面一层。这里最重要。

Constitutional Spec-Driven Development这个方法于2026年1月被提出。把基于CWE（通用漏洞类型）和MITRE框架的”安全宪法”嵌入到规格中。AI生成的代码必须遵循这部宪法。

结果在案例研究中报告了安全缺陷削减73%。

第二弹介绍的Checkmarx（Checkmarx）的框架中，也是把在生成时把安全要求包含进提示词作为第一层。这与第一弹介绍的VibeContract（VibeContract）的思路也是一致的。

在实际操作层面，是这样的。在向Claude Code指示”做一个Slack Bot”之前，先把”认证用OAuth 2.0实现”、“API密钥从环境变量读取”、“所有输入值都做清理”作为规格写在前面。不是让AI自由地写完之后再检查，而是从一开始就设定约束。

Agent Layer（代理层）: 在写的过程中收紧权限

中间一层。这是对第二弹CurXecute事件抛出的课题的直接回答。

英国NCSC（国家网络安全中心）的AI系统开发指南中提出了四个原则。

• 最小权限: 只给AI代理必要最小限度的权限
• 安全默认: 新功能默认设为”关闭”
• 危险操作opt-in: 文件写入和外部通信改为明确许可制
• 行为限制: 事先定义AI能执行的动作范围

CurXecute的攻击条件是Auto-Run模式下无条件执行了来自MCP Server的指令。如果遵循NCSC的原则，Auto-Run默认是”关闭”。连接外部MCP Server是”opt-in”。也就是说，攻击成立的条件本身就消失了。

NCSC的另一份报告中警告说，把提示词注入（向AI注入恶意指令）用SQL（数据库）注入来类比理解是危险的。LLM内部不存在指令与数据的坚固边界。正因如此，在与外部连接的接口处收紧权限就变得重要。

Gate Layer（门控层）: 在出货前用门拦住

最下面一层。最后的堡垒。

GitHub在2026年3月连续发布的功能强化了这一层。

2026年3月17日: 通过MCP Server，commit前、PR前都可以做密钥扫描。只需向AI编码代理指示”扫描一下现在的diff”，就能事先检测出API密钥和令牌的泄露。

2026年3月23日: 增加了AI-powered detections（AI驱动的检测）。把检测对象扩展到Shell、Dockerfile、Terraform、PHP等。内部测试中报告称30天检测出超17万件finding，超过80%获得了正面反馈。

2026年3月31日: 进一步把Langchain、Salesforce、Figma等的令牌加入检测对象。代理时代的秘密信息管理进入了”每周更新”阶段。

此外，VibeGuard这项2026年4月1日公开的研究很有意思。它提出了针对传统静态分析难以覆盖的”工件卫生”的门控。源码映射的泄露、打包配置的漂移（非预期的变更）。是捡起Vibe Coding特有疏漏的机制。

今天就能开始的实践三步骤

第一弹介绍了3项检查，第二弹介绍了5项。这次作为三部曲的总结，我整理了基于三层框架的实践步骤。

步骤1: 在提示词中写入安全规格（Spec Layer）

在向AI委托代码生成之前，请把以下项目包含到提示词中。

# 安全规格模板（贴在提示词开头）
# 1. 认证: OAuth 2.0 / JWT / API Key（从环境变量读取）
# 2. 输入验证: 清理所有用户输入
# 3. 权限: 最小权限原则。DB访问仅限READ等
# 4. 日志: 记录认证事件、错误
# 5. 秘密信息: 禁止硬编码。用.env或秘密管理器管理

如果把模板保存为项目根目录下的.ai-security-spec.md，就能省去每次复制粘贴的麻烦。如果用Claude Code，写在CLAUDE.md里也是有效的。

步骤2: 确认代理的权限（Agent Layer）

虽然和第二弹的5项检查重叠，再说一遍。

• 是否把Auto-Run模式限定在只有可信的MCP Server
• .cursor/mcp.json里是否注册了来历不明的Server
• 进行外部通信的功能是否明确opt-in了

步骤3: 在CI/CD中添加门控（Gate Layer）

# 通过GitHub MCP的密钥扫描
# 向AI代理的指示示例
# "对这个PR的diff执行密钥扫描"

# VibeGuard型出货前检查（概念）
# 1. 源码映射是否未包含在构建产物中
# 2. .env文件是否未被提交
# 3. 包的版本是否如预期

用GitHub MCP Server的话，这些检查都可以通过AI代理自动执行。不需要记命令。只要拜托”扫描一下”就行。

总结: Vibe Coding不是”放弃”而是”改变方法”

通过三部曲，我最后整理一下想传达的内容。

• 第一弹（Lovable）: AI生成的代码有漏洞。1645个应用中170个有安全缺陷。攻击对象是”代码”
• 第二弹（CurXecute）: AI编码工具自身成为攻击路径。CVSS 8.6的零点击漏洞。攻击对象是”工具”
• 第三弹（本文）: Forrester提倡”Secure Vibe Coding”。用Spec / Agent / Gate三层把安全嵌入。答案是”改变设计”

45%的AI生成代码有安全缺陷。即便通过功能测试，安全的也只有10.5%。75%的技术决策者感受到债务。数字很严峻。

另一方面，答案也开始显现。Forrester定义了范式。NCSC发布了指南。GitHub几乎每周都在强化门控功能。也有研究表明仅在规格中加入约束就能让安全缺陷减少73%。工具已经在逐步齐备。

我曾经觉得自己敌不过专业工程师。在安全的深度设计上现在可能也还敌不过。不过，在提示词里写安全规格是可以的。确认代理的权限也可以。在CI/CD里加门控这事儿，GitHub也为我们准备好了步骤。

Vibe Coding的速度是武器。这个武器不需要放弃。但是要改变握法。Secure Vibe Coding不是”安全还是速度”的二选一，而是向”因为安全所以快”这一新常识的迁移。我希望和读完三部曲的各位一起，把这场迁移推进下去。