研究审计 200 个 vibe coding 应用，发现 1,186 个漏洞

真实世界中由 AI 智能体主导从零构建并公开部署的 vibe-coded 应用究竟存在多大程度的安全风险，其漏洞成因与潜在缓解条件为何。

• 开发范式转变与现实风险：vibe coding 让用户主要通过自然语言与 AI 智能体交互来从零设计、实现并部署完整应用，大幅降低开发门槛；作者称随着此类应用被直接部署到公网，安全决策缺乏人工审查，导致权限绕过与远程代码执行等安全事件频发。
• 现有研究的局限：以往对 AI 生成代码安全性的评估多聚焦于传统 AI 辅助编程，即在已有代码库中完成局部的函数补全或代码修补任务；作者指出这无法反映智能体在从零构建系统时自主做出的架构决策、信任边界划分与部署配置对整体安全的影响。
• 核心观察与假设：作者认为 vibe coding 中由 AI 智能体端到端主导的开发流程，可能在缺乏人类架构设计和安全审查的情况下，引入贯穿整个软件生命周期的系统性安全缺陷。
• 提出的工作：作者构建了包含 9,041 个开源 vibe-coded 应用的 VIBEAPPS 数据集，并结合多智能体审计与人工验证对 200 个公开部署应用进行安全审查，建立了包含 1,186 个漏洞的 VIBEVULNS 数据集，对其流行度、危险等级、失败模式及缓解配置展开系统分析。

相关研究主要涵盖 AI 辅助编程及其安全性评估、真实世界漏洞基准等方向。

AI 辅助编程与 Vibe Coding 范式

• Karpathy（2025）与 Chou 等人（2026）——提出并分析了 vibe coding 这一由 AI 主导、用户仅提供高层需求和反馈的新型开发模式。
• GitHub Copilot（Microsoft）与相关产业调研（Shani 等人，2023；Chandra，2024）——代表了传统 AI 辅助编程工具，在该模式下开发者依然主导系统设计、实现决策并承担代码审查职责。

AI 生成代码的安全性评估

• 早期函数级与单文件评估（Pearce 等人，2022；Nie 等人，2026）——在合成 CWE 任务上评估生成代码，Pearce 等人报告 GitHub Copilot 约 40% 的补全存在漏洞；Khoury 等人（2023）、Tihanyi 等人（2025）拓展至多模型和多语言对比。
• 仓库级与基准测试（Lian 等人，2025；Chen 等人，2026；Zhao 等人，2025；Vero 等人，2025）——构建了 A.S.E、SECUREVIBEBENCH、SUSVIBES 与 BaxBench 等仓库级基准，但作者指出其评估仍局限在受控实验或既有代码库的局部修改。
• 真实仓库分析与人类审查（Perry 等人，2023；Schreiber 与 Tippe，2025；Fu 等人，2025）——研究发现人类开发者可能在审查中纠正漏洞，并对开源代码库中 AI 辅助代码的安全性进行了实证分析。

基线方法与基准数据集

• OWASP Juice Shop 与受控基线——论文采用包含已知漏洞的 OWASP Juice Shop 验证审计框架召回率；在缓解实验中以 GPT-5.6-Terra 搭配默认 harness 和简短提示词作为 Baseline 基线配置。

与本文的区别定位

• 作者称现有工作局限于受控实验环境或人类既有代码库中的局部代码生成缺陷，无法反映自主智能体在架构规划、实现与部署全流程决策下暴露的系统级风险；作者称本文是首个针对公网实际部署的真实 vibe-coded 应用展开的大规模实证研究。

论文通过构建真实应用数据集、实施多智能体代码审计与人工验证、归纳失败模式，并开展受控重放实验来解决这一问题。

应用收集与筛选流程

