kullanici1
Nisan 20, 2026

Aksiyon planı oluşturmanın ilk adımı, rapordaki tüm bulguları “iş için ne ifade ediyor” sorusuyla filtrelemektir. Yüksek CVSS skoruna sahip bir zafiyet, izole bir test ortamındaysa veya arkasında güçlü bir telafi edici kontrol (WAF, IPS) varsa düşük öncelik almalıdır. Öte yandan, orta seviye bir yetki yükseltme hatası, müşteri veritabanına erişim sağlıyorsa veya ödeme sistemini etkiliyorsa “Kritik” önceliğe yükseltilmelidir. Önceliklendirme matrisi oluşturulurken; zafiyetin teknik şiddeti, hedef varlığın iş kritikliği, istismarın zorluk derecesi (exploitability) ve mevcut tehdit istihbaratı (bu zafiyet aktif olarak sömürülüyor mu?) değişkenleri ağırlıklandırılarak skorlanır. Bu sayede kaynaklar, kurumun gerçek riskini artıran alanlara yönlendirilir.
Aksiyon planı, tüm düzeltmeleri aynı anda yapmaya çalışmamalı, gerçekçi bir zamanlama ile kademeli ilerlemelidir. “Kritik” seviyedeki ve aktif istismarı olan bulgular için 24-72 saatlik acil müdahale süreleri (SLA) tanımlanır; bunlar genellikle konfigürasyon değişikliği veya yama ile hızla kapatılır. “Orta” seviye bulgular için 2-4 haftalık makul süreler tanınır. Uzun vadeli mimari değişiklikler (örneğin Legacy sistemlerin modernizasyonu veya Zero-Trust geçişi) ise “Stratejik Projeler” başlığı altında roadmap’e alınır ve bütçe/planlama süreçlerine dahil edilir. Zaman çizelgesi oluşturulurken, iş sürekliliğini etkileyecek bakım pencereleri (maintenance windows) ve geliştirme sprint döngüleri dikkate alınarak gerçekçi hedef tarihler belirlenir.
Aksiyon planındaki maddelerin tamamlandığı beyan edildikten sonra, doğrulama aşamasına geçilmelidir. Retest, düzeltme işleminin büyüklüğüne göre zamanlanır: kritik düzeltmeler için 48 saat içinde, diğerleri için haftalık veya aylık periyotlarla yapılır. Retest kapsamı, sadece düzeltilen zafiyetle sınırlı kalmamalı; “Fix Bypass” (düzeltmenin atlatılması) senaryoları da denenmelidir. Örneğin, bir giriş filtresi eklendiyse, sadece o filtre test edilmemeli, alternatif giriş vektörleri de denenmelidir. Retest’i, orijinal testi yapan ekip yapabileceği gibi, tarafsızlık sağlamak için bağımsız bir iç denetim ekibi de yapabilir. Retest sonuçları, “Düzeltildi”, “Kısmen Düzeltildi” veya “Düzeltilemedi” olarak net bir şekilde kaydedilmelidir.
Sızma testleri sonrası sıkça karşılaşılan durum, bir zafiyetin tam olarak kapatılamayıp sadece kısmen giderilmesidir. Örneğin, bir şifreleme eksikliği giderilmiş olabilir ancak anahtar yönetimi hala zayıf olabilir. Bu durumda aksiyon planı “Kapanmış” olarak işaretlenmemeli, mevcut durum “Yeni Risk” veya “Kalan Zafiyet” olarak yeniden değerlendirilmelidir. Kısmi düzeltmeler için yeni bir ticket açılmalı ve eksik kalan kısım için spesifik bir aksiyon tanımlanmalıdır. Eğer kısmi düzeltme riski önemli ölçüde azaltıyorsa, bu durum kabul edilebilir ancak eksik kalan kısım için de bir son teslim tarihi verilmelidir. Bu titizlik, “iş görüldü” yanılgısını önler ve zafiyetin tamamen ortadan kalkmasını garanti eder.
Aksiyon planının başarısı sadece “yapıldı/yapılmadı” ile değil, metriklerle ölçülmelidir. En kritik metrik MTTR (Mean Time to Remediate) yani bir zafiyetin tespitinden kapatılmasına kadar geçen ortalama süredir. Bu metrik, ekibin çeviklik düzeyini gösterir. Ayrıca; “SLA İhlal Oranı”, “İlk Seferde Düzeltme Başarısı” (First Time Fix Rate) ve “Tekrar Açılan Zafiyet Oranı” gibi göstergeler takip edilmelidir. Bu veriler aylık güvenlik raporlarında paylaşılarak, ekibin performansının artıp artmadığı izlenir. Metriklerdeki iyileşme, güvenlik yatırımlarının ve eğitimlerin işe yaradığının kanıtıdır; kötüleşme ise süreçlerde veya kaynaklarda bir sorun olduğuna işaret eder.
Aksiyon planının en büyük katkısı, gelecekteki hataları önlemektir. Testte sıkça görülen bulgular (örneğin zayıf şifre kullanımı, phishing’e tıklama) analiz edilerek, bir sonraki güvenlik farkındalık eğitiminin içeriği bu konulara odaklanacak şekilde güncellenmelidir. Teknik bulgular (örneğin kod hataları) ise Yazılım Geliştirme Yaşam Döngüsüne (SDLC) entegre edilmelidir. Bu, “Shift-Left” yaklaşımıdır; yani testte bulunan hataların, geliştirme aşamasında otomatik araçlarla (SAST/DAST) yakalanması için pipeline’a kurallar eklenir. Geliştiriciler için “Güvenli Kodlama Rehberi” bulgulara göre güncellenir. Bu entegrasyon, sızma testini “sonradan kontrol” olmaktan çıkarıp, kalitenin kaynağa enjekte edildiği bir sürece dönüştürür.