AI 生成代码安全扫描：面向 vibe-coded 应用的 DAST

为什么AI-生成的代码需要不同的安全扫描

AI 编码工具在开源存储库上进行了大规模培训。该训练数据偏向make it work 而不是make it secure。由此得出一些结构模式：

• Autocomplete bias. 最接近的匹配导入获胜。在一个文件中粘贴使用 service_role 键的 Supabase 片段会使该键成为下一个文件中的自动完成建议 - 即使在它从未属于的客户端 React 组件中也是如此。
• No long-term context. LLM 不记得你上次绕过RLS 或你的团队的事件事后分析。每个生成的文件都是新鲜的，通常缺少人类在文件中携带的防御模式。
• Speed as the rewarded metric. 用户好评速度； LLM 培训强化了这一点。在延迟反馈信号上，“生成最快的 Next.js 身份验证”优于“生成最安全的 Next.js 身份验证”。
• Training data gaps. 较旧的代码库主导着训练数据，并且早于现代安全默认设置（严格CSP、SameSite=Lax、HSTS、RLS）。生成的代码与 2019 年正常但如今不安全的模式相呼应。
• Implicit platform trust. 当Cursor 生成Vercel 应用程序时，它假定Vercel 的默认设置是安全的。有些是（auto-HTTPS，签名cookie）。许多不是（默认情况下没有CSP，宽松的CORS，默认Next.js调试路由）。

vivi 编码应用程序中存在过多的十个漏洞类别

在对AI-生成的应用程序进行数千次扫描时，相同的发现类别出现得不成比例：

1. Exposed Supabase service-role keys. 提交给客户端捆绑包的service_role JWT（开始eyJ）会绕过项目上的每个RLS 策略。 Cursor 在边界的错误一侧自动完成它；密钥在 /_next/static/... 中发货。
2. Missing Row-Level Security (RLS). 模型看到CREATE TABLE public.items 并继续，但不启用RLS。然后，匿名用户可以通过匿名公钥读取或写入任何行。参见baas.supabase-rls。
3. Open Firebase / Firestore rules. 生成的规则文件通常读取allow read, write: if true; 或完全跳过规则文件。默认测试模式规则将在 30 天后过期并锁定数据库，但前提是开发人员注意到。
4. 当 env-var 规则失效时，Hardcoded API keys in bundles. Stripe 实时密钥、Anthropic sk-ant-*、OpenAI sk-*、Google AIza* 和 AWS AKIA* 密钥最终会内联到 JS 有效负载中。 secrets.browser-storage 在渲染页面级别标记它们。
5. Missing Content Security Policy. 没有 Content-Security-Policy 响应标头意味着每个内联脚本 XSS 只需单击一下即可完全接管帐户。 CSP 是抽象的； codegen 通常会跳过它。 headers.security-headers 报告与特定于部署平台的修复指南之间的差距。
6. Next.js middleware misplacement. 使用src/ 布局，Next.js 仅拾取src/middleware.ts — 根级middleware.ts 会被默默忽略。身份验证似乎仍然有效，因为页面调用requireAuth()，但标头、CSP 和速率限制无法实现。
7. IDOR via unsigned IDs. 生成的GET /api/items/[id] 处理程序信任路径参数，并且从不验证所有权。遍历整数或UUID空间会暴露每个租户的数据。
8. Broken auth flows. 没有 expires_at 的 Magic-link 令牌； JWT 跳过aud 和exp 的验证；客户端 getSession() 调用（读取未经验证的 cookie）而不是服务器端 getUser()。
9. Debug endpoints in production. 生成/api/debug、/api/health、/api/__nextjs_original-stack-frame 或/.next/trace 路由泄漏内部。 discovery.platform-vercel 通过内容验证来探测它们，以避免 SPA 后备出现误报。
10. Plaintext sensitive fields. 密码、API 密钥和 PII 以纯文本形式存储在 Postgres 中，因为迁移未到达 pgcrypto 或外部保管库。

DAST 与SAST：为什么两者对于AI-生成的代码都很重要

静态分析 (SAST) 和动态分析 (DAST) 是互补的，而不是替代的。分割对于AI-生成的代码比手写的代码更重要。

SAST 读取磁盘上的源代码。它在构建运行之前捕获源文件中的秘密、危险的函数调用和危险的模式。它无法查看运行时配置、部署的环境变量或捆绑程序如何转换代码。

