Hızlı cevap: Güvenilir bir yapay zeka pentest raporunun temelinde tek bir ayrım yatar: tespit, doğrulama değildir. Bir tarayıcının "burada SQL enjeksiyonu olabilir" demesi bir hipotezdir, bir iddiadır. Aynı bulguya "doğrulandı" diyebilmek için bağımsız bir kanıt gerekir: zamana dayalı SQL enjeksiyonunda ölçülmüş gecikme, XSS'te gönderilen script'in ham olarak sayfaya yansıması, istek ile yanıtın kaydı. Kanıt temelli bir rapor her bulguyu bir karara (doğrulandı, olası, hipotez), bir kanıta, bir önem derecesine, bir çözüm önerisine ve bir yanlış pozitif notuna bağlar. Kanıtsız kesinlik yasaktır ve "doğrulanamadı" demek, abartılı bir "kritik açık" iddiasından çok daha değerlidir.

Bir pentest raporunu değerli kılan şey bulunan açık sayısı değildir. Rapordaki her cümlenin arkasında durabilmektir. Müşteri raporu açtığında "kritik" yazan bir satır görür ve ekibini, mesaisini, bütçesini o satıra göre yönlendirir. Eğer o satır gerçek bir kanıta değil bir tarayıcının tahminine dayanıyorsa, müşteri boşa koşturur, gerçek açık ise listenin altında gözden kaçar. Yapay zeka destekli tarama bu riski hem azaltır hem de büyütür: doğru kurgulandığında insandan hızlı ve tutarlı doğrulama yapar, yanlış kurgulandığında ise yüzlerce "olabilir" cümlesini saniyeler içinde "kritik" gibi sunar. Bu yazı, bir yapay zeka pentest raporunun neden kanıt temelli olmak zorunda olduğunu ve bir bulguya ne zaman "doğrulandı" denebileceğini anlatıyor.

Tespit ile doğrulama arasındaki fark

Tespit, bir sistemin belirli bir açığa sahip olabileceğine dair bir sinyaldir. Tarayıcı bir parametreye tek tırnak gönderir, dönen yanıtta bir veritabanı hata mesajı görür ve "burada SQL enjeksiyonu olabilir" der. Bu doğru bir başlangıçtır ama bitmiş bir iş değildir. Çünkü aynı hata mesajı, girdiyi veritabanına hiç göndermeyen bir hata yakalayıcıdan da gelebilir, ya da sayfa her koşulda o mesajı basıyor olabilir. Sinyal gerçektir, sonuç belirsizdir.

Doğrulama ise bu sinyali bağımsız bir kanıta dönüştürmektir. Zamana dayalı kör SQL enjeksiyonunda yöntem nettir: sorguya ölçülebilir bir gecikme enjekte edersiniz, isteğin yanıt süresini ölçersiniz, bir kontrol isteğiyle karşılaştırırsınız. Normal istek 120 milisaniyede dönerken enjekte edilmiş istek tutarlı biçimde 5 saniyede dönüyorsa, elinizde artık bir tahmin değil tekrarlanabilir bir ölçüm vardır. Yansıyan XSS'te kanıt, gönderdiğiniz script'in sayfada kodlanmadan, ham ve yürütülebilir biçimde geri dönmesidir. SSRF'te kanıt, kontrolünüzdeki bir sunucuya hedeften gelen isteğin kaydıdır.

Fark tek cümleyle şudur: tespit "şüpheleniyorum" der, doğrulama "ölçtüm, işte kanıt" der. Geleneksel tarayıcı ile yapay zeka destekli yaklaşımın ayrıldığı nokta tam da burasıdır. Bu ayrımı yapay zeka destekli zafiyet taraması ile geleneksel tarayıcı farkı yazımızda ayrıntılı ele alıyoruz.

Bir bulguya ne zaman "doğrulandı" denir

Bir bulgu, ancak açığın gerçekten tetiklenebildiğini gösteren bağımsız ve tekrarlanabilir bir kanıt varsa "doğrulandı" sayılır. Tek bir sinyal, tek bir hata mesajı, tek bir sürüm eşleşmesi bunun için yeterli değildir. Pratikte üç karar seviyesi işi dürüst tutar ve okuyucuya her bulgunun ne kadar kesin olduğunu tek kelimeyle söyler.

Karar Anlamı Gereken kanıt Örnek
Doğrulandı Açık fiilen tetiklendi Bağımsız ve tekrarlanabilir kanıt (ölçülmüş gecikme, ham yansıma, dışarı sızan istek) Enjekte edilen 5 saniyelik gecikme tutarlı ölçüldü
Olası Güçlü belirti var ama tetiklenemedi Dolaylı kanıt, kısmi davranış, güvenli ortamda teyit mümkün olmadı Hata mesajı sızıyor ama WAF enjeksiyonu kesiyor
Hipotez Yalnızca sinyal ya da eşleşme Sadece sürüm, başlık veya imza eşleşmesi "Server: nginx 1.18" sürüm eşleşmesi