1. 潜在应用发现：基于 AI 编码智能体留下的特征标记检索 GitHub Code Search API，选取代表命令行智能体的 Claude Code（配置目录 .claude/）与代表开发平台的 Lovable（元数据标记），初筛获得 74,800 个仓库。
2. 高质量应用过滤：过滤非工具类仓库，要求 README 不少于 100 字符，仓库大小在 10 至 500,000 KB 之间，代码行在 500 至 1M 之间，文件数不少于 5 个，提交数在 10 至 5,000 次之间，保留 38,078 个仓库。
3. AI 主导属性判定：要求首个提交为 AI 生成，并通过提交信息中的署名标识识别 AI 提交，要求 AI 提交比例与 AI 编写代码行比例均达到或超过 90%，最终获得 9,041 个应用构成 VIBEAPPS。

多智能体协同审计与验证

• 2×2 审计架构：针对 200 个公开部署的 Web 应用，采用两套智能体框架（Claude Code 搭配 Claude Sonnet 4.6、GitHub Copilot 搭配 GPT-5.3-Codex）分别结合两套安全技能库（OpenAI security-best-practices 技能与 Antigravity Awesome Skills），顶层调度主智能体根据技术栈自动调用框架专用子智能体（如 React、Node.js）。
• 去重与动态验证：将四份独立报告归一化并合并为 2,125 个候选；验证智能体追踪污点路径并向部署站点发送无害探测 PoC，保留 1,287 个候选。
• 人工双审判定：两位安全研究员独立复查源码与线上环境，仅在双方均确认可利用时判定为漏洞（Cohen's κ = 0.87），并依据 OWASP 风险评级标准评定等级，产出含 1,186 个漏洞的 VIBEVULNS。

缺陷归纳与受控重放设计

• 三类缺陷与八种失败模式：将漏洞归纳为记忆缺陷（不完全变更传播、遗忘义务）、目标缺陷（面向演示的设计、功能修复副作用）与知识缺陷（不安全指令、幻觉、未显式说明的安全规则、依赖用户的安全操作）三类，并映射至四个开发阶段。
• OFAT 重放实验：对 70 个分层抽样的漏洞目标，在回滚后的前置状态下重放任务，采用单因素轮换设计（OFAT）评估加固 harness、强弱基座模型（GPT-5.6-Luna、GPT-5.6-Sol）与四类提示词策略的影响，每组配置重复 3 次。

论文针对真实世界 vibe-coded 应用的生态格局、漏洞流行度与严重程度、成因分析及缓解条件展开了系统实验。

实验设置

• 被测模型：审计阶段使用 Claude Sonnet 4.6（Claude Code）与 GPT-5.3-Codex（GitHub Copilot）；重放实验使用 GPT-5.6-Terra（基线）、GPT-5.6-Luna 与 GPT-5.6-Sol。
• 数据集与规模：包含 9,041 个开源应用的 VIBEAPPS；从中抽样 200 个可公网访问的部署 Web 应用构建含 1,186 个漏洞的 VIBEVULNS；验证框架采用 OWASP Juice Shop；重放实验使用 70 个分层抽样漏洞。
• 评测指标：漏洞总数、受影响仓库比例（Repo）、每仓库漏洞数、每千行代码漏洞密度（VulnDensity/kLoC）、漏洞重引入率、相对基线变化（∆ vs. Base）、一致性系数（Cohen's κ）、召回率（Recall）。
• 评审与判定方式：审计阶段结合 4 份多智能体报告、自动化 PoC 探测与两位安全专家人工复核；重放实验通过人工检查生成的代码产物与执行轨迹判定漏洞是否重现。
• 样本量与重复次数：深度审计 200 个部署应用，消耗 28.5 亿 token 与 128.47 小时算力；重放实验包含 70 个目标 × 8 种配置 × 3 次重复，共计 1,680 次受控运行。
• 框架漏检评估：20 个仓库的双盲独立审计显示漏检率低于 15%（95% CI，Rule of Three）；Juice Shop 基准上框架召回率为 95.70%。

主结果

下表呈现了受控重放实验中 8 种 OFAT 配置下的漏洞重引入率（据 Table 4）：

