Vibe-Code to Production

Bir uygulama artık birkaç cümlelik bir komutla saatler içinde ortaya çıkıyor: Cursor'da bir özellik isteniyor, Lovable'da bir arayüz tasarlanıyor, Replit'te bir backend ayağa kalkıyor, Codex ya da Claude Code bir entegrasyonu bağlıyor. Ekranlar çalışıyor, form veri kaydediyor, kullanıcı girişi oluyor. Ama modelin optimize ettiği şey isteği bitirmek, üretime dayanıklı olmak değil. Veracode'un yüzden fazla modeli test ettiği 2025 raporunda üretilen kodun yüzde 45'i OWASP Top 10 kapsamına giren bir açık taşıyordu, üstelik modelin büyüklüğü bu oranı değiştirmiyor. Bağımsız bir denetimde vibe-code edilmiş uygulamaların yalnızca yüzde 10,5'i güvenli çıktı. Sorun yalnız güvenlikle de sınırlı değil: ödeme veya kimlik doğrulama gibi entegrasyonlar yarım kalıyor, uygulama hiç gerçek kullanıcı yüküyle sınanmamış oluyor, AI çağrılarına harcama ya da oran sınırı konmamış kalıyor. Bu hizmet tam da o noktada devreye giriyor: ürününü bu araçlarla belirli bir yere kadar getirmiş, şimdi üretime çıkmadan önce neyin eksik olduğunu bilmeyen ekiplerin işini üstleniyoruz.

Üç senaryo, üç farklı giriş noktası

Bize üç halden biriyle geliniyor. Birincisi canlıdaki bir sızıntı: kullanıcı verisi, API anahtarı ya da başka bir müşterinin kaydı yanlışlıkla görünür durumda ve bunu ya siz ya bir güvenlik araştırmacısı fark etmiş. İkincisi yayın öncesi kontrol: ürün bitti sayılıyor ama kimse güvenlik ve dayanıklılık tarafına sistemli biçimde bakmadı, yayına almadan önce bir profesyonelin gözünden geçmesi isteniyor. Üçüncüsü büyüme durması: kod bir noktadan sonra dokunulması korkulan bir yığına dönüştü, hızlı üretilen her yeni özellik eskisini bozma riski taşıyor ve kimse nereden başlayacağını bilmiyor. Üçünde de ilk iş aynı: mevcut kodu okumak, neyin çalıştığını ve neyin şans eseri çalıştığını ayırmak. Hangi senaryodan geldiğiniz kapsam görüşmesinin ilk sorusu, çünkü canlı bir sızıntıda öncelik hız, yayın öncesi kontrolde ise öncelik kapsamın eksiksizliği oluyor.

Üç aşama: bul, düzelt, kapıyı kur

Çoğu vibe-code denetimi tek bir teslimat yapıyor: bulguları sıralayan bir rapor. Bulgu listesi kod tabanınızı değiştirmez, sadece nerede durduğunuzu söyler. Bizim işimiz üç aşamalı: birinci aşama denetim, yalnızca güvenlik açıklarını değil, yarım kalmış entegrasyonları, hiç yük altında sınanmamış uç noktaları ve sınırsız AI çağrılarının maliyet riskini de kapsıyor; ikinci aşama düzeltme; üçüncü aşama ise kodun her güncellemede otomatik olarak derlenip yayına hazırlandığı CI/CD hattına gömülü kalıcı bir güvenlik kapısı kurmak. Üçüncü aşama olmadan ikisi de geçicidir, çünkü bir sonraki AI destekli commit aynı hata sınıfını yeniden üretir. Kapı kurulduktan sonra siz ya da AI aracınız her yeni değişiklik gönderdiğinde otomatik taranıyor, birleştirme öncesinde durduruluyor.

Denetimde nereye bakıyoruz

Dört alan sabit taranıyor, çünkü gerçek sızıntıların neredeyse tamamı buradan çıkıyor: kimin neyi görebildiği, sırların nerede durduğu, bağımlılıkların gerçekten var olup olmadığı ve kullanıcı girdisinin nereye gittiği. Bunların yanında ödeme, kimlik doğrulama gibi yarım kalmış entegrasyonları ve gerçek trafikte kırılacak uç noktaları da işaretliyoruz; bu bulgular ayrı bir denetim kalemi değil, aynı taramanın parçası.

Erişim kontrolü ve görünürlük yetkisi

