Vibe Coding Güvenliği: AI Kodu Yazdı, Açığı Kim Kapatacak? (2026)

Bir fikrin var. Cursor'a ya da Lovable'a anlatıyorsun, yarım saat sonra çalışan bir uygulama elinde. Tıklıyorsun, açılıyor, kayıt oluyor — harika. Sorun şu: çalışıyor görünmesi güvenli olduğu anlamına gelmiyor. AI'nın ürettiği kod parlak ve tamamlanmış göründüğü için en az denetlenen kod oluyor. İstatistikler de bunu doğruluyor: bir 2026 çalışmasında AI üretimi kod örneklerinin %25,1'inde en az bir doğrulanmış güvenlik açığı çıktı, başka analizler ise AI kodunun insan koduna göre kabaca iki kat daha sık açık ürettiğini söylüyor.

Bu rehber vibe coding'i bırakman için değil. Tam tersi — hızını koruyup, yayına almadan önce seni batırabilecek açıkları nasıl kapatacağını anlatıyor.

Vibe coding neden güvenlik açığı üretir?

Mesele AI'nın "aptal" olması değil. Model kodu işlevsellik için optimize eder, güvenlik için değil. "Bana giriş sistemi yap" dediğinde çalışan bir giriş sistemi verir; rate limitingⁱBir kullanıcının belirli sürede yapabileceği istek sayısını sınırlama., parola hash'leme ya da yetki kontrolü istemediysen onları eklemeyebilir.

Üç şey bir araya gelince açık kaçınılmaz oluyor: hacim (dakikalar içinde yüzlerce satır), tekrarlayan güvensiz kalıplar (model aynı eksik deseni her projede üretir) ve en sinsisi — "hazır görünüyor, demek ki doğrudur" yanılgısı. Kod düzgün girintili ve kendinden emin göründüğü için kimse okumuyor. Cloud Security Alliance bu durumu doğrudan "AI üretimi CVEⁱBilinen güvenlik açıklarına verilen standart kayıt numarası. patlaması" diye adlandırdı.

Gerçekten ne oluyor: üç vaka

Soyut konuşmayalım. Bunlar oldu:

Moltbook (28 Ocak 2026). Kurucusunun "tek satır kod yazmadığını" söylediği bir AI sosyal ağı. Yayına çıktıktan üç gün sonra Wiz'deki güvenlik araştırmacıları tüm production veritabanının açıkta olduğunu buldu: 1,5 milyon API kimlik doğrulama token'ı, 35 bin e-posta adresi ve özel mesajlar.

Lovable. 8 milyon kullanıcılı, 6,6 milyar dolar değerlemeli bir vibe coding platformu. Bir açık, ücretsiz hesabı olan herhangi birinin yalnızca birkaç API çağrısıyla başka bir kullanıcının kaynak koduna ve veritabanı bilgilerine ulaşmasına izin verdi. Denetimlerde Lovable ile üretilen uygulamaların büyük bölümünde RLSⁱRow-Level Security — veritabanında satır bazında kimin neyi görebileceğini belirleyen kural katmanı. tamamen kapalı çıktı.

Tea app. Güvenliğin sonradan düşünülen bir şey olmasının bedelini gösteren, kullanıcı verilerinin sızdığı bir ihlal — Barracuda'nın vibe coding güvenliği üzerine yazısında dönüm noktası örneği olarak işleniyor.

Ortak nokta: hiçbiri "hacker dehası" değildi. Hepsi kapatılması beş dakika süren temel açıklardı.

En sık beş açık (ve nasıl kapatırsın)

1. Koda gömülü secret / API key. En yaygını. Model anahtarı doğrudan kodun içine yazar, sen de git'e push'larsın — artık herkese açık. Sızan bir AI sağlayıcı anahtarı, fatura sana gelene kadar başkası tarafından harcanır. Pentest'lerde vibe-coded SaaS'ların kabaca 10'da 4'ünde AI anahtarı sızıntısı bulunuyor. Çözüm: anahtarları .env dosyasına al, .gitignore'a ekle, asla client-side koda koyma.

2. Yetkilendirme / RLS kapalı. Uygulama "çalışıyor" çünkü herkes her veriye erişebiliyor. Supabase gibi backend'lerde RLS'i açmadıysan, bir kullanıcı API üzerinden başkasının verisini çekebilir. Çözüm: her tabloda satır bazında erişim kuralı tanımla, "sadece kendi verisi" varsayılan olsun.

3. Input doğrulama yok → injection. Kullanıcıdan geleni doğrudan sorguya ya da sayfaya koyarsan SQL injection ve XSS kapıda. Bu klasik açık, AI ile yine geri döndü. İlgili tarafı prompt injection rehberinde ayrıca anlattım. Çözüm: parametreli sorgular, çıktı kaçışı (escaping), gelen veriyi şemayla doğrulama.