DAST 像用户一样点击已部署的应用程序。它可以查看已发送的响应，针对生产包运行，并捕获存储库和部署之间的配置偏差。它在转译的 JavaScript 中找到 SAST 从未见过的硬编码键，因为它们是在构建时通过 process.env 赋值输入的。

For AI-generated code, DAST is essential 因为运送的内容与模型所写的不同。捆绑、摇树、转译和环境变量内联都会创建新的表面。源代码上的 SAST 可能会完全错过捆绑包嵌入的秘密。 DAST 捕获两个层。成熟的管道针对已部署的预览在CI和DAST中运行SAST - 这就是FixVibe模式。

在 AI- 代码扫描仪中寻找什么

大多数通用DAST扫描仪（Burp Suite、OWASP ZAP、Nessus）都是为整体应用程序和传统身份验证流程而设计的。扫描 Vercel + Supabase + Stripe AI- 生成的应用程序需要：

• BaaS coverage. 针对Supabase RLS、Firebase / Firestore 规则、Clerk 配置、AWS Amplify 以及这些服务发出的JWT 形状进行真实检查。通用OWASP规则不知道要标记什么。
• JS bundle inspection. 针对API-密钥格式、签名令牌和特定于提供者的模式（Stripe sk_live_、Anthropic sk-ant-、Supabase JWTs 开头eyJ）调整了正则表达式。通用熵启发法会引发太多误报。
• Passive + active split. 被动检查（标头、cookie、秘密、BaaS 配置、DNS）针对任何 URL 安全运行。主动探测器（SQLi、XSS、SSTI、IDOR 步行）需要授权边界，因为它们会发射攻击式有效负载。
• Framework awareness. 识别Next.js 应用程序路由器与页面路由器、Vite SPA 重写、Vercel 部署保护、Cloudflare 页面路由。无法区分 Vite SPA 后备和真实 /_next/build-manifest.json 的扫描仪会产生噪音。
• Rate-limit safety. 每次扫描的有限请求预算、基线响应比较以避免 WAF- 混淆的误报、随机路径探测基线以检测毯子 403 部署。
• Authorization gating for intrusive payloads. 在大多数司法管辖区中，将 SQLi 或 OS- 命令有效负载发送到您不拥有的域是非法的。真正的扫描程序需要 DNS 或 HTTP- 文件所有权验证，然后才能对目标运行主动模式。

FixVibe的方法：基于证据的扫描，低误报负载

FixVibe is a DAST built specifically for AI-generated web apps. The passive phase runs 200+ checks on the rendered page (headers, CSP, cookies, leaked secrets, BaaS misconfiguration, tech fingerprinting, DNS, attack-surface discovery). The active phase adds payload-firing probes (SQLi, XSS, SSTI, CORS, redirects, IDOR walking, CSRF, account enumeration, blind-SSRF) gated behind verified-domain ownership. Repo scans add code-phase checks against connected GitHub repositories. Every finding includes evidence, a CWE link, a remediation recipe, and either a coding-agent prompt or operator steps depending on who can actually apply the fix. The scan engine is open in the changelog — every new check, accuracy improvement, and false-positive fix is logged publicly.

FixVibe 与 Burp Suite、ZAP 和 Nessus：当每个工具获胜时

没有一个工具可以涵盖所有工作流程。 FixVibe 适合的诚实框架：

这些工具相互补充

• Start with FixVibe passive 作为任何部署预览的免费 30 秒基准。如果什么都没有出现，你就会得到一个快速的信心信号。
• 当您想要针对您自己的基础设施进行完全主动覆盖 (SQLi/SSTI/IDOR/etc.) 时，在经过验证的域上Move to FixVibe active。
• Layer SAST（Semgrep、CodeQL、Snyk）位于 CI 中的源代码。 SAST 捕获运行时看不到的内容 - 代码路径中永远不会到达部署的危险模式。
• Reach for Burp Suite 当您需要自定义攻击链时（特定的身份验证绕过、复杂的IDOR 场景、业务逻辑缺陷）。 Burp 是可用的最深的手动工作台； FixVibe 是最快的自动化基线。

后续步骤

Continue 和 Vibe coding security checklist 进行 44 项发货前审核，或跳转到 How to secure an app built with AI coding tools 使用代码片段进行逐步强化。