En pahalı hata sınıfı erişim kontrolüdür, çünkü sessiz kalır. Tea uygulamasında AI'ın ürettiği hatalı yetkilendirme mantığı kullanıcıların özel mesajlarını başka kullanıcılara açık bıraktı. Lovable'da Kasım 2025'ten önce oluşturulan her proje 48 gün boyunca açıktaydı; ücretsiz bir hesap başka kullanıcının kaynak kodunu, veritabanı kimlik bilgilerini ve müşteri verisini görebiliyordu. İkisinde de kod çalışıyordu, ekranlar doğru görünüyordu, sorun testte görünmeyen bir yerdeydi: bir kullanıcının kendi kimliğini değiştirip başkasının kaydına erişip erişemediği. Denetimde her uç noktayı, kimin hangi kaydı görebildiğini elle deneyerek kontrol ediyoruz, otomatik tarayıcı bunu tek başına yakalamıyor.

Sır ve kimlik bilgisi sızıntıları

AI destekli commit'ler, insan yazımı koda göre iki kat daha sık sır sızdırıyor: API anahtarı, veritabanı parolası, üçüncü taraf token'ı doğrudan koda ya da Replit'in ortam dosyasına gömülü kalıyor. Model bunu kötü niyetle yapmıyor, çalışan bir örnek üretmek için en kısa yolu seçiyor ve en kısa yol genelde sırrı düz metin olarak yazmak oluyor. Denetim bu taramayı kod tabanının tamamında, geçmiş commit'ler dahil yapıyor; bir sır bir kez tarihe girdiyse yalnızca ortam dosyasından silmek yetmiyor, anahtarın kendisinin döndürülmesi gerekiyor.

Bağımlılıklar ve halüsinasyon paketleri

Modellere kod yazdırıldığında önerilen paketlerin ortalama beşte biri gerçekte var olmuyor; bu paket adları rastgele değil, aynı istem tekrar çalıştırıldığında yüksek oranda aynı çıkıyor. Bu öngörülebilirlik yeni bir saldırı sınıfı doğurdu: slopsquatting. Saldırgan halüsinasyon paket adını gerçek bir pakete kayıt ettirip içine zararlı kod koyuyor, model o adı önerdiği için geliştirici fark etmeden kurulum yapıyor. Denetimde bağımlılık listesindeki her paketin gerçekten var olup olmadığı, indirme sayısının ve bakım geçmişinin makul olup olmadığı kontrol ediliyor.

Girdi doğrulama ve enjeksiyon sınıfı hatalar

Aynı Veracode raporunda test edilen kodun yüzde 86'sı, kullanıcıdan gelen bir girdinin doğrudan sayfaya yazılıp tarayıcıda çalıştırılabilir hale gelmesi anlamına gelen XSS saldırılarına karşı savunmasız çıktı; yüzde 88'i ise sunucu kayıtlarına denetimsiz veri yazılmasından doğan log enjeksiyonuna açıktı. İkisi de aynı kökten geliyor: kullanıcıdan gelen veri, ekrana yazılmadan ya da bir sorguya eklenmeden önce temizlenmiyor. Modelin ürettiği kod çoğu zaman beklenen kullanım için doğru çalışıyor, kötü niyetli girdiyle karşılaştığında değil. Denetimde her kullanıcı girdisinin nereye gittiği izleniyor: ekrana mı yazılıyor, bir sorguya mı ekleniyor, bir dosya yoluna mı dönüşüyor ve o noktada doğrulama var mı yok mu. Tek bir doğrulanmamış alan bile, o alanı besleyen her ekran ve her API uç noktası için ayrı bir risk taşır.

Düzeltme ve kalıcı koruma

Bulma işi düzeltmeden ayrı satılmaz; ikisi birlikte gelir, çünkü bir bulgu listesi tek başına hiçbir kullanıcıyı korumaz. Düzeltme kapsamı yalnızca güvenlik açıklarıyla sınırlı kalmıyor: yarım kalmış bir ödeme entegrasyonunu tamamlamak, kimlik doğrulama akışını bitirmek ya da AI çağrılarına harcama ve oran sınırı koymak da aynı pakette ilerliyor.

Düzeltme: rapor değil, birleştirilebilir kod

Bulgu listesi teslim ettikten sonra işi bırakmıyoruz. Her bulgu için düzeltme, değişikliği gözden geçirip onaylamanızı sağlayan ayrı bir pull request halinde geliyor: değişen dosyalar, gerekçe ve düzeltmeden önce açığı gösteren bir test aynı pakette yer alıyor. Öncelik ciddiyet ve kullanıcı verisine yakınlığa göre sıralanıyor; üretim ortamında kişisel veri sızdıran bir erişim hatası, ölçümü etkilemeyen bir yapılandırma sorunundan önce kapatılıyor. Ekibinizin kod tabanını okuyan yeni bir yazılımcı gibi çalışıyoruz, kendi tercihimizi dayatmıyoruz; mevcut mimariye uyan en küçük değişikliği yapıyoruz.

