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 编码应用程序中存在过多的十个漏洞类别

The same finding classes show up disproportionately in AI-generated apps:

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。然后，匿名用户可以通过匿名公钥读取或写入任何行。参见Supabase Row-Level Security。
3. Open Firebase / Firestore rules. Generated rules files often read allow read, write: if true; or skip the rules file entirely. Test-mode rules let anyone read and overwrite data until someone replaces them.
4. 当 env-var 规则失效时，Hardcoded API keys in bundles. Stripe 实时密钥、Anthropic sk-ant-*、OpenAI sk-*、Google AIza* 和 AWS AKIA* 密钥最终会内联到 JS 有效负载中。 Secrets in JavaScript Bundles 在渲染页面级别标记它们。
5. Missing Content Security Policy. 没有 Content-Security-Policy 响应标头意味着每个内联脚本 XSS 只需单击一下即可完全接管帐户。 CSP 是抽象的； codegen 通常会跳过它。 HTTP 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. Generated /api/debug, /api/health, /api/__nextjs_original-stack-frame, or /.next/trace routes leak internals. FixVibe reports them only with evidence that they really are exposed (Vercel-Specific Exposure).
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. Recognising real API-key formats — Stripe sk_live_, Anthropic sk-ant-, Supabase service-role keys — and telling a secret key from a publishable one. Generic pattern matching throws too many false positives.
• Passive + active split. 被动检查（标头、cookie、秘密、BaaS 配置、DNS）针对任何 URL 安全运行。主动探测器（SQLi、XSS、SSTI、IDOR 步行）需要授权边界，因为它们会发射攻击式有效负载。
• Framework awareness. Recognising Next.js App Router vs Pages Router, Vite SPA rewrites, Vercel deployment-protection, Cloudflare Pages routing. A scanner that doesn't understand how these platforms answer unknown paths generates noise.
• Rate-limit safety. Bounded request budgets per scan, and findings that require positive evidence — a blanket 403 from a WAF is not proof a file exists.
• 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 230+ 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：当每个工具获胜时

No single tool covers every workflow. For a sourced side-by-side of FixVibe, Burp Suite, ZAP, Snyk, Semgrep and Aikido, with a decision matrix, see choosing a security scanner for AI-built apps.

这些工具相互补充

• Start with FixVibe passive as a free baseline against any deploy preview — it usually finishes in under a minute. If nothing surfaces, you have a fast confidence signal.
• 当您想要针对您自己的基础设施进行完全主动覆盖 (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 进行 51 项发货前审核，或跳转到 How to secure an app built with AI coding tools 使用代码片段进行逐步强化。