Vibe Code'dan Production'a: Canlıya Almadan Önce Güvenlik Kontrol Listesi

Vibe code ile hazırlanmış bir uygulamayı canlıya almadan önce en az sekiz güvenlik kontrolü yapılmalıdır: sızmış sırlar, sunucu tarafında yetkilendirme, veritabanı erişim kuralları, girdi doğrulama, bağımlılıklar, hız sınırı, hata mesajları ve geliştirme ile canlı ortamın ayrılması. Sebebi, yapay zekanın ürettiği kodun çalışsa bile güvenli olmamasıdır: Veracode 2025 raporuna göre üretilen kod örneklerinin %45'i OWASP Top 10 kapsamında bir açık içeriyordu.

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:

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.

Bu tür sistemlere üretimde güvenli erişim vermeyi Yapay Zeka Ajanlarını Üretime Almak yazımızda, hızlı yazılan bir MVP'yi bu kontrol listesiyle canlıya almayı ise MVP Geliştirme Rehberimizde anlatıyoruz.

Sıkça Sorulan Sorular

Yapay zeka ile yazılan kod ne kadar güvenli? Veracode 2025 GenAI Code Security Report, 100'den fazla dil modelini test etti ve üretilen kod örneklerinin %45'inde OWASP Top 10 kapsamında bir açık buldu; XSS görevlerinde başarısızlık oranı %86'ya çıktı. CodeRabbit'in 2025 raporunda ise yapay zeka destekli PR'larda ortalama sorun sayısı 10,83, insan yazımı PR'larda 6,45 idi.

"Yapay zeka kodu 2,74 kat daha fazla açık içeriyor" doğru mu? Bu oran 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 var ve bunlar canlıda en pahalıya patlayan türler.

Supabase veya Firebase ile kurulan projede en kritik kontrol nedir? Satır düzeyi güvenlik kuralları. Bu servislerde istemci doğrudan veritabanıyla konuştuğu için tek savunma hattı bu kurallardır (Supabase'de RLS); kuralı olmayan bir tablo, anonim anahtara sahip herkese açıktır.

Slopsquatting nedir? Modellerin zaman zaman önerdiği, gerçekte var olmayan paket isimlerini saldırganların kaydedip içine zararlı kod koymasıdır. Her yeni bağımlılığın gerçekten beklenen paket olduğunu doğrulamak ve bilinen açıklar için otomatik tarama çalıştırmak gerekir.

Bu kontrol listesi bir güvenlik denetiminin yerini tutar mı? Hayır. Liste en sık görülen sorunları yakalar, ancak denetimin yerini tutmaz. Denetimi sürecin parçası yapmak için CI hattına statik analiz ve bağımlılık taraması eklemek, kritik uçlar için kod incelemesini zorunlu tutmak gerekir.