Doğrulandı demek için kanıt, üçüncü bir kişi tarafından aynı adımlarla yeniden üretilebilmelidir. Sürüm eşleşmesi tek başına hipotezdir, çünkü dağıtım geriye taşınmış (backport) bir yama içeriyor olabilir. Bu karar seviyelerini ölçülebilir ve denetlenebilir kılmanın yolları, bir güvenlik yapay zekası nasıl ölçülür: benchmark, halüsinasyon, kanıt replay yazımızda daha derinlemesine duruyor.

Kanıt temelli raporun öğeleri

Kanıt temelli bir raporda her bulgu aynı beş öğeyle gelir. Eksik öğe, eksik bulgudur.

Birincisi karardır: doğrulandı, olası ya da hipotez. Okuyucu tek kelimeyle bulgunun ağırlığını anlamalıdır. İkincisi kanıt ya da kavram kanıtıdır (PoC): zamana dayalı enjeksiyonda ölçüm tablosu, XSS'te yansıyan yük ve ekran görüntüsü, her durumda ham istek ve yanıt. Kanıt, raporu açan kişinin kendi başına yeniden üretebileceği kadar somut olmalıdır. PoC üretiminin etiği ve sorumlu açıklama çerçevesi için exploit geliştirme, PoC etiği ve sorumlu açıklama yazımıza bakın.

Üçüncüsü önem derecesidir. CVSS gibi bir çerçeveyle verilir ama bağlamla düzeltilir: internete açık ve kimlik doğrulaması istemeyen bir uç, aynı açığın iç ağdaki bir kopyasından daha ağırdır. Dördüncüsü çözüm önerisidir (remediation): "girdiyi doğrula" gibi genel bir cümle değil, o teknolojiye özel ve uygulanabilir bir adım. Beşincisi yanlış pozitif notudur: bulgunun hangi koşulda yanlış olabileceği, hangi varsayımlara dayandığı. Bu not, raporu yazanın dürüstlüğünün ölçüsüdür. Kanıt, PoC ve çözümü tek bir disiplinde birleştiren örnek akış için doğrulanmış zafiyet, yanlış pozitifsiz güvenlik testi, PoC ve remediation yazımız iyi bir başvurudur.

İyi rapor ile kötü rapor: karşılaştırma

Aynı taramanın iki rapora dönüşebileceğini görmek, farkı en net anlatan yoldur.

Ölçüt Kötü rapor İyi rapor
Dil "SQLi bulundu, kritik" "Zamana dayalı SQLi doğrulandı, 5 saniyelik gecikme ölçüldü"
Kanıt Tarayıcının ekran çıktısı Tekrarlanabilir istek, yanıt ve ölçüm
Önem Tarayıcının verdiği hazır etiket Bağlamla düzeltilmiş, gerekçeli skor
Belirsizlik Gizlenir, her şey "kritik" olur Açıkça belirtilir, karar seviyesi verilir
Yanlış pozitif Hiç konuşulmaz Her bulguda ayrı not
Önceliklendirme Uzun, ayrımsız liste Önce doğrulanmış ve etkili olanlar

Kötü rapor müşteriyi boğar: yüzlerce satır, hepsi "kritik", hiçbiri kanıtlı. İyi rapor müşteriye bir yol haritası verir: önce şu üç doğrulanmış açık, çünkü işte ölçülebilir kanıtları.

Aşırı iddia (over-claim) neden tehlikeli

Aşırı iddia, kanıtı olmayan bir bulguyu "doğrulandı" ya da "kritik" diye sunmaktır. İki ağır zararı vardır.

Birincisi güven kaybıdır. Müşteri "kritik SQL enjeksiyonu" raporunu alır, ekibini seferber eder, sonra açığın aslında sömürülemez olduğunu görür. Bu bir kez yaşandığında rapordaki diğer gerçek bulgular da inandırıcılığını yitirir. Bir güvenlik raporunun tek gerçek sermayesi güvenilirliğidir ve bu sermaye bir kere harcanınca geri gelmez.

İkincisi yanlış önceliklendirmedir. Sınırlı mesai ve bütçe abartılmış bir bulguya akar, gerçekten sömürülebilir ama sade görünen bir açık ise beklemeye alınır. Gürültü, gerçek sinyali gömer. Bir tarayıcı yüzlerce "olabilir" ürettiğinde bunları eleyip önceliklendirmek başlı başına bir iştir ve bunu yapay zeka taramasında aşırı üretim, gürültü ve bulgu önceliklendirme yazımızda ele alıyoruz. Bir yapay zekanın, bir bulguyu neden öyle sınıflandığını gösterebilmesi de bu güvenin parçasıdır. Kararın arkasındaki kanıt zinciri görünür olmalıdır, bu konuyu açıklanabilir yapay zeka güvenlikte neden kritik yazımızda tartışıyoruz.

