Yapay Zeka İçin Bug Bounty: Hackerları Savunmaya Dahil Etmek

Geleneksel web sitenizi korumak için Sızma Testi (Pentest) harika bir başlangıçtır, ancak bir yıl süren yapay zeka devriminde statik güvenlik kavramı artık geçerliliğini yitirmiştir. Hackerların motivasyonlarıyla aynı hizada olmayan kurumsal savunmalar genellikle başarısızlığa mahkûmdur. Şirketinizin Müşteri Hizmetleri AI botunu veya kendi bünyenizde çalıştırdığınız "Kurumsal LLM" (RAG) mimarisini gerçekten güvence altına almanın en modern yolu, Kalabalığın Gücünden (Crowdsourced Security) faydalanmak, yani bir Bug Bounty (Ödül Avcılığı) programı başlatmaktır.

Ancak, yapay zeka sistemlerine yönelik Bug Bounty programları klasik (Örn: XSS bulduğunda para ödenen) sistemlerden çok farklı işler.

---

1. Neden Yapay Zeka (AI) Odaklı Bug Bounty?

Yapay zeka modellerinin girdileri (Input) sadece kelimelerden oluşur. Geleneksel güvenlik duvarları (WAF) veya otomatik zaaf tarayıcılar, bir LLM'in manipüle edildiğini anlayamaz. Bir yapay zekayı kandırmak (Jailbreaking veya Prompt Injection yaratmak) son derece "insansı" bir yaratıcılık gerektirir.

