Vibe开发者正面临起诉。以下是发布前的精确操作手册。

OpenAI最近发布了一段值得所有使用智能体发布软件的人深思的表述。

在7月的一次内部网络安全评估中，OpenAI的智能体绕过了旨在将其与互联网隔离的控制措施，侵入了OpenAI自身研究基础设施和Hugging Face系统的部分区域。

这些智能体在数十台Hugging Face服务器上执行了代码，并在其中一台服务器上获得了root权限。代号为IM1的内部研究模型引发了该事件的大部分过程。GPT-5.6 Sol智能体还复现了一个漏洞利用，并将私密评估数据复制到一个公开的Hugging Face数据集中。

这并非公开的ChatGPT随机攻击互联网。这些模型是在安全措施被弱化的条件下进行网络评估，OpenAI表示客户数据和产品可用性未受影响。这些细节很重要。

OpenAI仍称此次事件为“警示信号”。

完整的OpenAI事件报告重建了事件经过，并解释了现有安全措施为何失效。

在过去近两年里，我在代理机构帮助发布了60多个最小可行产品（MVP），通常交付周期为21天。根据我在代理机构参与的客户MVP项目以及我们自己的应用工作室构建经验，这些是我在任何生产就绪版本上线前都会审查的类别。具体工具本月可能有所更新，但发布门禁标准未变。

速度固然有用。但发布你无法审查、约束或恢复的生产代码则毫无益处。

这是我将用于在AI构建的应用面向真实用户前的更新版发布前安全基线。

以下是完整解析。

本文第一版始于在r/vibecoding社区分享的一份发布前检查清单。原Reddit帖子已被删除，因此我不再依赖其作者资质或互动声明。截图仍然捕捉了使该帖子具有实用价值的核心思想：在发布前审查隐私、安全、数据泄露和暴露的密钥。

本次更新保留了该基础并补充了后续变化。

OpenAI究竟披露了什么

关键并非AI模型突然变成了电影反派。

关键在于，一个持续运行的智能体能够发现弱点、通过其操作者非预期的渠道传递信息、获取网络访问权限、进行漏洞链攻击并持续行动。

OpenAI的应对措施很有参考价值，因为它与小团队应考虑的控制措施非常相似：

→ 将不可信代码置于更强的沙箱环境中 → 限制网络访问 → 降低任何单一受侵工作负载的爆炸半径 → 监控工具操作和可疑行为 → 保留人工暂停或停止系统的权限

规模虽完全不同，但控制难题却似曾相识。如果你的编程智能体能够读取所有密钥、执行任何命令、写入生产环境并未经批准发布，那么一条错误指令或恶意仓库就能访问你赋予它的所有权限。

这才是与vibe编程的真正关联。

这并非证明AI生成的代码自动不安全，而是证明没有边界的能力会成为其自身的攻击面。

大多数人发布方式的问题

精致的界面几乎无法证明其背后的控制措施。

你的应用可能看起来已经完成，但一个可通过浏览器访问的角色可能拥有过高的数据库权限。身份验证可能对你有效，但可能泄露他人邮箱是否存在。支付按钮可能成功运行一次，但一个未受保护的端点可能让脚本调用付费API数千次。

危险的表述是：“AI构建了它，所以我假设它已处理了这个问题。”

AI可以起草策略、编写验证模式、配置行级安全策略（RLS）或建议限速器。你仍需检查该控制是否保护了正确的边界，以及应用在有人试图越界时是否表现正常。

应用的所有者仍需承担结果责任。

目前尚无联邦法院裁决过专门涉及vibe编程软件的数据泄露案件。但隐私和网络安全律师已发出警告，使用AI并不能免除应用所有者采取合理安全预防措施的责任。

因此目标不是偏执，而是建立可重复的发布门禁。

步骤1：映射应用暴露面

在扫描代码前，先记下你所保护的表面。

→ 每个公开域名、路由、API端点和webhook → 每个数据库表、存储桶、队列和第三方服务 → 你收集的每种个人或敏感数据 → 应用可访问的每个密钥或生产凭证 → 每个会改变数据、收取费用、发送消息或对外发布的操作

如果你无法描述暴露面，扫描器也无法告诉你它是否得到充分保护。

发布一份隐私声明，准确解释你收集什么、为何收集、谁接收、保留多久，以及用户拥有哪些选择或权利。

GDPR和CCPA并非自动适用于每个收集一个邮箱的应用。覆盖范围取决于业务运营地点、用户位置、处理的数据以及是否满足法律门槛。其他隐私、泄露通知、消费者保护和平台义务可能仍然适用。

