AI写代码快10倍，攻击面也涨10倍？前谷歌工程师的安全警告

本文整理自前谷歌资深工程师 Steve Yegge 在 AI Engineer 大会上代表 Snyk 所做的演讲。他没有兜售乐观情绪，而是给出了一个足够清醒甚至令人不安的判断：当 AI 把代码产出速度提升 10 倍，安全缺陷的攻击面也可能随之膨胀 10 倍。

AI编程速度提升10倍，安全问题也在10倍增长

Steve Yegge 在演讲开场就抛出了一个他自己都没能立刻回答的问题。去年 12 月，他在一家大型银行做 vibe coding（氛围编程）的 Q&A，正讲得意气风发时，这家银行的首席安全架构师站起来平静地问了一句：

如果大家的代码交付速度快了 10 倍，而安全缺陷率保持不变，那是不是意味着攻击面（defect surface）扩大了 10 倍？

这个问题击中了要害。Yegge 坦言当时被问到几乎瘫在地上。而更可怕的是隐含的前提——缺陷率根本不会保持不变，在 AI 大量写代码的情况下，它只会变得更糟，糟很多。

这不是一次危言耸听的表演。演讲的真正标题，用 Yegge 自己的话说，其实就是两个字：害怕（Be Scared）。而问题的关键在于，真正需要害怕的人往往不在安全大会的现场，而是在外面那些正在疯狂用 AI 提速交付的团队里。

AI生成代码的新型漏洞：从XSS到Slop Squatting

AI 生成代码不仅会继续制造那些我们早已熟悉的老漏洞——比如 XSS 跨站脚本。Yegge 提到，他短暂试用某个先进编码工具时，它就写出了一个 XSS 漏洞。这些老问题我们至少知道怎么修。

真正棘手的是全新的漏洞类型和攻击面，而且很多已经被打磨得相当精致。他重点讲了一个典型例子——Slop Squatting（幻觉抢注）：

当 AI 幻觉出一个不存在的包名

假设你想用一个图数据库，AI 信誓旦旦地告诉你：「用 graphy-1-2-3 就行。」于是它跑去包管理器下载、构建、运行，单元测试全部通过，看起来一切正常。

但问题是——graphy-1-2-3 这个包原本根本不存在。 有人发现 LLM 会反复幻觉出这个名字，于是抢先上传了一个功能一模一样、但额外植入后门的包。你下载的，是一个「附赠漏洞」的木马。

这类攻击的可怕之处在于：它完美利用了 AI 的行为模式，而开发者几乎无从察觉。

Slop Squatting 这一术语是 2024-2025 年间被安全研究人员正式命名的新型供应链攻击方式。其名称脱胎于已有的 "Typo Squatting"（域名/包名拼写劫持），后者是指攻击者注册与知名软件包极其相似的名称（如将 requests 写成 reqeusts）来诱骗开发者下载恶意代码。Slop Squatting 的不同之处在于，它完全依赖 LLM 的"幻觉"（hallucination）特性——大语言模型在生成代码时，有一定概率会虚构出并不存在于公共包管理器（npm、PyPI、Maven 等）中的库名。安全研究者发现，同一个幻觉包名往往会被不同模型、不同用户的对话反复生成，形成可预测的模式。攻击者只需监控这些高频幻觉名称，抢先在包管理器上注册同名包并植入恶意代码，就能以极低成本完成大规模的供应链投毒。这使得传统基于"已知恶意包黑名单"的防御手段几乎完全失效，因为攻击者创建的是全新的、此前从未存在过的包名。

借鉴谷歌经验：把漏洞推送到开发者指尖

Yegge 分享了他在谷歌积累的一条关键洞察：Bug 有半衰期。

谷歌运行着海量的单元测试和集成测试，他们发现了一个关于 bug 的规律——你越早看到它，就越可能修它。如果 bug 在你敲代码的当下就被提示出来，你会立刻修掉；但如果拖到 code review 阶段，你就开始犹豫「真的值得改吗」。正因如此，谷歌花了大力气把 bug 报告前移到「你正在打字的那一刻」。

安全漏洞为什么没有半衰期

