"Çalışıyor, demek ki bitti" — vibe coding'in en tehlikeli cümlesi budur. Bir vibe coding güvenlik kontrol listesi olmadan AI ajanına yazdırdığın kod, ekranda hatasız çalışırken production'da RLS politikası eksik bir tabloyu, client bundle'a gömülü bir API anahtarını veya hiç var olmayan bir paketi commit'e taşıyabilir. Bu yazı, bir satırını bile elle yazmadan üretilen kodu yayına almadan önce denetlemen gereken 12 somut maddeyi; listeyi gerçek CVE'ler, akademik ölçümler ve üretim olaylarına dayandırarak anlatıyor.
💡 Pro Tip: Denetim listesini "kod incelemesi" değil, "üretim yapılandırması incelemesi" olarak düşün — vibe coding'de asıl risk mantık hatası değil, varsayılan-açık kalan bir yetkilendirme veya sızan bir sırdır.
İçindekiler
- Vibe Coding'de Açık Neden Farklı Doğar
- Neden "çalışıyor" yetmiyor
- 12 Maddelik Vibe Coding Güvenlik Denetim Listesi
- Auth ve Yetkilendirme: RLS'nin Sessiz Yokluğu
- Denetim adımı
- Secret ve Env Sızıntısı: Commit, Client Bundle, Log
- Denetim adımı
- Bağımlılık Zinciri: Uydurma Paket ve Sürüm Pinleme
- Denetim adımı
- Ajanın Kendi İzinleri: Sandbox, Allowlist, Working-Directory Kilidi
- Denetim adımı
- Gerçek Olaylar ve Tekrarlayan Desen
- Denetim adımı
- CI'ya Bağlanacak Otomatik Kapılar
- Denetim adımı — minimal CI kapısı
- Denetim Listesini Kod İncelemesi Sürecine Yerleştirmek
- Denetim adımı
- SSS
- Vibe coding ile yazılan kod güvenli mi?
- AI'nın yazdığı kodda en sık hangi güvenlik açıkları çıkar?
- AI üretimi kodu production'a almadan önce hangi güvenlik kontrolleri yapılmalı?
- AI kodlama ajanının secret sızdırmasını nasıl engellerim?
- Sonuç
- Kaynaklar
Vibe Coding'de Açık Neden Farklı Doğar
Geleneksel kod incelemesinde geliştirici her satırı yazar, sonra başka biri okur. Vibe coding'de bu sıra tersine döner: geliştiricinin rolü "implementer"dan "reviewer"a kayar ve satır satır anlama oranı düşer. Sonuç, tekrar eden ve tahmin edilebilir bir zafiyet sınıfı üretimi oluyor — RCE/eval kullanımı, encoding atlayan XSS, string-concatenation ile kurulan SQL sorguları, bellek bozulması ve sızan sırlar (Legit Security, ASPM knowledge base).
Bu tekrar eden desen ölçüldü: Veracode'un 2025 GenAI Code Security Report'u, 100'den fazla büyük dil modelinden toplanan kod örneklerinin %45'inin güvenlik testlerinden geçemediğini ve koda OWASP Top 10 zafiyeti soktuğunu gösterdi. Bu oran "AI kötü kod yazıyor" demek değil; "AI'nın ürettiği kodu insan kadar şüpheyle okumazsan açık kaçırırsın" demek. Vibe coding güvenlik kontrol listesinin ilk maddesi de tam burada başlıyor: her çıktıyı, bir stajyerin ilk PR'ı gibi oku.
Neden "çalışıyor" yetmiyor
Bir ajan sana çalışan bir giriş formu, çalışan bir API endpoint'i verebilir — ama "çalışıyor" testi yetkilendirme, girdi doğrulama veya sır yönetimini test etmez. Bu üç alan, aşağıdaki 12 maddelik listenin omurgasını oluşturuyor.
12 Maddelik Vibe Coding Güvenlik Denetim Listesi
Aşağıdaki liste, ilerideki bölümlerde tek tek açıklanan somut ve denetlenebilir kontrollerin özetidir. Her madde "evet/hayır" ile cevaplanabilir olacak şekilde yazıldı — "genel olarak güvenli görünüyor" gibi belirsiz bir cevap kabul etme.
# | Kontrol Maddesi | Denetim Yöntemi |
|---|---|---|
1 | Her tabloda RLS/row-level policy aktif mi? | Migration dosyasında ENABLE ROW LEVEL SECURITY ara |
2 | Her API route'ta auth middleware zorunlu mu? | Route listesini auth middleware listesiyle eşleştir |
3 | Kod içinde hardcoded credential var mı? | grep -rnE "api_key|secret|password" --include="*.ts" |
4 | .env geçmiş commit'lerde sızmış mı? | git log -p -- .env + .gitignore kontrolü |
5 | Client bundle'a admin/service-role key gömülü mü? | Build çıktısında service_role string'ini ara |
6 | SQL sorguları parametreli mi? | String concatenation ile kurulan sorgu ara |
7 | Her bağımlılık gerçekten var mı? | npm view <paket> / pip index versions <paket> |
8 | Sürümler exact pin mi? | ^/~ yerine tam sürüm numarası kontrolü |
9 | Ajanın dosya erişimi allowlist ile sınırlı mı? | Permission config'te deny/allow glob'ları oku |
10 | Ajan working directory dışına çıkabiliyor mu? | Sandbox ayarını ve mutlak yol erişimini test et |
11 | Log dosyalarına secret/PII yazılıyor mu? | Log çıktısında token/e-posta pattern'i ara |
12 | CI'da SAST + secret-scan + dep-audit var mı? | Pipeline YAML'ında ilgili adımları doğrula |
Auth ve Yetkilendirme: RLS'nin Sessiz Yokluğu
Vibe coding'de en sık görülen ve en pahalı hata sınıfı, satır satır yazılan kötü kod değil; hiç yazılmayan yetkilendirme katmanıdır. Supabase gibi backend-as-a-service platformlarında bir tablo SQL migration'ı veya AI aracıyla oluşturulduğunda Row Level Security varsayılan olarak KAPALI kalır — yalnız Table Editor arayüzünden manuel oluşturulan tablolarda otomatik açılır. Bir ajana "kullanıcı profili tablosu oluştur" dedirttiğinde, ajan migration dosyası ürettiği sürece bu varsayılan kapalı durum devam eder.
Mayıs 2025'te yayımlanan CVE-2025-48757, tam olarak bu deseni belgeliyor: güvenlik araştırmacısı Matt Palmer'ın taraması, incelenen 1.645 Lovable projesinin 170'inde (yaklaşık %10,3) eksik ya da yetersiz RLS politikası buldu; NVD kaydında zafiyete CVSS 9.3 (kritik) puanı verildi — aynı kayıtta Lovable tarafının itirazını gösteren disputed etiketi de bulunuyor. Bu, "hatalı yetkilendirme" (CWE-863) sınıfının klasik bir örneği — MITRE'nin CWE-863 tanımı, ürünün yetkilendirme kontrolünü yapması ama bu kontrolü doğru yapmaması durumunu kapsıyor.
Denetim adımı
Her migration dosyasında ENABLE ROW LEVEL SECURITY ve karşılık gelen CREATE POLICY satırlarını ara; biri eksikse tablo varsayılan olarak herkese açıktır.
sql
1-- Doğru desen: tablo + RLS + politika birlikte gelmeli2CREATE TABLE profiles (id uuid PRIMARY KEY, user_id uuid REFERENCES auth.users);3ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;4CREATE POLICY "kullanici_kendi_verisi" ON profiles5 FOR SELECT USING (auth.uid() = user_id);Secret ve Env Sızıntısı: Commit, Client Bundle, Log
Legit Security'nin ASPM bilgi tabanı, vibe coding çıktılarında üç tekrarlayan sızıntı deseni tanımlıyor: kaynak dosyalara gömülen hardcoded credential, repoya commit'lenen .env dosyalarındaki API anahtarları ve debug sırasında loglanan token'lar. İlk ikisi CWE-798 (Use of Hard-coded Credentials) kapsamına giriyor — MITRE'nin tanımına göre bu zafiyet sınıfı, bir yazılımın kaynak koduna veya konfigürasyon dosyasına gömülü, değiştirilmesi zor bir kimlik bilgisi içermesi anlamına geliyor.
Şubat 2026'da ortaya çıkan Moltbook olayı bu desenin somut hali: Wiz araştırmacılarına göre bir Supabase API anahtarı, RLS politikası olmadan doğrudan production JavaScript dosyasının içinde bulunuyordu ve bu dosya incelenerek tespit edildi. Sızan veri, on binlerce kullanıcının e-posta adresini kapsıyordu (kaynak: wiz.io/blog). Anahtarın kendisi "gizli" değildi — herkese açık bir JavaScript bundle'ının içindeydi.
Denetim adımı
bash
1# Geçmiş commit'lerde .env sızıntısı tara ("**/" kök .env'i kaçırır, kök desenleri şart)2git log --all --full-history -- ".env" ".env.*" "**/.env" "**/.env.*"3 4# Build çıktısında service-role/admin anahtar izini ara5grep -r "service_role\|SUPABASE_SERVICE" .next/static/ 2>/dev/nullBir anahtar client bundle'da görünüyorsa, o anahtar zaten sızmış sayılır — rotasyon tek çözümdür, "kimse bakmaz" varsayımı geçerli değildir.
Bağımlılık Zinciri: Uydurma Paket ve Sürüm Pinleme
AI ajanlarının bağımlılık önerirken var olmayan paket adları "halüsine etmesi" (slopsquatting olarak adlandırılan risk) akademik olarak ölçülmüş bir sorun. Spracklen ve arkadaşlarının 576.000 kod örneği üzerinde yaptığı çalışma (arXiv:2406.10279), halüsine edilen paketlerin ortalama oranının ticari modellerde en az %5,2, açık kaynak modellerde en az %21,7 olduğunu gösterdi. Aynı çalışma, halüsine edilen Python paketlerinin %8,7'sinin aslında geçerli birer JavaScript paketi olduğunu da tespit etti.
2026'da yayımlanan bir takip çalışması (arXiv:2605.17062), bu aralığın %5,2–21,7'den %4,62–6,10'a sıkıştığını gösterdi — iyileşme var ama risk sıfırlanmadı. Bir saldırgan, sık halüsine edilen bir paket adını gerçekten yayımlayarak (typosquatting'in AI-özel versiyonu) tedarik zinciri saldırısı düzenleyebilir.
Denetim adımı
bash
1# package.json'daki her paketin gerçekten var olduğunu doğrula2cat package.json | jq -r '.dependencies | keys[]' | while read pkg; do3 npm view "$pkg" version >/dev/null 2>&1 || echo "UYARI: $pkg bulunamadı"4doneSürüm aralığı (^1.2.3) yerine exact pin (1.2.3) kullanmak, ajan bir sonraki çalıştırmada farklı (ve doğrulanmamış) bir minor sürüme atlamasını da engeller — tedarik zinciri denetiminin ikinci ayağı budur.
Ajanın Kendi İzinleri: Sandbox, Allowlist, Working-Directory Kilidi
Denetim listesinin ilk sekiz maddesi ajanın ürettiği koda bakıyordu; 9. ve 10. maddeler ajanın kendisine, 11. ve 12. maddeler ise çalışma zamanına ve CI pipeline'ına bakıyor. Ajanın dosya sistemi, ağ ve komut çalıştırma izinleri de "üretilen kod" kadar denetlenebilir bir yüzeydir. Claude Code'un resmi dokümantasyonuna göre Read ve Edit izin kuralları gitignore deseniyle tanımlanır ve deny kuralları her zaman allow kurallarının önüne geçer (code.claude.com/docs/en/permissions); sandbox'lı bash komutları ise varsayılan olarak geçerli çalışma dizinine, oturumun geçici dizinine ve açıkça eklediğin dizinlere yazabilir (code.claude.com/docs/en/sandboxing).
Bu üç kural, bir denetim kontrol listesine dönüştürülebilir: ajanın konfigürasyonunda deny listesi var mı, .env/secrets/ gibi hassas yollar açıkça reddediliyor mu, ve bash çalıştırma çalışma dizini dışına (/etc, ~/.ssh) yazma izni veriyor mu?
Denetim adımı
json
1{2 "permissions": {3 "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(rm -rf *)"],4 "allow": ["Bash(npm test)", "Bash(git diff)"]5 }6}Ayrı bir gelişme olarak Cursor, "self-hosted machines" adlı bir özellik duyurdu — ajanın tool-call'ları artık AWS Lambda, Cloudflare, Daytona, Modal, Vercel veya E2B gibi müşterinin kendi altyapısında çalışabiliyor, kod ve sırlar üçüncü taraf sunucuya çıkmıyor (cursor.com/changelog/self-hosted-machines). Bu, "ajanın izinleri" denetiminin altyapı seviyesindeki karşılığı.
Gerçek Olaylar ve Tekrarlayan Desen
Teoriyi somutlaştırmak için iki üretim olayına bakalım. Temmuz 2025'te Tea uygulamasında yaşanan veri ihlalinde 1,1 milyondan fazla özel direkt mesaj açığa çıktı (TechCrunch) — bu olay burada yalnızca ölçek için anılıyor; kaynak, uygulamanın AI ile üretildiğine dair bir bağ belgelemiyor. Şubat 2026'daki Moltbook olayında ise yukarıda anlattığımız gibi client-side'a gömülü bir Supabase anahtarı, RLS eksikliğiyle birleşince on binlerce kullanıcının e-posta adresi açığa çıktı (Wiz).
Moltbook'u ve CVE-2025-48757'yi yan yana koyduğunda ortak bir desen görülüyor: ikisinde de kimse özel bir exploit yazmadı, zero-day kullanmadı — sadece halka açık bir uygulamanın temel bir yetkilendirme kontrolünü atladığını fark ettiler. Vibe coding güvenlik kontrol listesinin var olma nedeni tam olarak bu: "temel yanlış yapılandırma" saldırganlar için en ucuz bulgu türüdür, çünkü aranması özel bilgi gerektirmez.
Denetim adımı
Yayına almadan önce şu soruyu sor: "Bu özelliği kimse test etmeseydi, en kolay nasıl kötüye kullanılırdı?" Cevap genelde "yetkilendirmesiz bir endpoint'e istek atarak" veya "client'ta görünen bir anahtarı kullanarak" oluyor — ikisi de bu yazıdaki 12 maddenin ilk beşinde zaten karşılanıyor.
CI'ya Bağlanacak Otomatik Kapılar
12 maddelik listeyi elle her PR'da kontrol etmek sürdürülebilir değil — bu yüzden son madde, listenin geri kalanını otomatikleştirmekle ilgili. Üç katman önerilir: SAST (statik kod analizi, encoding/SQL/eval desenlerini yakalar), secret-scan (commit'e giren anahtarları PR aşamasında engeller) ve dependency-audit (halüsine edilmiş veya bilinen zafiyetli paketleri işaretler).
OpenAI'a göre, Mart 2026'da duyurulan Codex Security aracı, gürültülü SAST çıktısı yerine sandbox içinde doğrulanmış ve önceliklendirilmiş bulgular üretmeyi hedefliyor; araç duyurudan önceki 30 günde harici depolarda 1,2 milyondan fazla commit tarayıp 792 kritik ve 10.561 yüksek önemli bulgu belirledi. Bu araçların yanına projene özel bir kapı da ekle: RLS/auth kontrolünü CI'da migration-diff'e bağla — CVE-2025-48757'nin pratik düzeltmesi de tam olarak budur: her migration'ın ENABLE ROW LEVEL SECURITY satırı içerdiğini otomatik doğrulamak.
Denetim adımı — minimal CI kapısı
yaml
1# .github/workflows/security-gate.yml2name: security-gate3on: [pull_request]4jobs:5 security:6 runs-on: ubuntu-latest7 steps:8 - uses: actions/checkout@v69 with:10 fetch-depth: 011 - name: RLS kontrolü12 run: |13 missing=$(grep -L "ENABLE ROW LEVEL SECURITY" prisma/migrations/*/migration.sql || true)14 if [ -n "$missing" ]; then15 echo "RLS eksik migration bulundu:"16 echo "$missing"17 exit 118 fi19 - name: Secret tarama20 uses: gitleaks/gitleaks-action@v321 env:22 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}23 - name: Bağımlılık denetimi24 run: npm audit --audit-level=highBu üç adım, 12 maddenin üçünü (1, 3 ve 4) her PR'da otomatik denetler; kalan dokuzu (client bundle taraması, RLS politikasının mantıksal doğruluğu, ajan izin konfigürasyonu gibi) ayrı bir adım ya da manuel gözden geçirme gerektirir.
Denetim Listesini Kod İncelemesi Sürecine Yerleştirmek
12 maddelik listeyi tek bir dev "güvenlik denetimi" adımına sıkıştırmak yerine, üç aşamaya bölmek daha sürdürülebilir: ajan koda başlamadan önce (izin konfigürasyonu, allowlist), ajan kodu ürettikten hemen sonra (auth/RLS/secret taraması, kendi oturumunda) ve PR birleşmeden önce (CI kapıları). Bu üçlü ayrım, tek bir kişinin veya tek bir aracın her şeyi yakalamasını beklemek yerine, her aşamanın kendi doğal sorumluluğunu üstlenmesini sağlıyor.
Pratikte bu şu anlama geliyor: yeni bir proje kurarken ajan izin dosyasını (.claude/settings.json veya eşdeğeri) ilk commit'te yaz, .env ve secrets/ yollarını deny listesine ekle. Ajan bir özellik ürettiğinde, aynı promptun sonuna "şimdi bu kodu CWE-863 ve CWE-798 açısından kendin denetle" cümlesini ekle — bu, Altın İpucu bölümünde anlatılan ikinci-geçiş tekniğinin günlük iş akışına yerleşmiş hali. PR açılırken de CI'daki üç otomatik kapı (SAST, secret-scan, dependency-audit) zaten çalışmış olur; insan gözden geçirmesi bu noktada yalnızca "mantık doğru mu" sorusuna odaklanabilir, "sır sızdı mı" sorusuna değil.
Denetim adımı
Ekip büyüdükçe bu üç aşamayı bir şablon PR açıklamasına dönüştür: "İzin konfigürasyonu güncellendi mi? Ajan ikinci-geçiş denetimi yapıldı mı? CI kapıları yeşil mi?" — üç kutu, üç aşama, tek bakışta durum.
ALTIN İPUCU
Bu yazının en değerli bilgisi
Bu ipucu, yazının en önemli çıkarımını içeriyor.
Easter Egg
Gizli bir bilgi buldun!
Bu bölümde gizli bir bilgi var. Keşfetmek ister misin?
Okuyucu Ödülü
Bu makaledeki 12 maddeyi tek sayfalık, PR açıklamasına yapıştırabileceğin düz bir checklist'e indirdik. Her satırı işaretleyerek yayına almadan önceki son kontrolü hızlıca yapabilirsin.
SSS
Vibe coding ile yazılan kod güvenli mi?
Otomatik olarak değil. Veracode'un 2025 GenAI Code Security Report'una göre AI üretimi kod örneklerinin %45'i güvenlik testlerinden geçemedi ve koda OWASP Top 10 zafiyeti soktu. Bu, vibe coding'in doğası gereği güvensiz olduğu anlamına gelmez; insan gözden geçirmesi olmadan üretilen her kod parçası gibi, denetlenmeden yayına alınırsa risk taşıdığı anlamına gelir. Bu yazıdaki 12 maddelik listeyi uygulamak bu riski ölçülebilir şekilde azaltır.
AI'nın yazdığı kodda en sık hangi güvenlik açıkları çıkar?
Tekrarlayan desen; hatalı yetkilendirme (CWE-863, özellikle RLS'nin varsayılan kapalı kalması), hardcoded credential (CWE-798) ve parametrelenmemiş SQL sorguları (CWE-89). Bu üç zafiyet sınıfı, hem Legit Security'nin gözlemlerinde hem de CVE-2025-48757 gibi belgelenmiş olaylarda öne çıkıyor.
AI üretimi kodu production'a almadan önce hangi güvenlik kontrolleri yapılmalı?
Bu yazıdaki 12 maddelik denetim listesinin tamamı: RLS/auth kontrolü, secret taraması, bağımlılık doğrulaması ve ajanın kendi izin konfigürasyonunun gözden geçirilmesi. CI'da SAST + secret-scan + dependency-audit adımlarının otomatik çalışması, bu kontrollerin çoğunu her PR'da tekrarlanabilir hale getirir.
AI kodlama ajanının secret sızdırmasını nasıl engellerim?
Üç katman gerekir: .env dosyasını .gitignore'a ekle ve geçmiş commit'leri tara, build çıktısında service-role/admin anahtarı aramak için otomatik bir adım kur, ve ajan konfigürasyonunda .env/secrets/ yollarını açıkça deny listesine ekle — Claude Code'un izin sistemi bu tür glob tabanlı reddetmeleri destekliyor (code.claude.com/docs/en/permissions).
Sonuç
Vibe coding'in getirdiği hız, denetim sorumluluğunu ortadan kaldırmıyor — sadece nerede uygulandığını değiştiriyor: satır satır kod incelemesinden, yapılandırma ve yetkilendirme denetimine. Bu yazıdaki 12 maddelik liste, CVE-2025-48757 ve Moltbook olayının gösterdiği gibi, en pahalı hataların genelde en basit kontrol eksikliklerinden doğduğunu hatırlatıyor.
Konuyu derinleştirmek istersen, iOS Security Best Practices yazısı genel mobil güvenlik prensiplerini, iOS Keychain ve Güvenlik sır yönetimini platform seviyesinde, iOS Network Security Advanced ise ağ katmanı sertleştirmesini ele alıyor. Ajan tarafındaki riskleri daha geniş bağlamda görmek için AI ile Kodlamada 10 Yanılgı ve araç seçimi için GitHub Copilot vs Claude Code vs Cursor karşılaştırmasına göz atabilirsin.
Kaynaklar
- Vibe Coding Security — Legit Security ASPM Knowledge Base — vibe coding'de tekrarlayan zafiyet sınıflarının (RCE/eval, XSS, SQLi, secrets exposure) genel çerçevesi
- 2025 GenAI Code Security Report — Veracode — 100'den fazla dil modelinden alınan kod örneklerinin %45'inin güvenlik testlerinden geçemediğini gösteren ölçüm
- We Have a Package for You! (Slopsquatting) — arXiv:2406.10279 — 576.000 örnekte halüsine edilen paket oranlarının (%21,7 açık kaynak, %5,2 ticari) ölçümü
- The Range Shrinks, the Threat Remains — arXiv:2605.17062 — 2026 frontier-model kohortunda halüsine edilen paket oranının %4,62–6,10 aralığına daraldığını gösteren takip çalışması
- CVE-2025-48757 — mattpalmer.io — Lovable/Supabase projelerinde yetersiz RLS politikalarından doğan kritik zafiyetin resmi bildirimi
- Statement on CVE-2025-48757 — mattpalmer.io — taramanın 1.645 projenin 170'inde (%10,3) yetersiz RLS bulduğunu belgeleyen araştırma notu
- Exposed Moltbook Database — Wiz Blog — client-side'a gömülü Supabase anahtarının RLS eksikliğiyle birleştiği olayın analizi
- Tea App's Data Breach Gets Much Worse — TechCrunch — 1,1 milyondan fazla özel direkt mesajın açığa çıktığı ihlalin haberi
- CWE-798: Use of Hard-coded Credentials — MITRE — hardcoded credential zafiyet sınıfının resmi tanımı
- CWE-863: Incorrect Authorization — MITRE — hatalı yetkilendirme zafiyet sınıfının resmi tanımı
- Claude Code Permissions — code.claude.com — ajan izin sisteminde deny/allow önceliği ve Read/Edit kurallarının gitignore desen sözdizimi
- Claude Code Sandboxing — code.claude.com — sandbox'lı bash komutlarının varsayılan yazma erişimi kapsamı
- Codex Security, now in research preview — OpenAI — 1,2 milyondan fazla commit taramasında 792 kritik ve 10.561 yüksek önemli bulgunun duyurulduğu birincil kaynak
