Yapay Zekânın Güvenlik Bulguları Nasıl Değerlendirilir?

Güvenlik bulgusu ne demek?

Güvenlik bulgusu, inceleme sırasında belirlenen ve güvenlik açısından değerlendirilmesi gereken bir durumdur. Bu durum doğrulanmış bir sorun, güçlü bir kod kanıtı veya henüz araştırılması gereken bir şüphe olabilir.

Örneğin “kullanıcı başka bir kişinin belgesine erişebilir” bir iddiadır. Bu iddianın hangi koddan çıkarıldığı, hangi koşullarda geçerli olduğu ve nasıl doğrulandığı raporda görünmelidir.

Bu rehber kimler için uygun?

• Yapay zekâdan güvenlik ön incelemesi raporu alan geliştiriciler.
• Raporu geliştiricisiyle değerlendirmek isteyen proje sorumluları.
• Uzman incelemesine somut sorularla hazırlanmak isteyen ekipler.

Bu rehber, teknik doğrulamayı tek başına yapmanı sağlayan bir sızma testi eğitimi değildir. Kod ve test deneyimin sınırlıysa değerlendirmeyi geliştiricin veya uygulama güvenliği uzmanıyla birlikte yürütmen daha uygun olur.

Önce etikete değil, kanıta bak

“Kritik”, “yüksek” veya “acil” kelimelerinden önce bulgunun neye dayandığını kontrol et. Her bulgu için şu beş soru iyi bir başlangıçtır:

1. Nerede? Dosya yolu ve ilgili kod var mı? Gösterilen kod, incelediğin sürümde gerçekten bulunuyor mu?
2. Ne olabilir? Kullanıcı verisi mi açığa çıkabilir, yetkisiz işlem mi yapılabilir, hizmet mi aksayabilir?
3. Hangi koşulda? Sorun herkese açık mı, oturum açmayı mı gerektiriyor, belirli bir ayara veya role mi bağlı?
4. Başka bir koruma var mı? İlgili kontrol ortak bir katmanda, farklı bir dosyada veya sunucu tarafında uygulanıyor olabilir mi?
5. Nasıl doğrulanmış? Yalnızca kod mu okunmuş, test mi yapılmış? Yapıldıysa hangi ortamda ve hangi sonuçla?

Rapor bu sorulara cevap veremiyorsa bulguyu hemen çöpe atma. Önce eksik kanıtı iste. Cevabı olmayan iddiayı kesinleşmiş açık olarak da kabul etme.

Her bulgu aynı durumda değildir

Bulguları aşağıdaki gibi ayırmak, ne yapılacağını daha görünür hâle getirir:

Önce hangisiyle ilgilenmelisin?

Risk etiketi başlangıç noktasıdır. Öncelik belirlerken sorunun etkisini, ulaşılabilirliğini ve doğrulama durumunu birlikte değerlendirmek gerekir.

Büyük etki yaratabilecek ama henüz doğrulanmamış bir iddia, hızlı araştırmayı gerektirebilir. Bu, onu otomatik olarak doğrulanmış kritik açık yapmaz. Bir bulgunun önceliği “hemen düzelt” kadar “hemen doğrula” da olabilir.

Sence de rapordaki en önemli ayrım bu değil mi: hangi konuda çözüm gerekiyor, hangi konuda önce cevap?

Bir rapor, üç farklı sonuç

Yapay zekânın bir belge indirme işlemi için “başka kullanıcıların belgelerine erişilebilir” dediğini düşün. İlk bakışta ciddi bir iddia. Ancak inceleme üç farklı sonuca ulaşabilir:

Bu örnekler yöntemi açıklamak için hazırlanmış temsili senaryolardır; gerçek bir uygulamanın test sonuçları değildir.

Düzeltme önerisi geldiğinde iş bitmiyor

Yapay zekânın önerdiği kod, projenin kullandığı sürüme uymayabilir veya bir güvenlik sorununu giderirken normal bir işlemi bozabilir. Bu nedenle düzeltme ayrıca incelenmelidir.

