Sızma Testi (Penetration Test) Raporlaması: Teknik Bulguları Yönetime Nasıl Anlatmalı?

Bir sızma testinin gerçek çıktısı bulunan açıklar değil, o açıkların kapatılmasıdır. Açıkların kapatılması ise bütçe, zaman ve öncelik gerektirir; bunlara karar verenler de çoğunlukla teknik ekip değil, yöneticilerdir. Bu yüzden rapor, bir sızma testinin en az test kadar önemli parçasıdır.

Sahada sık görülen tablo şudur: yüzlerce sayfalık, araç çıktılarıyla dolu bir PDF; ilk sayfada "23 kritik, 41 yüksek bulgu" yazıyor; yönetici neden endişelenmesi gerektiğini, neyin önce yapılacağını ve ne kadar kaynak gerektiğini anlayamıyor. Rapor bir klasöre giriyor ve bir sonraki teste kadar orada kalıyor.

İki okuyucu, iki katman

İyi bir raporun iki farklı okuyucusu vardır ve her birine ayrı bir katman gerekir:

Yönetici özeti nasıl yazılır?

1. Tek cümlelik genel değerlendirme

İlk paragraf, raporun geri kalanını okumayacak kişinin bile anlayacağı net bir yargı içermeli:

İnternetten erişilebilen müşteri portalında, kimliği doğrulanmamış bir saldırganın tüm müşteri kayıtlarına erişmesine izin veren bir açık tespit edilmiştir. Bu açık, bugünkü haliyle kişisel veri ihlaline ve KVKK kapsamında bildirim yükümlülüğüne yol açabilecek niteliktedir.

2. Teknik terimi iş etkisine çevirin

3. Saldırı hikâyesi anlatın

Tek tek bulgular yerine, bulguların nasıl zincirlendiğini gösterin. Yöneticiler, "orta" seviyeli üç açığın birleşince kritik bir sonuç doğurduğunu hikâye olarak çok daha iyi kavrar:

1. Sitedeki şifre sıfırlama sayfası, kayıtlı e-posta adreslerini doğruluyor (düşük).
2. Giriş sayfasında deneme sınırı yok (orta).
3. Yaygın parolalar kabul ediliyor (orta).
4. Sonuç: Saldırgan geçerli kullanıcı listesini çıkarıp yaygın parolaları deneyerek birkaç saat içinde müşteri hesaplarına girebiliyor (kritik).

4. Görsel bir risk özeti

Olasılık ve etki eksenli basit bir ısı haritası veya bulguların varlıklara göre dağılımı, 40 satırlık tablodan daha hızlı okunur. Ancak görsel, veriyi süslemek için değil, önceliği göstermek için olmalı.

5. Önceliklendirilmiş aksiyon planı

Yöneticinin sorusu "ne yapmalıyız?"dır. Yanıtı zaman çerçevesine bölün:

• Hemen (0–7 gün): Müşteri portalındaki yetkilendirme açığının kapatılması. Tahmini efor: 2–3 geliştirici günü.
• Kısa vade (30 gün): Tüm dış sistemlerde MFA, giriş deneme sınırı.
• Orta vade (90 gün): Yama yönetimi sürecinin kurulması, geliştiricilere güvenli kodlama eğitimi.

Efor ve maliyet tahmini eklemek, bütçe konuşmasını "güvenlik pahalı" düzeyinden "bu riski şu maliyetle kapatıyoruz" düzeyine taşır.

Risk puanlaması: CVSS yeterli mi?

CVSS, bir açığın teknik ciddiyetini ölçmek için endüstri standardıdır ve teknik ekte mutlaka yer almalıdır. Ancak CVSS, sizin iş bağlamınızı bilmez. İnternete açık, kişisel veri barındıran bir sistemdeki "orta" puanlı bir açık, yalnızca iç ağdan erişilen bir test sunucusundaki "yüksek" puanlı açıktan daha acil olabilir.

Teknik ek: geliştiricinin sevdiği rapor

Her bulgu için şu yapı, geliştiricinin açığı yeniden üretip kapatmasını kolaylaştırır:

• Başlık ve özet: Tek cümlede ne olduğu.
• Etkilenen varlık: URL, uç nokta, sunucu, parametre.
• Risk derecesi ve gerekçesi: CVSS vektörü ve iş bağlamı.
• Yeniden üretme adımları: Numaralı, kopyalanabilir istekler ve ekran görüntüleri.
• Kanıt: Hassas veriler maskelenmiş şekilde.
• Çözüm önerisi: Genel tavsiye değil, somut düzeltme (ör. "sorguda parametreli ifade kullanın; örnek kod ektedir").
• Referanslar: OWASP, CWE numarası.

Sunum toplantısı: raporu teslim etmek yetmez

Raporu e-postayla göndermek yerine 30–45 dakikalık bir kapanış toplantısı yapın. İlk 10 dakikada yönetici özetini anlatın, kritik bulgunun canlı ya da kayıtlı kısa bir gösterimini yapın; kalan sürede soruları yanıtlayın. Bir saldırının gerçekten nasıl göründüğünü görmek, sayfalarca metinden daha ikna edicidir.

Sık yapılan hatalar

• Otomatik tarayıcı çıktısını doğrulamadan rapora koymak (yanlış pozitifler güveni yok eder).
• Her bulguya "kritik" demek (her şey kritikse, hiçbir şey kritik değildir).
• Olumlu bulguları yazmamak: iyi çalışan kontrolleri de belirtmek, ekibin emeğini görünür kılar ve raporu dengeli yapar.
• Doğrulama testini (retest) planlamamak.

Sonuç

Bir sızma testi raporunun başarısı, kapatılan açık sayısıyla ölçülür. Bunun yolu da bulguları doğru okuyucuya, onun anlayacağı dilde sunmaktan geçer. Tüm sızma testlerimizde yönetici özeti ve teknik ek içeren iki katmanlı rapor ve ücretsiz doğrulama testi sunuyoruz. Ayrıntılar için sızma testi hizmetimize göz atabilirsiniz.