Pemindaian keamanan kode buatan AI: DAST untuk aplikasi vibe-coded

Mengapa AI- kode yang dihasilkan memerlukan pemindaian keamanan yang berbeda

AI alat pengkodean dilatih pada repositori sumber terbuka dalam skala besar. Data pelatihan tersebut condong ke make it work daripada make it secure. Beberapa pola struktural mengikuti dari itu:

• Autocomplete bias. Impor pencocokan terdekat menang. Menempelkan cuplikan Supabase yang menggunakan kunci service_role di satu file akan menjadikan kunci tersebut sebagai saran pelengkapan otomatis di file berikutnya — bahkan di komponen React sisi klien yang tidak pernah menjadi bagiannya.
• No long-term context. LLM tidak memiliki ingatan tentang bypass RLS terakhir Anda atau insiden postmortem tim Anda. Setiap file yang dihasilkan masih segar, sering kali tidak ada pola pertahanan yang dibawa manusia ke seluruh file.
• Speed as the rewarded metric. Pengguna memuji kecepatan; LLM pelatihan memperkuatnya. "Hasilkan Next.js auth" tercepat mengalahkan "hasilkan Next.js auth paling aman" pada sinyal umpan balik latensi.
• Training data gaps. Basis kode lama mendominasi data pelatihan dan mendahului default keamanan modern (ketat CSP, SameSite=Lax, HSTS, RLS). Kode yang dihasilkan mencerminkan pola yang normal pada tahun 2019 tetapi tidak aman saat ini.
• Implicit platform trust. Ketika Cursor membuat aplikasi Vercel maka diasumsikan default Vercel aman. Beberapa di antaranya (auto-HTTPS, cookie bertanda tangan). Banyak yang tidak (tidak ada CSP secara default, permisif CORS, rute debug default Next.js).

Sepuluh kelas kerentanan terwakili secara berlebihan dalam aplikasi berkode getaran

Dari ribuan pemindaian aplikasi yang dihasilkan AI-, kelas temuan yang sama muncul secara tidak proporsional:

1. Exposed Supabase service-role keys. service_role JWT (dimulai eyJ) yang berkomitmen pada paket klien mengabaikan setiap kebijakan RLS pada proyek. Cursor melengkapinya secara otomatis di sisi batas yang salah; kunci dikirimkan dalam /_next/static/....
2. Missing Row-Level Security (RLS). Model melihat CREATE TABLE public.items dan melanjutkan tanpa mengaktifkan RLS. Pengguna anonim kemudian dapat membaca atau menulis baris apa pun melalui kunci publik segera. Lihat baas.supabase-rls.
3. Open Firebase / Firestore rules. File aturan yang dihasilkan sering kali dibaca allow read, write: if true; atau melewatkan file aturan seluruhnya. Aturan mode pengujian default akan kedaluwarsa setelah 30 hari dan mengunci database, tetapi hanya jika pengembang menyadarinya.
4. Hardcoded API keys in bundles. Stripe kunci langsung, kunci Antropik sk-ant-*, OpenAI sk-*, Google AIza*, dan AWS AKIA* akhirnya dimasukkan ke dalam muatan JS ketika disiplin env-var hilang. secrets.browser-storage menandainya pada tingkat halaman yang dirender.
5. Missing Content Security Policy. Tidak ada Content-Security-Policy header respons berarti setiap skrip inline XSS hanya berjarak satu klik untuk pengambilalihan akun penuh. CSP bersifat abstrak; codegen secara rutin melewatkannya. headers.security-headers melaporkan kesenjangan dengan panduan perbaikan khusus platform penerapan.
6. Next.js middleware misplacement. Dengan tata letak src/, Next.js hanya mengambil src/middleware.ts — tingkat akar middleware.ts diabaikan secara diam-diam. Auth tampaknya masih berfungsi karena halaman memanggil requireAuth(), tetapi header, CSP, dan batas kecepatan tidak masuk.
7. IDOR via unsigned IDs. Penangan GET /api/items/[id] yang dihasilkan memercayai parameter jalur dan tidak pernah memverifikasi kepemilikan. Berjalan di bilangan bulat atau ruang UUID akan mengekspos setiap data penyewa.
8. Broken auth flows. Token tautan ajaib tanpa expires_at; JWT verifikasi yang melewati aud dan exp; panggilan sisi klien getSession() (yang membaca cookie yang belum diverifikasi) alih-alih sisi server getUser().
9. Debug endpoints in production. Menghasilkan /api/debug, /api/health, /api/__nextjs_original-stack-frame, atau /.next/trace rute kebocoran internal. discovery.platform-vercel memeriksanya dengan validasi konten untuk menghindari kesalahan positif pada SPA fallback.
10. Plaintext sensitive fields. Kata sandi, kunci API, dan PII disimpan sebagai teks biasa di Postgres karena migrasi tidak menjangkau pgcrypto atau brankas eksternal.

DAST vs SAST: mengapa keduanya penting untuk kode yang dihasilkan AI-