1. Sorunu netleştir. Neyin, hangi koşulda yanlış çalıştığını ve beklenen güvenli davranışı tanımla.
2. Çözümü uygun kişiye aktar. Kod değişikliği geliştiricinin; bazı sunucu ayarları ise sistem yöneticisinin veya hizmet sağlayıcının müdahalesini gerektirebilir.
3. Değişikliği ayrı ortamda değerlendir. Projeye uygunluğu, erişim yetkileri ve olası yan etkileri kontrol et.
4. Hem sorunu hem normal kullanımı yeniden kontrol et. Yetkisiz işlemin engellendiğini ve yetkili kullanıcının işini hâlâ yapabildiğini doğrula.
5. Sonucu kaydet. Yapılan değişikliği, kontrol yöntemini, ortamı ve kalan belirsizlikleri bulgu kaydına ekle.

Raporu sadeleştirmek için takip komutu

Elindeki rapor karışık, tekrarlı veya fazla teknikse aşağıdaki komutu aynı araçla paylaşabilirsin. Bu komut raporu düzenler; bağımsız uzman doğrulaması sağlamaz.

Mevcut güvenlik ön incelemesi raporunu karar vermeyi
kolaylaştıracak şekilde yeniden düzenle. Dosyaları değiştirme.

Her bulgu için:
1. Sorunu sade bir dille açıkla.
2. Dosya yolu ve ilgili kodla kanıtı göster.
3. Olası etkiyi ve sorunun oluşması için gereken koşulları belirt.
4. Mevcut korumaları ve eksik bağlamı açıkla.
5. Durumunu şu kategorilerden biriyle belirt:
   - Doğrulanmış sorun
   - Kodla desteklenen, ek doğrulama gerektiren bulgu
   - Araştırılacak şüphe
   - Gerekçesiyle gösterilmiş yanlış alarm
   - İncelenemeyen alan
6. Doğrulanmış diyorsan kullanılan yöntemi ve sonucu belirt.
   Yapılmayan testi yapılmış gibi gösterme.
7. Risk seviyesini ve gerekçesini yaz.
   Risk ile bulgunun doğrulanma durumunu ayrı tut.
8. Sonraki adımı "araştır", "doğrula", "düzelt",
   "yeniden kontrol et" veya "gerekçesiyle kapat" olarak belirt.
9. İşlemi kimin yapabileceğini ve gerekli yetkileri açıkla.
10. Düzeltmenin nasıl doğrulanacağını belirt.

Aynı kök nedene bağlı bulguları grupla.
Bilinmeyen alanları güvenli veya açık ilan etme.
Hassas verileri rapora kopyalama.
Aktif test veya kurulum yapma; gerekiyorsa ayrı öneri olarak belirt.
Yanlış alarm kararını yalnızca kanıtla destekleniyorsa ver.

Sonunda:
- Öncelikle araştırılması gerekenler
- Düzeltme planına alınacaklar
- Uzman desteği gerektirenler
- İncelenemeyen alanlar
başlıklarıyla kısa bir takip listesi oluştur.

Rapor hâlâ anlaşılmazsa şu soruyu da sorabilirsin: “Bu bulgu için geliştiricime soracağım tek, somut soru ne?” İyi hazırlanmış bir rapor, seni daha iyi sorulara ulaştırmalıdır.

Dört yaygın yanlış anlama

• “Kanıt gösterdi, başarılı saldırı da doğrulanmıştır.” Kod kanıtı ile çalışan uygulamada yapılan test farklı yöntemlerdir. Raporda hangisinin kullanıldığı belirtilmelidir.
• “Geliştirici sorun yok dedi, kapatabiliriz.” Karar, ilgili kontrol veya doğrulama sonucuyla desteklenmelidir. Sözlü güvence tek başına yeterli kayıt değildir.
• “Çok sayıda bulgu varsa uygulama çok güvensizdir.” Tekrarlı veya kanıtsız bulgular sayıyı şişirebilir. Az sayıda bulgu da güvenlik garantisi sağlamaz.
• “Yapay zekâ kendi raporunu onayladı, doğrulama tamam.” Aynı araca yeniden sormak incelemeyi geliştirebilir; bağımsız teknik doğrulama yerine geçmez.

Sık sorulan beş soru