Swipe horizontally to read the table

• 提示词与 harness 的缓解效果：作者指出 production 提示词（降低 14.8 个百分点）与加固 harness（降低 13.8 个百分点）效果最为明显，表明在任务层明确健壮性标准与在工作流层加入可复用安全检查均能减少漏洞。
• 专业提示词的负面影响：professional 提示词反使重引入率上升 20.0 个百分点；作者通过轨迹观察指出，详细的技术指令促使智能体死板执行用户需求，压缩了自身进行安全判断的空间。
• 模型能力扩展的收益递减：从 Luna 升级到 Terra 漏洞重引入率下降 13.8 个百分点，但升级到 Sol 反而微增 0.5 个百分点，作者认为单纯扩大模型能力规模不是提升安全的稳妥途径。

真实部署应用漏洞分布与组件分析

• 测试内容：统计 200 个部署应用在 OWASP 类别与代码组件层面的分布（据 Table 2）。
• 实验结果：91.00% 的应用含至少一个漏洞，65.77% 达 Critical 或 High 级别。Broken Access Control（339 处，占 28.58%，波及 64.00% 应用）、Injection（199 处，占 16.78%，波及 54.00% 应用）与 Authentication Failures（176 处，占 14.84%，波及 51.50% 应用）位居前三；后端代码集中了 52.70% 的漏洞，前端占 35.92%，配置占 11.38%。
• 作者解读：作者认为漏洞高度集中在信任边界处的鉴权与输入校验，且服务器端逻辑是主要薄弱环节。

根因缺陷与失败模式分析

• 测试内容：对 1,186 个漏洞在三类缺陷与八种失败模式下的归类统计（据 Figure 3）。
• 实验结果：知识缺陷占比最高（752 处，占 63.4%），其中未显式说明的安全规则达 658 处（55.5%）；目标缺陷占 274 处（23.1%），其中面向演示的设计占 174 处（14.7%）；记忆缺陷占 160 处（13.5%），其中不完全变更传播占 110 处（9.3%）。
• 作者解读：作者指出知识缺失与未声明规则是主要来源，而在迭代中为跑通功能绕过安全检查是目标缺陷的典型表现。

安全认知与执行差距分析

• 测试内容：人工检查重放实验中 434 次触发漏洞运行的智能体执行轨迹（据第 7 节）。
• 实验结果：在 90 次触发运行（20.7%）中，智能体在轨迹中明确识别并指出了安全风险，但仍生成并交付了不安全代码，代之以警告、代码注释或修正建议。
• 作者解读：作者指出智能体存在认知与行动差距，仅仅具备安全知识不足以保证安全，必须引入强制执行阻断机制。

其他消融与分析

• 仓库规模与漏洞密度：Small 应用漏洞密度为 0.85/kLoC，xLarge 应用降至 0.22/kLoC，但平均漏洞数从 2.13 升至 12.38（据 Table 1）。
• 开发跨度与提交强度：1 天内完成的项目中位数提交密度为 316.41 次/天，超过 90 天的项目降至 0.58 次/天（据第 4 节）。
• 应用类别分布：Web 应用占 96.17%（8,695 个），游戏占 1.08%（98 个），部署链接可达比例为 11.32%（据 Figure 1 与第 4 节）。
• 重复运行随机性：560 个漏洞-配置组合中，123 个（22.0%）在 3 次重复中结果不一致（据第 7 节）。
• 漏洞持久性：35 个漏洞在 8 种配置中的至少 3 种下被触发，且无任何配置能消除全部目标漏洞（据第 7 节）。

本节梳理作者明确指出的局限、后续方向以及实验所覆盖的客观范围。

作者指出的局限与后续方向

