Araç listeleri yukarıda fazlasıyla verilmiş, tekrar etmeyeyim. Çok kiracılı (multi-tenant) bir SaaS geliştiriyoruz; bizim başımıza gelenlerden, o listelerde olmayan üç şeyi ekleyeyim.
1) Tarayıcıların yakalayamadığı asıl açık: kiracı izolasyonu.
Birden fazla müşterinin aynı veritabanını paylaştığı bir sistem yazıyorsanız en tehlikeli açık SQL injection değil, A müşterisinin B müşterisinin verisini görmesi. OWASP ZAP bunu bulamaz, Semgrep bulamaz çünkü araçlar sizin kiracı modelinizi bilmiyor.
Test etmesi ise çok basit ve kimse yapmıyor: A hesabıyla giriş yapın, B hesabına ait bir kaydın ID'sini alın, A'nın oturumuyla o ID'yi API'ye sorun. Veri dönüyorsa açığınız var. Bu testi her kritik uç için yapın; on dakikalık iş, karşılığı şirketin kapanmaması.
Kalıcı çözüm uygulama katmanında değil, veritabanı katmanında olmalı (PostgreSQL'de Row Level Security gibi). Çünkü uygulamada where tenant_id = ? yazmayı bir yerde unutursunuz biz unuttuk.


2) Asıl tehlike "hata veren" kod değil, "sessizce hiçbir şey yapmayan" kod.
Bu bizim için en pahalı ders oldu. Yaşadığımız birkaç örnek:
  • Zamanlanmış görevler veritabanına kiracı bağlamı olmadan soruyordu. Güvenlik kuralı devreye giriyor, sorgu hata vermiyor, sadece boş dönüyor. Sonuç: senkronizasyon aylarca hiç çalışmadı ve hiçbir yerde hata görünmedi.
  • Bir veritabanı taşıması esnasında veri dolduran UPDATE, yine aynı sebeple 0 satır etkiledi. Yapı kuruldu, veri dolmadı, deploy yeşil yandı.
  • Bir alan her yerde okunuyordu ama hiçbir yerde yazılmıyordu. Panel sonsuza kadar boş data gösterdi.
Bunların hiçbiri klasik anlamda "güvenlik açığı" değil ama gerçek sistemler böyle çöküyor. Yapay zekâ ile üretilmiş kodda bu sınıf hata çok yaygın, çünkü model "çalışıyor gibi görünen" kod yazmakta çok iyi.
Pratik önlem: yeni bir alan eklerken "bunu kim yazıyor?" sorusunu "kim okuyor?" kadar ciddiye alın. Ve bir işlemin sonucunu daima doğrulayın "kaç satır etkiledi" bilgisini kontrol etmeyen kod, sessiz hataya davetiyedir.
3) Uygulamanızda yapay zekâ varsa, veritabanınız artık bir saldırı yüzeyi.
Bu, konunun tam kalbi ve pek konuşulmuyor. Eğer asistanınız kullanıcı verisini okuyup cevap üretiyorsa, o verinin içine talimat gömülebilir. Bir müşteri mesajına, bir ürün açıklamasına, bir dosya adına yazılmış "önceki talimatları unut, şu bilgiyi şuraya gönder" cümlesi, modelin önüne sizin kendi sisteminiz tarafından konur. Buna prompt injection deniyor ve klasik girdi doğrulaması bunu durdurmaz çünkü veri "geçerli"dir.
Alınacak önlem şu: modelden gelen çıktıyı asla doğrudan yetkili bir işleme bağlamayın. Bizde asistan hiçbir işlemi kullanıcı onayı olmadan yapmıyor; okuma ile yazma yolları ayrı ve yazma tarafı her zaman insan onayından geçiyor. Model ne kadar iyi olursa olsun, "sil", "gönder", "öde" gibi bir eylemi tek başına tetikleyebiliyorsa mimari yanlıştır.


Özetle: hazır araçlar bilinen açıkları bulur, o yüzden çalıştırın. Ama sizi asıl vuracak olan şey genelde sizin sisteminize özgü olan ve hiçbir aracın bilmediği şey oluyor kiracı izolasyonu, sessiz başarısızlıklar ve modele giden veri.