Dürüstlük: "doğrulanamadı" demek meşrudur

Kanıt temelli raporlamanın en çok yanlış anlaşılan yanı budur: "doğrulanamadı" demek bir başarısızlık değil, bir dürüstlük ifadesidir. Bir pentest sonunda tek bir bulgu için üç dürüst sonuç olabilir: doğrulandı (kanıt var), doğrulanamadı (yetki, zaman ya da ortam kanıtı mümkün kılmadı) ve güvenli (test edildi, açık bulunamadı). Üçü de meşru sonuçlardır ve her biri raporda açıkça yer alabilir.

Yasak olan tek şey kanıtsız kesinliktir. "Doğrulayamadık ama büyük ihtimalle açıktır, kritik yazalım" cümlesi raporu çürütür. Doğru dil şudur: "Şu belirti görüldü, şu nedenle güvenli ortamda tetiklenemedi, yetkili bir tekrar testi önerilir." Bu cümle hem müşteriyi yanıltmaz hem de gerçek riski saklamaz. Sınır her zaman aynıdır: yetki ve kapsam içinde kal, ölçemediğin şeyi "ölçtüm" diye yazma.

KAOS ve DSET yaklaşımı

DSET'in yerel yapay zeka motoru KAOS, raporlamayı bu ayrım üzerine kurar: önce tespit, sonra bağımsız doğrulama. Bir açık sinyali yakalandığında KAOS bunu bir hipotez olarak işaretler, ardından güvenli ve yetkili sınırlar içinde tetiklemeye çalışır. Zamana dayalı enjeksiyonda gecikmeyi ölçer ve kontrol isteğiyle karşılaştırır, yansıyan XSS'te yükün ham olarak döndüğünü teyit eder. Yalnızca bu bağımsız kanıt elde edildiğinde bir bulgu "doğrulandı" seviyesine çıkar.

KAOS'un bir aşırı iddia freni (over-claim brake) vardır: kanıt yoksa bulgu "hipotez" ya da "olası" seviyesinde kalır, asla "doğrulandı" diye raporlanmaz. Sürüm eşleşmeleri "etkilenebilir" diye geçer, "kesin açık" denmez. Her bulgu; kanıtı, önem gerekçesi, çözüm önerisi ve yanlış pozitif notuyla birlikte sunulur. Amaç bulgu sayısını şişirmek değil, müşterinin güvenerek aksiyon alabileceği bir karar listesi vermektir. KAOS'un tarama yaklaşımının bütününü KAOS yapay zeka siber güvenlik tarama aracı sayfasında inceleyebilirsiniz.

Sık sorulan sorular

Bir tarayıcı "kritik SQL enjeksiyonu buldu" diyorsa bu doğrulanmış değil midir? Hayır. Tarayıcının çıktısı bir tespittir, yani bir hipotezdir. Doğrulanmış sayılması için açığın fiilen tetiklenebildiğini gösteren bağımsız ve tekrarlanabilir bir kanıt gerekir, örneğin zamana dayalı enjeksiyonda enjekte edilen gecikmenin tutarlı biçimde ölçülmesi. O ölçüm yoksa bulgu "olası" ya da "hipotez" seviyesindedir ve raporda öyle gösterilmelidir. Tarayıcının etiketi, doğrulama kanıtının yerini tutmaz.

Kanıt temelli bir raporda her bulguda ne bulunmalı? Beş öğe bulunmalıdır: karar (doğrulandı, olası ya da hipotez), kanıt ya da kavram kanıtı (PoC), bağlamla düzeltilmiş önem derecesi, uygulanabilir bir çözüm önerisi ve yanlış pozitif notu. Kanıt, raporu okuyanın kendi başına yeniden üretebileceği kadar somut olmalıdır. Bu beş öğe bir arada bulunduğunda okuyucu hem neye öncelik vereceğini hem de bulgunun ne kadar kesin olduğunu tek bakışta anlar.

"Doğrulanamadı" yazmak raporu zayıf göstermez mi? Tam tersine güçlendirir. "Doğrulanamadı" dürüst bir sonuçtur ve genelde somut bir nedeni vardır: yetki sınırı, zaman kısıtı ya da güvenli ortamda tetiklemenin mümkün olmaması. Bunu açıkça yazmak, kanıtı olmayan bir bulguyu "kritik" diye sunmaktan çok daha değerlidir, çünkü kanıtsız kesinlik bir kez çürüdüğünde raporun tamamı güvenilirliğini yitirir. Dürüst bir "doğrulanamadı", yanında yetkili bir tekrar testi önerisiyle sunulur.

Kaynaklar

Raporunuzun her satırının arkasında ölçülebilir bir kanıt olmasını istiyorsanız DSET ile iletişime geçin. Ekibimiz Ankara Hacettepe Teknokent merkezinden, kanıt temelli sızma testi ve raporlama hizmeti verir.