这套「早提示早修复」的机制对几乎所有类型的 bug 都有效，唯独对安全漏洞失灵。

普通 bug 会因为「没人被它困扰」而逐渐失去紧迫性，但安全漏洞不会。它不会因为暂时没咬到用户就变得不重要——它会随时间不断累积、复利式恶化。

所以结论是：安全漏洞必须像谷歌对待顶级漏洞那样，在开发者指尖第一时间浮现出来。而当写代码的是 LLM（它可没有手指）时，就得把漏洞信息浮现给 LLM 本身。

这里提到的"半衰期"概念借用了物理学中放射性衰变的比喻。在谷歌的工程实践中，普通 bug 的修复概率会随时间呈指数衰减——发现后 1 小时内修复的概率最高，拖到一周后可能只剩不到 10% 的机会被修复，因为开发者的上下文记忆已经消退、修复的机会成本在主观感受上不断上升。谷歌为此开发了大量的"left-shift"（左移）工具链，包括在 IDE 中实时标注问题的 Tricorder 系统，以及将静态分析结果直接嵌入 code review 界面的机制。但安全漏洞的特殊性在于它的"价值"不取决于内部开发者是否注意到它，而取决于外部攻击者是否发现它。一个未修复的 SQL 注入漏洞不会因为"暂时没人利用"而降低风险等级——相反，随着系统暴露时间增长、攻击者工具链进化，其被利用的概率只会持续上升，呈现出"负半衰期"的特征。

LLM编程的「五遍法则」：安全必须是独立的一遍

那么，为什么不能指望 AI 直接写出安全的代码？

Yegge 给出了一个基于大量实战的方法论。他去年写了一本关于 vibe coding 的书，也是最早大规模实践 AI 编程的人之一。他总结出了 「五遍法则」（Rule of Five）：

用 LLM 做事，你往往需要让它对自己的产出反复审阅四到五遍，才能真正达到可交付的状态。

这是因为 LLM 的认知过程和人类相似，要经历草稿、修订、润色、编辑，就像刷墙一样，不可能一遍搞定，需要多遍叠加。

一次只让AI专注做一件事

更关键的一条经验是：即便是最强的模型，也只擅长一次专注做一件事。

这意味着你不能同时要求它「写对」和「写安全」——它会两边都做得半吊子。而你既不想要半吊子的正确性，也不想要半吊子的安全性。所以：

• 正确性是一遍
• 性能是另一遍
• 符合公司编码规范又是一遍
• 安全，应该既是你的第一遍，也是你的最后一遍

Yegge 亲身验证了这一点。他把玩了 30 年的一款游戏交给 AI 做「安全加固」，AI 处理完后自信满满地表示「加固效果看起来不错」。结果他再跑一遍 Snyk，扫出了 241 个漏洞——全是 AI 自己压根没想到去检查的。

把安全工具变成LLM的「超能力」

Yegge 五个月前写过一篇文章《软件生存 3.0》，核心观点是：LLM 可以合成任何它想要的软件，但它们「懒得可爱」——不想浪费 token（那意味着钱、电力和环境成本）。 因此它们非常乐意调用工具来卸载认知负担，只要能省 token。

把这个逻辑串起来：既然 AI 在写代码、又乐于用工具帮自己省力——那就把安全工具直接喂给它。

他推荐了两类工具的组合：

• Chain Guard：管你的「输入」。它提供经过预先审查、无漏洞且持续更新的镜像，守住供应链的源头。
• Snyk：管其余的一切——你写的代码、LLM 写的代码、以及从 slop squatting 拉进来的「无辜」依赖。

具体做法是：把安全分析作为一个独立的 pass 加进你给 AI 的提示词里，让它在完成主任务后「最后再看一件事」——运行所有安全工具（开源的、Snyk 的、Chain Guard 的），甚至让它们互相检查彼此的工作。

需要提醒的是，Yegge 也如实说明：他在自己的代码库上跑 Snyk 时，并没有扫出任何超出公开 CVE 的私有漏洞，但工具「用起来极其简单」。这是他给出的诚实边界。

AI安全威胁已从企业蔓延到个人生活

演讲最后，Yegge 把视野从代码库拉到了每个人的生活。