Analisis statis (SAST) dan analisis dinamis (DAST) merupakan pelengkap, bukan pengganti. Pembagian ini lebih penting untuk kode yang dihasilkan AI- dibandingkan kode tulisan tangan.

SAST membaca kode sumber pada disk. Ia menangkap rahasia dalam file sumber, panggilan fungsi berbahaya, dan pola berisiko sebelum build dijalankan. Itu tidak dapat melihat konfigurasi runtime, variabel lingkungan yang diterapkan, atau bagaimana bundler mengubah kode Anda.

DAST mengenai aplikasi yang diterapkan seperti pengguna. Ia melihat respons yang dikirimkan, dijalankan pada bundel produksi, dan menangkap penyimpangan konfigurasi antara repo dan penerapan. Ia menemukan kunci hardcode dalam JavaScript yang ditranspilasi yang SAST tidak pernah dilihat karena dimasukkan melalui tugas process.env pada waktu pembuatan.

For AI-generated code, DAST is essential karena kapalnya berbeda dengan yang ditulis modelnya. Bundling, pengguncangan pohon, transpilasi, dan inlining variabel lingkungan semuanya menciptakan permukaan baru. SAST pada sumber dapat melewatkan seluruh rahasia yang tertanam dalam bundel. DAST menangkap kedua lapisan. Pipeline yang matang berjalan SAST di CI dan DAST terhadap pratinjau yang diterapkan — itulah pola FixVibe.

Apa yang harus dicari dalam pemindai kode AI-

Sebagian besar pemindai DAST untuk tujuan umum (Burp Suite, OWASP ZAP, Nessus) dirancang untuk aplikasi monolitik dan alur autentikasi tradisional. Memindai aplikasi yang dihasilkan Vercel + Supabase + Stripe AI- memerlukan:

• BaaS coverage. Pemeriksaan nyata terhadap Supabase RLS, Firebase / aturan Firestore, konfigurasi Clerk, AWS Amplify, dan bentuk JWT yang dihasilkan layanan tersebut. Aturan umum OWASP tidak tahu apa yang harus ditandai.
• Inspeksi bundel JS. Regex yang disetel untuk format kunci API-, token bertanda tangan, dan pola khusus penyedia (Stripe sk_live_, Anthropic sk-ant-, Supabase JWT mulai eyJ). Heuristik entropi generik menghasilkan terlalu banyak kesalahan positif.
• Passive + active split. Pemeriksaan pasif (header, cookie, rahasia, konfigurasi BaaS, DNS) dijalankan dengan aman terhadap URL apa pun. Probe aktif (SQLi, XSS, SSTI, IDOR berjalan) memerlukan batas otorisasi karena mereka menembakkan muatan bergaya serangan.
• Framework awareness. Mengenali Next.js App Router vs Pages Router, Vite SPA penulisan ulang, Vercel perlindungan penerapan, Cloudflare Perutean halaman. Pemindai yang tidak membedakan fallback Vite SPA dari /_next/build-manifest.json yang asli menghasilkan kebisingan.
• Rate-limit safety. Anggaran permintaan terbatas per pemindaian, perbandingan respons dasar untuk menghindari WAF- kesalahan positif yang membingungkan, garis dasar pemeriksaan jalur acak untuk mendeteksi penerapan menyeluruh-403.
• Authorization gating for intrusive payloads. Mengirim SQLi atau OS- muatan perintah ke domain yang bukan milik Anda adalah ilegal di sebagian besar yurisdiksi. Pemindai sebenarnya memerlukan DNS atau HTTP- verifikasi kepemilikan file sebelum membiarkan Anda menjalankan mode aktif terhadap target.

Pendekatan FixVibe: pemindaian berbasis bukti, muatan positif palsu yang rendah

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 vs Burp Suite, ZAP, dan Nessus: ketika masing-masing alat menang

Tidak ada satu alat pun yang mencakup setiap alur kerja. Pembingkaian jujur ​​yang cocok dengan FixVibe:

Dimana alat-alat tersebut saling melengkapi

• Start with FixVibe passive sebagai baseline 30 detik gratis terhadap pratinjau penerapan apa pun. Jika tidak ada yang muncul, Anda memiliki sinyal percaya diri yang cepat.
• Pindah ke FixVibe active pada domain terverifikasi bila Anda menginginkan cakupan aktif penuh (SQLi/SSTI/IDOR/etc.) terhadap infrastruktur Anda sendiri.
• Layer SAST (Semgrep, CodeQL, Snyk) pada kode sumber di CI. SAST menangkap apa yang tidak dapat dilihat oleh runtime — pola berisiko dalam jalur kode yang tidak pernah mencapai penerapan.
• Reach for Burp Suite ketika Anda memerlukan rantai serangan khusus (bypass autentikasi spesifik, skenario IDOR yang rumit, kelemahan logika bisnis). Bersendawa adalah meja kerja manual terdalam yang tersedia; FixVibe adalah baseline otomatis tercepat.

Langkah selanjutnya

Continue dengan Vibe coding security checklist untuk audit pra-pengiriman 44 item, atau lompat ke How to secure an app built with AI coding tools untuk pengerasan langkah demi langkah dengan cuplikan kode.