Bir fikirden çalışan bir uygulamaya birkaç günde ulaşmak artık olağan. Cursor, Claude Code, Lovable ya da Bolt ile hazırlanan bir prototip demoda kusursuz görünebilir. Sorun, "demoda çalışıyor" ile "gerçek kullanıcıya açılabilir" arasındaki mesafenin görünmez olması.
Bu yazıda o mesafeyi ölçülebilir hale getirmeye çalışıyoruz: araştırmalar yapay zeka ile üretilen kod hakkında ne söylüyor, en sık hangi açıklar çıkıyor ve canlıya almadan önce hangi kontrolleri mutlaka yapmalısınız.
Çalışan Kod ile Güvenli Kod Aynı Şey Değil
Dil modelleri, istenen davranışı üreten kodu yazmakta çok iyi. Ama bir isteği karşılamak ile o isteğin kötüye kullanılamamasını sağlamak farklı problemler. "Kullanıcı profilini gösteren bir sayfa yap" dediğinizde model sayfayı yapar. "Başka bir kullanıcı URL'deki ID'yi değiştirirse ne olur?" sorusunu siz sormadıkça çoğu zaman sormaz.
Vibe coding'in doğası da bunu büyütüyor. Kod satır satır okunmadan kabul edildiğinde, güvenlik kararları hiç verilmemiş oluyor. Uygulama çalışıyor, çünkü test ettiğiniz tek senaryo iyi niyetli kullanıcı senaryosu.
Araştırmalar Ne Söylüyor?
Bu konuda artık tahmin değil, ölçüm var. İki çalışma özellikle öne çıkıyor.
Veracode 2025 GenAI Code Security Report, 100'den fazla dil modelini Java, JavaScript, Python ve C# üzerinde güvenlik açısından hassas görevlerle test etti. Üretilen kod örneklerinin %45'i OWASP Top 10 kapsamında bir açık içeriyordu. Cross-site scripting (XSS) görevlerinde modellerin başarısızlık oranı %86'ya çıktı.
CodeRabbit'in 2025 raporu ise gerçek pull request'lere baktı: yapay zeka destekli 320 PR ile yalnızca insan yazımı 150 PR karşılaştırıldı. Yapay zeka destekli PR'larda ortalama sorun sayısı 10,83, insan yazımı PR'larda 6,45 çıktı. Kategori bazında fark daha da belirgin:
| Açık türü | Yapay zeka destekli kodda |
|---|---|
| Cross-site scripting (XSS) | 2,74 kat daha sık |
| Güvensiz doğrudan nesne referansı (IDOR) | 1,91 kat daha sık |
| Hatalı parola işleme | 1,88 kat daha sık |
Burada dürüst olmak gerekiyor: sık tekrarlanan "yapay zeka kodu 2,74 kat daha fazla açık içeriyor" cümlesi aslında yalnızca XSS kategorisine ait. Genel tablo "her şey 3 kat kötü" değil. Ama belirli açık türlerinde sistematik bir eğilim olduğu açık, ve bu türler tam da canlıda en pahalıya patlayanlar.
Canlıya Almadan Önce 8 Maddelik Kontrol Listesi
Aşağıdaki liste, yapay zeka ile hızla geliştirilmiş projeleri devraldığımızda ilk baktığımız noktalardan oluşuyor. Hepsi birkaç günlük bir denetimle kontrol edilebilir.
1. Sırlar koda ya da istemciye sızmış mı?
API anahtarları, veritabanı bağlantı dizeleri ve servis hesabı bilgileri en sık bulduğumuz sorun. Özellikle frontend koduna gömülü anahtarlar, tarayıcıda herkes tarafından okunabilir. Git geçmişini de tarayın: silinen bir anahtar commit geçmişinde yaşamaya devam eder.
2. Yetkilendirme her istekte sunucuda kontrol ediliyor mu?
Kimlik doğrulama (kim olduğun) ile yetkilendirme (neye erişebileceğin) ayrı şeyler. Arayüzde bir butonu gizlemek yetkilendirme değildir. Her API ucunda, istenen kaydın o kullanıcıya ait olup olmadığını sunucu tarafında doğrulayın. IDOR açıklarının kaynağı tam olarak bu eksiklik.
3. Veritabanı erişim kuralları açık mı?
Supabase ve Firebase gibi servislerle kurulan projelerde istemci doğrudan veritabanıyla konuşur. Bu durumda tek savunma hattı satır düzeyi güvenlik kurallarıdır (Supabase'de RLS). Kuralı olmayan bir tablo, anonim anahtara sahip herkese açıktır.
4. Kullanıcı girdisi doğrulanıyor ve kaçışlanıyor mu?
Formdan, URL'den ya da API'den gelen her veriyi güvenilmez kabul edin. Sunucu tarafında şema doğrulaması yapın, ham HTML render etmekten kaçının, veritabanı sorgularında parametre kullanın.
5. Bağımlılıklar gerçek mi ve güncel mi?
Modeller zaman zaman var olmayan paket isimleri önerir. Saldırganlar bu isimleri kaydedip içine zararlı kod koyabilir; bu saldırıya "slopsquatting" deniyor. Her yeni bağımlılığın gerçekten beklenen paket olduğunu doğrulayın ve bilinen açıklar için otomatik tarama çalıştırın.
6. Hız sınırı ve kötüye kullanım koruması var mı?
Giriş, kayıt, parola sıfırlama ve özellikle dil modeli çağıran uçlar hız sınırı olmadan açılmamalı. Aksi halde bir gecede hem hesap ele geçirme denemeleri hem de beklenmedik bir API faturası ile karşılaşabilirsiniz.
7. Hata mesajları ve loglar fazla mı konuşuyor?
Canlı ortamda stack trace, SQL hatası ya da iç dosya yolu kullanıcıya dönmemeli. Loglarda ise parola, token ve kişisel veri tutulmamalı.
8. Geliştirme ile canlı ortam ayrı mı?
Ayrı veritabanı, ayrı anahtarlar, yedekleme ve geri dönüş planı. Vibe code projelerinde sık rastlanan senaryo, geliştirme sırasında kullanılan veritabanının olduğu gibi canlıya taşınması.
Kontrol Listesi Tek Başına Yetmez
Bu maddeler en sık görülen sorunları yakalar ama bir güvenlik denetiminin yerini tutmaz. Daha büyük risk, kodun kimse tarafından gerçekten anlaşılmamış olması. Bir açık bulunduğunda onu düzeltecek kişinin sistemin nasıl çalıştığını bilmesi gerekir. Bu konuyu bilgi borcu yazımızda ayrıntılı ele almıştık.
Bir de şunu eklemek gerekiyor: yapay zeka ile kod yazmak sorun değil. Ekiplerin büyük kısmı zaten bu araçları kullanıyor ve hız kazancı gerçek. Sorun, üretim hızının denetim hızını geçmesi. Çözüm yavaşlamak değil, denetimi de sürecin parçası yapmak: CI hattına statik analiz ve bağımlılık taraması eklemek, kritik uçlar için kod incelemesini zorunlu tutmak.
Sonuç
Vibe coding bir prototipi günler içinde ortaya çıkarmanın en hızlı yolu. Ama gerçek kullanıcı verisi taşıyan bir ürüne dönüşmeden önce, çalışan kodun güvenli koda çevrilmesi gerekiyor. Yukarıdaki sekiz madde bu işin başlangıç noktası.
Yapay zeka ile geliştirilmiş projelerin denetimini, güvenlik sağlamlaştırmasını ve canlıya alınmasını Vibe Code to Production hizmetimiz kapsamında yapıyoruz. Otomatik tarama ve dağıtım hatlarının kurulumu için DevOps ve CI/CD sayfamıza göz atabilirsiniz.