• 智能体指纹识别的代表性偏差：论文依赖 Claude Code 与 Lovable 的特定标记筛选应用，作者在第 8 节指出该发现可能无法直接推广到整个 vibe-coding 生态（据第 8 节 Limitations）。
• 开源托管平台范围限制：数据集全部采集自 GitHub 开源项目，作者在第 8 节指出研究结论可能仅适用于开源公开应用环境（据第 8 节 Limitations）。
• 漏洞挖掘框架的误报与漏报风险：虽然进行了人工复审与 Juice Shop 基准验证，但作者在第 8 节指出多智能体检测框架仍可能存在假阳性与假阴性（据第 8 节 Limitations）。
• 审计模型重叠偏见：由于广泛使用，Claude Code 同时被用作审计由其自身生成应用的工具，作者在第 8 节指出这可能引入潜在偏见（据第 8 节 Limitations）。
• 模型对齐干预方向：针对模型能力扩展无法带来开箱即用安全性的现象，作者在第 8 节指出后续研究需要在对齐阶段设计专门干预手段，以在任务完成压力下维持安全约束（据第 8 节 Takeaways）。

实验覆盖范围

• 应用类型聚焦 Web 应用：实际漏洞审计与重放实验仅覆盖了 200 个公开部署的 Web 应用，未覆盖占比共约 3.8% 的游戏、移动端及 CLI 等类别（据第 4 节）。
• 重放实验排除了幻觉缺陷：受控重放测试抽样了 70 个目标，覆盖了 7 种失败模式，但排除了难以稳定复现的幻觉类型（据第 7 节）。
• 代码样本限定于公开开源仓库：VIBEAPPS 与 VIBEVULNS 均源自 GitHub 公开项目，论文未测试企业内部闭源应用（据第 3.1 节）。
• 审计工具限定于两套框架：代码审计仅采用了 Claude Code 与 GitHub Copilot，论文未评估其他商业代码审计工具（据第 3.2 节）。
• 加固技能覆盖范围单一：harness 防护测试仅引入了 security-hardening 单一技能，论文未评估其他运行时防护插件（据第 7 节）。

1. 研究定位与核心问题：论文针对用户主要通过自然语言指令委托 AI 智能体从零构建并部署软件的 vibe coding 范式，首次对其真实世界公网部署应用的安全态势、漏洞成因与缓解条件展开了系统实证研究。
2. 数据集与多智能体审计：作者从 GitHub 筛选出 AI 编写比例不低于 90% 的 9,041 个应用构建 VIBEAPPS，从中随机抽样 200 个公开部署 Web 应用，通过 2×2 多智能体协同审计与人工双审复核，建立了包含 1,186 个已验证漏洞的 VIBEVULNS 数据集。
3. 安全态势与分布特征：在审计的部署应用中，91.00% 存在至少一个漏洞，平均每个应用含 6.52 个漏洞；65.77% 的漏洞评级为 Critical 或 High，且 Broken Access Control（28.58%）、Injection（16.78%）与 Authentication Failures（14.84%）三类占据了 60.20%，后端代码占漏洞总数的 52.70%。
4. 系统性成因与八种失败模式：漏洞根因归结为知识缺陷（63.4%）、目标缺陷（23.1%）与记忆缺陷（13.5%）三类，其中未显式说明的安全规则占 55.5%，面向演示的设计占 14.7%，反映出智能体功能优先与上下文遗忘等固有局限。
5. 缓解条件与认知行动差距：在 70 个漏洞的受控重放中，production 提示词（重现率 11.0%）与加固 harness（重现率 11.9%）缓解效果最好，而 professional 提示词反使重现率增至 45.7%；基座模型从 Terra 升级至 Sol 未见改善（25.7% 变为 26.2%）；在 20.7% 的漏洞触发运行中，智能体明确识别出安全风险却仍交付不安全代码。
6. 作者结论与治理启示：作者认为单纯提升基座模型能力无法消除安全风险，必须将 vibe coding 视为全流程管线安全问题，在 harness 中嵌入策略即代码（policy-as-code）与强制阻断机制，用户也应避免过度干预技术细节并在部署前开展专门安全自检。