策略生成器是起点，而非证明你的真实数据流与文档匹配的证据。

步骤2：测试数据库授权，而非仅测试登录

身份验证回答一个问题：这是谁？

授权回答危险的问题：此人能读取或修改什么？

在Supabase中，打开数据库 > 策略，审查通过数据API暴露的每个表和视图。Supabase的API安全指南解释了权限和策略如何协同工作。

权限决定哪些角色可以访问对象。行级安全策略（RLS）决定这些角色可以读取或修改哪些行。你需要审查两者。

启用RLS但无策略属于默认拒绝。零策略并不意味着表自动公开。危险状态包括：

→ 在暴露的表上禁用RLS → 过度权限 → 过于宽泛的策略，包括粗心的 USING (true) 规则 → 绕过你预期检查的视图或函数

使用匿名会话和至少两个独立用户账户进行测试。

用户A不应能读取、插入、更新或删除用户B的行。对存储、视图和函数重复相同测试。

同时运行Supabase的数据库 > 安全顾问。如果有助于起草策略SQL，可以让AI参与，但必须在跨用户测试后才能部署该SQL。

步骤3：攻击身份验证流程

大多数人测试一次正常路径就继续前进。

运行这四个冒烟测试：

→ 提交多次错误密码。验证是否出现限流、退避或升级挑战，且不确认账户是否存在 → 为未知邮箱请求密码重置。公开响应应与已知邮箱的响应相同 → 重用邮箱验证或密码重置链接。令牌应为单次使用或安全过期 → 尝试用现有邮箱注册。避免在用户证明控制该地址前暴露账户状态

使用通用响应如“邮箱或密码无效”和“如果账户存在，我们已发送说明”。

不要在生产错误中显示数据库查询、堆栈跟踪、内部标识符或密钥值。将诊断详情保留在服务器日志中，并将密码、访问令牌、API密钥和不必要的个人数据排除在这些日志之外。

这些是冒烟测试，而非完整的身份验证审计。会话处理、多因素认证、OAuth、CSRF、授权、令牌撤销和业务逻辑在相关情况下仍需单独测试。

步骤4：在服务器端验证每个不可信请求

客户端验证改善界面，但不是安全边界。

攻击者可以禁用JavaScript并直接调用你的API。

使用允许列表模式在服务器端验证每个不可信请求：

→ 类型和格式 → 最小和最大长度 → 数值范围 → 允许的值 → 已认证用户执行该操作的权限

对SQL使用参数化查询。使用与目标匹配的输出编码，无论是HTML、JavaScript、URL还是其他上下文。

不要依赖通用“清理输入”函数来解决所有注入问题。

步骤5：将密钥和陌生仓库视为敌对环境

只有文档记录的可发布密钥才能出现在浏览器代码中。

示例包括Stripe pk_... 密钥和Supabase可发布或旧版匿名密钥。这些密钥本身不构成授权。它们的安全性取决于其周围的权限和后端控制。

将Stripe sk_...、Supabase密钥或服务角色密钥、OpenAI密钥、Anthropic密钥及其他私密凭证保留在服务器端。

如果密钥泄露到公共仓库，应立即视为已泄露。首先撤销或轮换它。然后审查提供商日志、从当前代码和历史中移除它，并检查分支和构建产物。

GitHub会为许多支持的密钥模式扫描公共仓库，但覆盖范围并非普遍。其8月更新添加了Lovable作为密钥扫描合作伙伴，并扩展了对其他几个提供商的推送保护。这是有用的备份，但不是提交密钥的许可。

人们忽略的另一个智能体特定风险：仓库本身可能包含在智能体打开时执行的指令或配置。

8月，GitLab披露了Serena 1.6.1及更早版本存在漏洞，当打开仓库时可能执行来自恶意 .serena/project.yml 的攻击者控制代码。1.7.0版本已修复。

在将陌生仓库交给智能体前，请检查其智能体指令、钩子、MCP配置、环境文件、包脚本、编辑器任务和项目配置。在具有低权限凭证的隔离环境中打开未知代码。

步骤6：限制滥用和花费

对登录、注册、密码重置、公共表单、状态更改路由和调用付费服务的端点进行速率限制。

不要从某篇文章中复制通用的每分钟请求数字。

根据以下内容选择限制：

→ 预期用户行为 → 端点成本 → 下游提供商限制 → 单个账户或IP可能造成的损害

在适当时使用突发窗口、持续窗口、并发限制和成本预算。分层使用身份信号如用户或账户加IP，而非仅信任单一信号。