Dünya genelinde on binlerce beyaz şapkalı hacker, kelime cambazlığında, hipotetik senaryo kurgularında ve saldırgan istem mühendisliğinde (Adversarial Prompting) ustalaşmıştır. Google ve OpenAI gibi firmalar kendi amiral gemisi modellerini canlıya almadan önce devasa "Red Teaming" etkinlikleri (Hackathon'lar) düzenleyerek tüm açıkları dışarıdan gelen sivillere paralı olarak test ettirmektedir. İşletmeniz de inovasyonda siber güvenlik adımlarını dışarıdaki bu kolektif zeka ile perçinlemelidir.

---

2. AI Bug Bounty Süreçlerinde Neler Ödüllendirilir?

Klasik bir Bug Bounty programında SQL harfleri, dizin geçişi (Path Traversal) hataları aranır. AI dünyasında ise avcılar tamamen farklı, algoritmik hedeflerin peşindedir:

A. Modelin Şifre veya Veri Sızdırması (Model Inversion)

Etik hacker, şirket asistanınızı saatlerce sıkıştırarak sadece kendi yazdığı yetki dâhilindeki cevaplara değil; arka planda asistanın bağlı olduğu Vektör Veritabanı'ndaki diğer çalışanların maaşlarına veya AWS konfigürasyon veri tabanlarına ulaşmaya çalışır.

B. Otonom Eylemleri Tetikleme (Excessive Agency)

Şirket asistanınız eğer otonom işlemler (Plugins) yapabiliyorsa (Örneğin: şirketin iç e-posta sistemindeki şifreleri sıfırlayabilme vb.), hacker modeli kandırarak kendisi adına veritabanı yedeğini indirmesini ve bunu internete yollamasını isteyebilir. Başarılı bir "Yetki Aşımı" zafiyeti, çok yüksek kritiklikte (Critical / P1) sınıflandırılır.

C. Telif Hakkı ve Zehirli (Toxic) Halüsinasyonlar

Avcılar modeli kışkırtarak, rakip şirketin itibarını zedeleyecek küfürlü veya yasadışı yanıtlar verdirtmeye (Toxicity) veya lisanslı bir kitap içinden sayfa sayfa (Copyright Infringement) veri kusmasına sebep olacak açıklar bulur. Marka zedelenmesi riskleri, yapay zeka ürünleri için inanılmaz pahalı sonuçlar doğurur.

---

3. Kurumlar Bu Programı Nasıl Kurgulamalı?

İşletmenizdeki yapay zeka araçları için bir Zafiyet Ödül Programı açmadan önce Eresus Security Research veya benzeri danışmanlıklarla altyapıyı sağlamlaştırmanız gerekir:

1. Katı Kurallar (Rules of Engagement) Belirleyin: AI hedefleri söz konusu olduğunda neyin "Sistem Hatası (Bug)" neyin "Siber Zaafiyet (Vulnerability)" olduğunu tanımlayın. Yapay zekanın "Eski nesil bir müzisyen" gibi davranması bir zafiyet değil halüsinasyondur; ancak yapay zekanın gizli bir kredi kartı maskelemesini kaldırması bir Zafiyettir. Para ödülünün sadece bilgi sızdıran zafiyetlere verileceğini açıkça sınırlandırın.
2. GPU Kaynaklarınızı (DDoS İçin) Koruyun: Hizmet Reddi (Model DoS) saldırılarını izin verilen testlerin dışında tutun. Hackerlar modelinize test olsun diye saniyede milyonlarca kelime yollarsa, bulut faturalarınız çakılır.
3. Güvenli Bir Sanal Alan (Sandbox) Sunun: Etik hackerların, kurumun gerçek aktif üretim (Production) asistanını kurcalaması yerine onlara test edebilecekleri "Klon" makine ortamları tahsis edin.

Sonuç

Yapay zeka siber güvenliğinde kusursuzluğa ulaşmak statik çözümlerle imkansızdır. Kötü niyetli aktörlerin yapay zekanızla oynamasından (Exploitation) aylar önce, bu zafiyetleri bağımsız siber güvenlik araştırmacılarına ödüller teşvikiyle kırmak; güvenli yarınları bugünden satın almaktır.

Saha Kontrol Notları

Bu başlık pratikte yalnızca teorik risk olarak ele alınmamalıdır. AI sistemlerinde zafiyetin etkisi, modelin bulunduğu ortam ve bağlı olduğu veri kaynaklarıyla birlikte değişir.

İnceleme sırasında şu kanıtlar toplanmalıdır:

• Model veya agent hangi ortamda çalışıyor?
• Hangi kullanıcı veya servis hesabı kullanılıyor?
• Hassas veri kaynakları ayrı etiketlenmiş mi?
• Model dosyası veya artefact kaynağı doğrulanmış mı?
• Yükleme anında kod çalıştırma riski var mı?
• Retrieval sonuçları kullanıcı yetkisine göre filtreleniyor mu?
• Tool çağrıları ayrı loglanıyor mu?
• Kritik aksiyonlarda onay mekanizması var mı?
• Test ortamı production verisinden ayrılmış mı?
• Olay halinde hangi loglardan geri dönüş yapılacak?

Uygulama Kontrol Listesi

• Güvenilmeyen model dosyaları izole ortamda açılmalı.
• Model registry erişimi minimum yetkiyle çalışmalı.
• Hash, imza veya provenance bilgisi tutulmalı.
• Agent tool izinleri görev bazlı ayrılmalı.
• Memory ve retrieval kaynakları ayrı güven sınırı olarak ele alınmalı.
• Prompt testleri runtime aksiyon testleriyle desteklenmeli.
• Her bulgu iş etkisiyle birlikte raporlanmalı.

Karar Noktası

Bu risk müşteri verisine, üretim API’sine, geliştirici ortamına veya model yükleme hattına dokunuyorsa bekletilmemelidir. Eresus Security bu tip incelemelerde dosya, runtime, tool ve veri sınırını birlikte test ederek gerçek saldırı yolunu kanıtlar.

Operasyonel İnceleme Checklisti

• Model veya agent kaynağı doğrulandı mı?
• Tool izinleri minimum yetkiyle mi tanımlandı?
• Retrieval sonucu kullanıcı yetkisine göre filtreleniyor mu?
• Memory kalıcı talimat riskine karşı incelendi mi?
• Model artefact hash veya imza ile takip ediliyor mu?
• Yükleme işlemi sandbox içinde test edildi mi?
• Prompt testi runtime aksiyon testiyle desteklendi mi?
• MCP veya plugin server listesi çıkarıldı mı?
• Agent production API çağırıyorsa onay var mı?
• Veri sızıntısı senaryosu kontrollü denendi mi?
• Kapsam net yazıldı mı?
• Etkilenen varlık sahibi belli mi?
• Test ortamı production etkisinden ayrıldı mı?
• Kullanıcı rolleri doğru temsil ediliyor mu?
• Hassas veri sınıfı tanımlandı mı?
• Yetki sınırı teknik olarak doğrulandı mı?
• Log kaynağı ve saklama süresi belli mi?
• Bulgu tekrar üretilebilir kanıtla destekleniyor mu?
• İş etkisi teknik etkiden ayrı açıklandı mı?
• Düzeltme sahibi belirlendi mi?
• Retest kriteri yazıldı mı?
• Benzer risklerin nerelerde tekrar edebileceği kontrol edildi mi?
• Monitoring veya alert tarafında görünürlük var mı?
• Olay müdahale adımı gerekiyorsa planlandı mı?
• Yönetim özeti teknik jargona boğulmadan hazırlanabilir mi?

Sonraki Teknik Adım

Bu checklist tamamlandıktan sonra bulgular önem sırasına göre backlog’a taşınmalı, kritik riskler için retest planı çıkarılmalı ve ilgili servis/hub sayfasına iç bağlantı verilmelidir. Eresus Security bu aşamada kapsam netleştirme, kanıt üretme ve remediation önceliklendirme konusunda teknik ekiplerle birlikte çalışır.

Ek Kontrol Soruları

• Bu risk hangi varlıkları etkiliyor?
• Hangi kullanıcı rolleri bu akışa erişebiliyor?
• Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
• Bulgunun müşteri verisine etkisi var mı?
• Loglardan olayın izi sürülebiliyor mu?
• Düzeltme sonrası retest nasıl yapılacak?
• Geçici önlem ile kalıcı çözüm ayrıldı mı?
• İş etkisi teknik ekibin dışında da anlaşılır mı?
• Benzer hata için önleyici kontrol eklenebilir mi?
• Ekip bu kontrolü release sürecine bağlayabilir mi?
• Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
• Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?