2026 Sızma Testi Bulguları ve Risk Seviyeleri: Önceliklendirme, Kanıt ve Düzeltim Yol Haritası
2026 tehdit manzarasında sızma testi çıktısı yalnızca “zafiyet listesi” değildir; bulguların teknik kanıt (PoC), iş etkisi ve risk seviyesi ile birlikte aksiyona dönüştürülebilir formatta yönetilmesi beklenir. Bu yaklaşım; BT, uygulama ekipleri, yönetim ve uyum fonksiyonları arasında ortak bir dil oluşturur.
Bu rehber; sızma testi bulgularında Kritik–Yüksek–Orta–Düşük risk seviyelerinin hangi kriterlerle belirleneceğini, CVSS gibi teknik skorların iş bağlamı ile nasıl birleştirileceğini ve bulguların SLA bazlı önceliklendirme ile nasıl kapatılacağını kurumsal pratikler üzerinden ele alır.
Hedef: Teknik zafiyetleri “iş riski” diline çevirmek.
Çerçeve: CVSS/teknik skor + maruziyet + istismar kolaylığı + veri/iş etkisi + kontrol olgunluğu.
Çıktı standardı: PoC + etki + kanıt + hedef yapılandırma + düzeltim adımları.
Operasyon: Risk seviyesine göre SLA, sorumlular, doğrulama ve kapanış kriterleri.
1. 2026’da Risk Seviyesi Neden Yeniden Tanımlanmalı?
2026’da saldırılar yalnızca “tek bir zafiyet” üzerinden değil; zincirleme istismar, kimlik temelli saldırılar, yetki yükseltme ve lateral hareket senaryoları üzerinden ilerlemektedir. Bu nedenle risk seviyesi belirlenirken yalnızca teknik skor değil, maruziyet, varlık kritiklik ve iş etkisi birlikte ele alınmalıdır.
1.1. Kurumsal Risk Skoru Yaklaşımı
Pratikte önerilen yaklaşım; CVSS gibi teknik ölçütleri “tek kaynak” olarak almak yerine, aşağıdaki bileşenlerle kurumsal risk skoru üretmektir:
- Teknik şiddet: CVSS, istismar önkoşulları, exploit olgunluğu
- Maruziyet: İnternet’e açık servis, geniş ağ erişimi, zayıf segmentasyon
- Varlık kritiklik: Üretim sistemi, ödeme/kimlik verisi, kritik iş süreçleri
- İş etkisi: KVKK/uyum etkisi, gelir kaybı, operasyon kesintisi, itibar etkisi
- Kontrol olgunluğu: EDR/SIEM, logging, IAM politikaları, izleme ve alarm
2. Risk Seviyeleri: Kritik–Yüksek–Orta–Düşük
Risk seviyeleri; bulgunun istismar edilmesi hâlinde olasılık ve etki bileşenlerinin birleşimi ile belirlenir. Aşağıdaki çerçeve, raporlama ve aksiyon takibi için kurumsal standart oluşturur.
| Seviye | Tipik Kriter | Örnek Etki | Önerilen Aksiyon |
|---|---|---|---|
| Kritik | Uzaktan istismar + yetkisiz erişim veya veri sızıntısı mümkün; exploit/PoC doğrulanmış; internet maruziyeti yüksek | Toplu veri ifşası, sistem ele geçirilmesi, iş kesintisi, KVKK ihlal bildirimi riski | Acil izolasyon/mitigasyon, hızlı düzeltim, doğrulama testi ve yönetim bilgilendirmesi |
| Yüksek | İstismar edilebilir zafiyet; ayrıcalık yükseltme/lateral hareket mümkün; kontrol zayıflığı mevcut | Yetki yükseltme, hassas sistemlere sıçrama, sınırlı veri sızıntısı | SLA ile kısa vadeli düzeltim, konfigürasyon sertleştirme, izleme/alert güçlendirme |
| Orta | İstismar için ek önkoşul var; etkisi sınırlı; çevresel kontroller kısmen mevcut | Sınırlı yetkisiz erişim, bilgi sızıntısı (düşük hacim), servis bozma riski | Planlı sprint ile giderim, yapılandırma iyileştirmesi, prosedür güncellemesi |
| Düşük | İstismar zor; etkisi düşük; daha çok hijyen/konfigürasyon standardı ihlali | Bilgi sızıntısı ihtimali düşük, operasyonel risk minimal | Backlog’a alınır, standart hardening ile giderim, periyodik kontrol |
2.1. SLA Örnekleri (Kurumsal Pratik)
- Kritik: 24–72 saat içinde mitigasyon + 7 gün içinde kalıcı düzeltim
- Yüksek: 14 gün içinde düzeltim / sertleştirme
- Orta: 30–60 gün içinde planlı düzeltim
- Düşük: 90 gün içinde standardizasyon / teknik borç iyileştirmesi
3. Bulgu Standardı: Kanıt (PoC) + Etki + Hedef Yapı
2026’da güçlü bir sızma testi raporu; teknik ekibin “hemen uygulayabileceği” netlikte olmalı, yönetime ise “riskin neden öncelikli olduğu”nu gösterebilmelidir. Bu nedenle her bulguda minimum aşağıdaki bileşenler yer almalıdır:
- Bulgu özeti: Zafiyetin adı, etkilenen bileşen, ortam (prod/test)
- Etki: CIA (Gizlilik-Bütünlük-Erişilebilirlik) ve iş etkisi açıklaması
- Kanıt (PoC): İstismar adımları, ekran görüntüsü/log çıktısı, doğrulama yöntemi
- Kök neden: Konfigürasyon hatası, patch eksikliği, tasarım problemi vb.
- Hedef yapı: Önerilen güvenli konfigürasyon (baseline)
- Düzeltim adımları: Uygulanabilir teknik aksiyon listesi
- Doğrulama kriteri: “Kapanış” için test senaryosu ve kabul kriteri
4. Örnek Bulgular ve Önceliklendirme (SLA)
4.1. Kritik Örnek: İnternet’e Açık Yönetim Paneli + Zayıf Kimlik Doğrulama
- Etki: Yetkisiz erişim, kullanıcı/veri çekimi, sistem kontrolü
- Kanıt: PoC ile oturum elde edilmesi veya brute-force/credential stuffing bulgusu
- Öneri: IP kısıt, MFA, WAF kuralı, rate-limit, SSO sertleştirme, audit log aktivasyonu
- SLA: 24–72 saat mitigasyon + 7 gün kalıcı düzeltim
4.2. Yüksek Örnek: Yetki Yükseltme (IDOR / Broken Access Control)
- Etki: Kullanıcılar arası veri erişimi, hesap ele geçirme zinciri
- Kanıt: Parametre manipülasyonu ile başka kullanıcının verisine erişim
- Öneri: Sunucu tarafı authorization kontrolleri, role-based policy, test kapsamı genişletme
- SLA: 14 gün
4.3. Orta Örnek: Güvenli Olmayan Header/Policy Eksikleri (Hardening)
- Etki: Exploit zincirlerinde kolaylaştırıcı etki (ör. clickjacking, MIME sniffing)
- Kanıt: Güvenlik başlıkları eksikliği raporu + doğrulama
- Öneri: CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy baseline
- SLA: 30–60 gün
4.4. Düşük Örnek: Bilgi Sızıntısı (Versiyon Banner / Default Sayfalar)
- Etki: Keşif aşamasını kolaylaştırır, tek başına kritik değildir
- Kanıt: Header/banner çıktıları
- Öneri: Banner kapatma, default endpoint temizliği, standart hardening
- SLA: 90 gün
5. Yönetim, Uyum ve Raporlama En İyi Uygulamalar
Sızma testi bulguları, KVKK ve bilgi güvenliği yönetişimi açısından “teknik ekip işi” olmaktan öte, kurumsal risk yönetimi çıktısıdır. Bu nedenle raporlama, karar ve kapanış akışı net kurgulanmalıdır.
5.1. Yönetim Özeti (Executive Summary) Formatı
- Toplam bulgu sayısı: Kritik/Yüksek/Orta/Düşük kırılımı
- En kritik 5 risk: İş etkisi, veri etkisi, operasyon etkisi
- Hızlı kazanımlar: 1–2 haftada kapatılabilecek yüksek riskli alanlar
- Yol haritası: 30/60/90 gün planı, sorumlular ve bağımlılıklar
5.2. Kapanış ve Doğrulama
- Kapanış kriteri: Düzeltim uygulanmış + yeniden test ile doğrulanmış
- Risk kabul: Gerekçe, süre, telafi kontrolleri ve yönetim onayı ile kayıt altına alınmalı
- İzlenebilirlik: Ticket ID, değişiklik kaydı, konfigürasyon farkı, test kanıtı
6. Sık Sorulan Sorular
CVSS skoru tek başına risk seviyesi belirlemek için yeterli mi?
Hayır. CVSS teknik şiddeti gösterir; ancak varlık kritiklik, maruziyet ve iş etkisi gibi bağlamsal unsurlar eklenmeden kurumsal önceliklendirme eksik kalır.
PoC eklemek her zaman gerekli mi?
Kritik ve yüksek bulgularda PoC/kanıt standardı, hem teknik doğrulama hem de yönetişim açısından belirleyicidir. PoC; üretimde risk yaratmayacak kontrollü yöntemle hazırlanmalı ve gerektiğinde maskelenmelidir.
Risk kabul nasıl yönetilmeli?
Risk kabul; süreli olmalı, telafi kontrolleri tanımlanmalı ve yönetim onayı ile kayıt altına alınmalıdır. “Kapatılamıyor” ifadesi tek başına kabul gerekçesi değildir; neden ve alternatif kontrol netleşmelidir.
Bulgu kapanışı için “fix uygulandı” yeterli mi?
Hayır. Kapanış; düzeltim sonrası yeniden test ile doğrulanmalı ve kanıtı rapora/ticket’a eklenmelidir. Aksi durumda benzer zafiyetlerin tekrar etmesi kaçınılmaz olur.
