AI 생성 코드 보안 스캔: vibe-coded 앱을 위한 DAST

AI- 생성된 코드에 다른 보안 검색이 필요한 이유

AI 코딩 도구는 대규모 오픈 소스 저장소에서 교육을 받습니다. 해당 학습 데이터는 make it secure보다 make it work 쪽으로 치우쳐 있습니다. 몇 가지 구조적 패턴은 다음과 같습니다.

• 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, 서명된 쿠키)입니다. 대부분은 그렇지 않습니다(기본적으로 CSP 없음, CORS 허용, 기본 Next.js 디버그 경로).

바이브 코딩된 앱에서 과도하게 나타나는 10가지 취약성 클래스

수천 개의 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. Hardcoded API keys in bundles. Stripe 라이브 키, Anthropic sk-ant-*, OpenAI sk-*, Google AIza* 및 AWS AKIA* 키는 env-var 규율이 만료되면 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이 없는 매직링크 토큰; aud 및 exp을 건너뛰는 JWT 확인; 서버측 getUser() 대신 클라이언트측 getSession() 호출(확인되지 ​​않은 쿠키를 읽음).
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는 마이그레이션이 pgcrypto 또는 외부 볼트에 도달하지 않았기 때문에 Postgres에 일반 텍스트로 저장되었습니다.

DAST vs SAST: AI- 생성 코드에 둘 다 중요한 이유

정적 분석(SAST)과 동적 분석(DAST)은 대체가 아닌 보완입니다. 분할은 손으로 작성한 코드보다 AI- 생성된 코드에 더 중요합니다.

SAST은 디스크의 소스 코드를 읽습니다. 빌드가 실행되기 전에 소스 파일, 위험한 함수 호출 및 위험한 패턴에서 비밀을 포착합니다. 런타임 구성, 배포된 환경 변수 또는 번들러가 코드를 변환한 방법을 볼 수 없습니다.

DAST은 사용자처럼 배포된 애플리케이션에 도달합니다. 배송된 응답을 보고, 프로덕션 번들에 대해 실행하고, 저장소와 배포 사이의 구성 드리프트를 포착합니다. SAST이 빌드 시 process.env 할당을 통해 입력했기 때문에 본 적이 없는 트랜스파일된 JavaScript에서 하드코딩된 키를 찾습니다.

For AI-generated code, DAST is essential 모델이 작성한 내용과 배송되는 내용이 다르기 때문입니다. 번들링, 트리 쉐이킹, 변환 및 환경 변수 인라인 처리는 모두 새로운 표면을 생성합니다. 소스의 SAST은 번들에 포함된 비밀을 완전히 놓칠 수 있습니다. DAST은 두 레이어를 모두 포착합니다. 성숙한 파이프라인은 CI에서 SAST을 실행하고 배포된 미리 보기에 대해 DAST을 실행합니다. 이것이 바로 FixVibe 패턴입니다.

AI-코드 스캐너에서 찾아야 할 사항

대부분의 범용 DAST 스캐너(Burp Suite, OWASP ZAP, Nessus)는 모놀리식 앱과 기존 인증 흐름을 위해 설계되었습니다. Vercel + Supabase + Stripe AI- 생성된 앱을 스캔하려면 다음이 필요합니다.

• BaaS coverage. Supabase RLS, Firebase / Firestore 규칙, 사무원 구성, AWS Amplify 및 해당 서비스가 내놓는 JWT 형태에 대한 실제 검사입니다. 일반 OWASP 규칙은 무엇을 플래그해야 할지 모릅니다.
• JS bundle inspection. API- 키 형식, 서명된 토큰 및 공급자별 패턴(Stripe sk_live_, Anthropic sk-ant-, Supabase JWTs eyJ으로 시작)에 대한 정규식을 조정했습니다. 일반적인 엔트로피 휴리스틱은 너무 많은 오탐지를 발생시킵니다.
• Passive + active split. 수동 검사(헤더, 쿠키, 비밀, 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이 적합한 위치에 대한 정직한 구성:

도구가 서로 보완하는 곳

• 배포 미리 보기에 대한 무료 30초 기준으로 Start with FixVibe passive을 제공합니다. 아무 것도 나타나지 않으면 빠른 신뢰 신호를 받습니다.
• 자체 인프라에 대해 전체 활성 범위(SQLi/SSTI/IDOR/etc.)를 원하는 경우 확인된 도메인의 Move to FixVibe active.
• CI의 소스 코드에 대한 Layer SAST(Semgrep, CodeQL, Snyk). SAST은 런타임이 볼 수 없는 것, 즉 배포에 도달하지 못하는 코드 경로의 위험한 패턴을 포착합니다.
• Reach for Burp Suite 사용자 지정 공격 체인이 필요한 경우(특정 인증 우회, 복잡한 IDOR 시나리오, 비즈니스 논리 결함) Burp는 ​​사용 가능한 가장 깊은 수동 작업대입니다. FixVibe은 가장 빠른 자동화 기준선입니다.

다음 단계

44개 항목의 출시 전 감사를 보려면 Vibe coding security checklist과 함께 Continue을 사용하고, 코드 조각을 사용한 단계별 강화를 위해서는 How to secure an app built with AI coding tools으로 이동하세요.