4. Güncellenmemiş veya uydurma bağımlılıklar. Model bazen var olmayan ya da eski, açıklı paketleri önerir. Çözüm: bağımlılıkları kilitle, otomatik güvenlik güncellemesi aç, eklemeden önce paketin gerçek ve bakımlı olduğunu doğrula.

5. Sırların client-side'da görünmesi. Tarayıcıya giden her şey okunabilir. API anahtarını ya da gizli mantığı frontend'e koyarsan F12 yeter. Çözüm: hassas işleri sunucu tarafına taşı, tarayıcıya sadece kullanıcının görmesi gerekeni gönder.

[mindi_yorum]
💰 Yukarıdaki beş açığın hiçbirini kapatmak para istemiyor — hepsi alışkanlık meselesi.
🟢 İlk üçünü (secret, RLS, input) hallettiysen, vibe-coded uygulamaların ihlallerinin çoğunu zaten elemişsin demektir.
🟡 "Sonra eklerim" tuzağına düşme — yayına çıkmış bir uygulamada secret rotate etmek, baştan doğru yapmaktan on kat zahmetli.
🔵 Her yeni özellikten sonra tek soru sor: "Bu veriye erişmemesi gereken biri erişebilir mi?"

Yayına almadan önce kontrol listesi

Deploy butonuna basmadan önce şunları geç:

• .env dosyan .gitignore'da mı, repo geçmişinde sızmış anahtar var mı?
• Veritabanındaki her tabloda erişim kuralı (RLS) açık mı?
• Kullanıcıdan gelen her girdi doğrulanıyor/temizleniyor mu?
• Tarayıcıya giden kodda hiç gizli anahtar veya sır var mı?
• Bağımlılıklar güncel ve gerçek mi, bilinen açık taraması yapıldı mı?
• Hata mesajları kullanıcıya veritabanı/sistem detayı sızdırıyor mu?

Altısına da "evet/temiz" diyemiyorsan, henüz yayına hazır değilsin.

Güvenli prompt: AI'ya güvenliği baştan söylet

En ucuz savunma, isteği doğru kurmak. "Giriş sistemi yap" yerine güvenlik gereksinimlerini prompt'a göm:

Kullanıcı girişi ekle: parolaları Argon2 ile hash'le, veritabanı sorgularında parametreli sorgu kullan, login'e rate limiting koy, oturumları JWT ile yönet ve OWASP güvenli kodlama pratiklerine uy.

Aynı modeli kullanıyorsun ama çıktı bambaşka oluyor. Güvenliği istemezsen model varsayılan olarak en kısa yolu seçer.

Açığı sana bulduracak araçlar

Gözle denetim şart ama yetmez. Otomatik tarama hattına al:

• Codex Security. OpenAI bu eklentiyi yeni herkese açtı — Codex kullanıyorsan kod tabanını birkaç tıkla açıklar için taratıp yama önerisi alabiliyorsun. Detayını haberde yazdım.
• Semgrep. OWASP kural setleriyle çalışan SASTⁱStatic Application Security Testing — kodu çalıştırmadan, statik olarak açık tarayan analiz. aracı. Açık kaynak CLI'ı ücretsiz.
• Secret tarayıcı. gitleaks ya da git-secrets ile repo'na sızmış anahtarları yakala — ikisi de açık kaynak ve ücretsiz, commit öncesi çalıştır.
• Bağımlılık taraması. Kullandığın paketlerdeki bilinen açıkları otomatik raporlayan bir tarayıcı bağla.

[mindi_yorum]
💰 Codex Security eklentisi açık erişimde (Codex hesabı yeterli); Semgrep ile gitleaks açık kaynak ve ücretsiz. Bu hat sana sıfır lira.
🟢 Pre-commit aşamasına secret + SAST taraması koymak, açıkların büyük kısmını daha git'e girmeden eler.
🟡 Hiçbir tarayıcı %100 değil — araç "temiz" dedi diye gözle kontrolü atlama, özellikle yetki mantığını.
🔵 Taramayı CI'ya bağla; elle çalıştırmayı er ya da geç unutursun.

Sonuç — şimdi ne yaparsın

Vibe coding hızı gerçek, riski de gerçek. İkisini birlikte yönetmenin yolu, güvenliği en sona değil akışın içine koymak. Bugün şunlarla başla:

1. Mevcut projende .env ve git geçmişini secret için tara — sızmış anahtar varsa hemen rotate et.
2. Veritabanındaki tüm tablolarda RLS / erişim kurallarını aç.
3. Bir sonraki prompt'una güvenlik gereksinimlerini ekle ve farkı gör.
4. Repo'na gitleaks + Semgrep'i bağla, mümkünse pre-commit aşamasına koy.

Kodun büyük kısmını AI yazıyor olabilir, ama yayına alan sensin — açığı da kapatacak olan sensin.