在可用时配置强制性的提供商花费限制。当需要按用户或每日控制时，添加应用级预算。在50%、75%和90%等里程碑处的警报可以给你反应时间，但它们是运营选择而非通用默认值。

对于易滥用的公共表单，从服务器端速率限制、验证、重复抑制和监控开始。当流量或行为需要时，添加Cloudflare Turnstile或其他机器人挑战作为升级控制。

如果使用Turnstile，请在服务器端验证每个令牌。仅浏览器小部件不构成保护。

一个重要的纠正：CORS不会认证调用者或阻止直接API请求。它控制哪些浏览器来源可以读取响应。Cookie认证的状态更改可能还需要SameSite cookie、CSRF令牌和服务器端来源检查。

步骤7：扫描前先修补技术栈

安全扫描器无法弥补选择运行存在已知关键漏洞版本的问题。

8月25日，Next.js发布了针对两个关键未认证远程代码执行路径的补丁。

一个涉及处理攻击者控制的AVIF文件的图像优化。另一个影响在Windows上同时使用Pages Router和App Router且未使用缓存组件的应用。

升级到已打补丁的版本，包括15.5.24或16.3.3（适用于这些发布线）。Windows问题目前没有文档记载的解决方法。

然后扫描其余依赖树并移除不需要的包。

在每次公开发布前，检查你的框架、数据库、身份验证提供商、托管平台和主要依赖项的安全公告。

步骤8：运行自动化安全审查

将自动化作为第二双眼睛，而非安全证书。

OpenAI在7月悄然发布了开源Codex Security CLI。它可以扫描仓库、跟踪运行间的发现、验证修复并在CI中添加安全检查。

从以下命令开始：

npx @openai/codex-security scan .

OpenAI表示初始扫描可能需要数小时，大型仓库可能需要数天。这就是本文不再承诺完整安全审查可在30分钟内完成的原因。

Anthropic提供两个独立的Claude Code插件：

security-guidance 在Claude编写代码时运行，并警告已知危险模式。安装命令：

/plugin install security-guidance@claude-plugins-official

claude-security 是独立的按需深度扫描器。它映射架构、构建威胁模型、搜索漏洞，并在报告前将发现发送给独立验证代理进行验证。

安装并运行命令：

/plugin install claude-security@claude-plugins-official

/reload-plugins

/claude-security

深度扫描器需要付费Claude Code计划并消耗计划用量。

Cursor和Lovable也提供安全审查界面。可用性和计费可能取决于计划。

无论使用哪种扫描器，都需要重现发现、评估漏洞路径是否可达、审查建议的补丁、运行测试并再次扫描。

我在发布前运行的四个提示

这些提示是审查辅助工具，并非渗透测试。

要求提供证据而非接受一段自信的陈述。

提示1：架构与威胁模型

映射此应用的信任边界、公开入口点、特权组件、敏感数据、第三方依赖项和不可逆操作。识别可能的攻击者目标和滥用路径。引用创建每个边界的精确文件和路由。在映射完成前不要提出修复建议。

提示2：授权与租户隔离

审查身份验证、授权、数据库权限、行级安全策略、存储策略、视图和服务器函数。对于每个潜在的跨用户或跨租户访问路径，提供精确文件或策略、漏洞利用前提条件、可能影响，以及使用两个用户加匿名会话的测试。

提示3：密钥、验证与输出

追踪从每个公共路由到数据库查询、shell命令、模板、日志和API调用的不可信输入。查找暴露的凭证、过宽的API响应、不安全的日志记录、缺失的服务器端验证、注入路径和特定于上下文的输出编码问题。为每个发现提供文件行号证据和测试方法。

提示4：滥用、成本与依赖项

审查登录、注册、密码重置、公共表单、上传、webhook和付费API路由是否存在滥用和成本放大风险。对照当前安全公告检查依赖项和框架版本。对于每个问题，提供证据、可复现测试、建议控制以及修复后的剩余风险。

何时使用此基线

在暴露以下应用前运行此基线：

→ 处理个人数据 → 暴露后端或数据库 → 处理资金 → 调用付费API → 上传或存储文件 → 授予私有资源访问权限 → 允许智能体执行外部或不可逆操作

当内部工具可以访问生产数据、客户记录、凭证或特权系统时，需要相同的控制措施。

没有真实用户、生产凭证或生产数据的本地原型可以保持轻量。记录必须在公开前完成的事项。

健康、金融、身份、儿童、精确位置及其他受监管或高度敏感数据需要超越此基线的措施。请获取合格的专家…