CI/CD'ye gömülü güvenlik kapısı

Düzeltme kalıcı değildir, çünkü AI aracınız yarın aynı hatayı yeniden üretebilir. Bu yüzden son adım statik analiz, bağımlılık taraması ve sır taramasını yayın hattınıza gömmek: her pull request otomatik taranıyor, kritik bulgu varsa birleştirme durduruluyor. Kapı, değişikliği kim gönderirse göndersin aynı şekilde çalışıyor; siz elle yazmış olun ya da bir AI agent commit atmış olsun, fark etmiyor. Bu kapı halihazırda bir CI/CD hattınız varsa oraya eklenir; yoksa DevOps ve CI/CD hizmetiyle birlikte kurulur. Kapı kurulduktan sonra aynı sınıf hata artık üretime hiç ulaşmıyor, siz bu hizmete bir daha ihtiyaç duymadan kendi ekibiniz sürdürebiliyor.

Kapsam nasıl belirleniyor

Kapsam, kapsam görüşmesinde yazılı olarak netleşiyor: hangi depo, hangi ortam, hangi entegrasyonlar dahil. Kodun hangi AI aracıyla üretilmiş olması denetimin kapsamını değiştirmiyor; hepsi aynı süreçten geçiyor. Denetim o anki bilgiyle bulunabilecek bilinen hata sınıflarını tarıyor ve taranan her sınıf ya bir düzeltmeyle ya da bilinçli kabul edilmiş bir risk notuyla kapanıyor. Mimari bir karar, örneğin tüm veri modelinin yeniden tasarlanması, bu denetimin doğal sınırının dışında kalıyor; böyle bir ihtiyaç çıkarsa iş Backend Ölçekleme ya da CTO as a Service tarafına yönleniyor. Bu netlik baştan kurulduğu için hem sizin hem bizim ne aldığımız görüşmenin ilk gününden itibaren açık oluyor.

İlk tarama bulguları

Vibe-code edilmiş bir uygulamanın ilk taramasında, kod hangi araçla üretilmiş olursa olsun neredeyse hep aynı üç şey çıkıyor: kimlik doğrulaması olmadan erişilebilen bir yönetim ekranı, koda gömülü en az bir API anahtarı ve düzgün doğrulanmamış en az bir kullanıcı girdisi. Mayıs 2026'da halka açık beş binden fazla vibe-code uygulamanın tarandığı bağımsız bir araştırmada bunların yaklaşık yüzde 40'ı tıbbi ya da finansal veri gibi hassas bilgiyi açık bırakıyordu, iki binden fazla kurumsal uygulamada hiç erişim kontrolü yoktu. Bu üç bulgu birlikte çıktığında aradaki bağlantı genelde aynıdır: hız uğruna atlanmış ve sonradan hiç geri dönülüp kapatılmamış bir adım. Kendi tarafımızda da aynı disiplini uyguluyoruz: bu site dahil ürettiğimiz her kod, izin verilen etiket listesini aşan hiçbir HTML'i geçirmeyen bir sanitizasyon katmanından ve otomatik bir ön-commit denetiminden geçiyor. Sattığımız yöntemi kendi üretimimize uygulamayan bir hizmeti önermeyiz.

Süreç: ilk temastan teslim edilen koda

Süreç dört adımdan oluşuyor. İlk adım kısa bir kapsam görüşmesiyle başlıyor: hangi depo, hangi ortamlar ve hangi entegrasyonlar kapsama giriyor, bu görüşmede netleşiyor. Ardından denetim geliyor ve genelde üç ila beş iş günü sürüyor; sonunda ciddiyete göre sıralanmış, tek başına da alınabilecek yazılı bir bulgu listesi teslim ediliyor. Üçüncü adımda düzeltme başlıyor; süresi kapsanan bulgu sayısına göre değişiyor ve her düzeltme ayrı bir pull request olarak geliyor. Son adım ise CI/CD kapısının kurulumu ve ekibinizle birlikte yapılan bir deneme çalıştırması oluyor. Süreç bir devir belgesiyle kapanıyor: hangi kontrolün ne aradığı, alarm çaldığında ne yapılacağı ve kapıyı ekibinizin nasıl güncelleyeceği burada yazılı olarak teslim ediliyor.