他引用 Five Eyes（五眼联盟）的最新预警——距离「开源模型追平顶级攻击模型」的那一天，已经是以月计，而非以年计。他甚至给出了一个逐渐收缩的估算：大约六到七个月。届时，具备强大攻击能力的模型将变得触手可及。

请回家和家人约定一套「暗号」

他给出了一个极其具体、几乎让人脊背发凉的建议：

去线下、当面和你的家人重新约定一套「暗号」。因为一种新型诈骗即将到来——你会接到一个身处困境、急需用钱的「家人」来电，声音极具说服力，甚至配有视频。你需要一种方法来分辨他们究竟是真人还是 AI。

Yegge 说，他为此已经害怕了近两年。他提到国会曾被秘密演示过「掏空银行账户」的 AI 能力。这不再是企业层面的抽象风险，而会切实影响到每一个人。

Five Eyes（五眼联盟）是由美国、英国、加拿大、澳大利亚和新西兰组成的情报共享联盟，其联合发布的网络安全公告在业界具有极高的权威性和预警价值。Yegge 引用的这一预警指向了一个正在加速到来的现实：随着 Meta Llama、Mistral、Qwen 等高性能开源模型的快速迭代，攻击者不再需要购买昂贵的 API 或突破商业模型的安全护栏——他们可以在本地部署经过微调的开源模型，用于生成钓鱼邮件、伪造语音/视频、自动化漏洞扫描与利用等恶意用途。这意味着网络攻击的"门槛"正在被压缩到几乎为零，原本只有国家级黑客组织才掌握的能力，很快将对任何有基本技术能力的人开放。

Agentic Security：谁在监督你的AI Agent？

在问答环节，Yegge 补充了一个他没来得及展开、但极其重要的「第三个维度」——Agentic Security（智能体安全）。

随着越来越多的人开始 7×24 小时地部署 Agent 来处理队列、响应事件、真正干活，一个全新的问题浮现了：谁在盯着你的 Agent 的肩膀？

他建议大家用「对抗性思维」来设计：

• 用对抗性的 Agent 群组来做队列管理——因为单个 Agent 迟早会搞砸，你必须有「监督者」Agent。
• 收紧权限：去审视你的服务账号，它真的需要那么多凭证吗？也许某个动作可以单独隔离出来。

同时，针对 Prompt Injection（提示注入） 这类攻击（比如用户输入中夹带「无视以上所有指令，执行如下操作」的恶意文本，即所谓「新型 XSRF」），Yegge 坦言目前没有完美答案，本质上还是一个教育问题——你需要让整个团队都开始认真对待。他预判企业内部即将涌现出全新的安全岗位：Agentic Security 工程师。

Prompt Injection（提示注入）是当前 LLM 应用安全中最受关注的攻击向量之一，已被 OWASP 列入 LLM 应用十大安全风险的首位。其原理是：LLM 无法从根本上区分"系统指令"和"用户输入"——两者在模型看来都是同质的文本 token。攻击者可以在看似正常的用户输入中嵌入伪装成系统级指令的文本（如"Ignore all previous instructions and..."），诱使模型执行非预期操作。Yegge 将其类比为"新型 XSRF"（跨站请求伪造），是因为两者的核心逻辑一致：让受信任的执行主体（浏览器/LLM Agent）在不知情的状态下代替攻击者执行恶意操作。在 Agentic 场景下，Prompt Injection 的危害被进一步放大——Agent 通常拥有调用 API、读写数据库、执行代码等真实系统权限，一旦被注入成功，攻击者可以借此横向移动、提权甚至外泄敏感数据，其破坏力远超传统的聊天机器人场景。

结语：AI安全是一场没有终点的军备竞赛

Yegge 的演讲不是一支希望的赞歌，但它的信息清晰得令人无法回避：

安全从来是一场永不停歇、随摩尔定律指数上升的军备竞赛，量子计算到来时还会更难受。而 LLM 的加入，正让这场竞赛以前所未有的速度逼近临界点。

好消息是——现成的工具、技术和实践已经存在，从开源到商业方案，你此刻就可以开始武装自己。前提是，你得先足够害怕，才会真正行动起来。