Zafiyet Yönetimi Nedir, Kimler İçin Gerekli?
Zafiyet yönetimi, bilgi teknolojileri varlıklarında ortaya çıkan güvenlik açıklarının tespit edilmesi, doğrulanması, risk bazlı önceliklendirilmesi ve giderilmesi için yürütülen sürekli bir süreçtir. Amaç yalnızca açıkları bulmak değil, hangisinin önce kapatılması gerektiğine doğru karar vermektir.
Zafiyet Yönetimi Nedir?
Zafiyet yönetimi, bilgi teknolojileri varlıklarında ortaya çıkan güvenlik açıklarının tespit edilmesi, doğrulanması, risk bazlı önceliklendirilmesi ve giderilmesi için yürütülen sürekli bir süreçtir.
Siber saldırganlar mevcut zafiyetleri kullanarak sistemlere sızabilir, verileri çalabilir veya hizmetleri kesintiye uğratabilir. Ancak her zafiyet aynı önemde değildir, önceliklendirme yapmadan çalışan bir program sınırlı kaynakları yanlış yere harcar.
Zafiyet Yönetimi Neden Kritik? İki Gerçek Vaka
Log4Shell (2021) — Yama Vardı, Görünürlük Yoktu
Apache Log4j kütüphanesindeki Log4Shell açığı (CVE-2021-44228) 9 Aralık 2021'de kamuoyuna duyuruldu ve Apache aynı gün bir yama yayınladı. Ancak Log4j o kadar çok uygulamanın içine gizli bağımlılık olarak gömülmüştü ki, kurumlar kendi sistemlerinde nerede kullanıldığını tespit etmekte aylarca zorlandı. Güvenlik araştırmacıları bu açığın hâlâ, dört yıl sonra bile, bazı kurumlarda istismar edildiğini bildiriyor.
Buradaki ders yama hızıyla ilgili değil, görünürlükle ilgilidir: bir yama olsa bile, o bileşenin nerede kullanıldığını bilmiyorsanız kapatamazsınız.
MOVEit Veri İhlali (2023) — Bilinmeyen Bir Açığın İstismarı
MOVEit dosya transfer yazılımındaki kritik SQL injection açığı (CVE-2023-34362) bir zero-day'di, yani Cl0p saldırgan grubu bu açığı 27 Mayıs 2023'te istismar etmeye başladığında yazılımı üreten Progress Software'in kendisi bile açığın varlığından habersizdi. Şirket açığı öğrenir öğrenmez hızlı davrandı ve dört gün içinde (31 Mayıs) yama yayınladı, ama o noktada saldırı zaten geniş çapta sürüyordu. 100 milyondan fazla kişinin verisi etkilendi.
Buradaki ders şu: aktif olarak istismar edilen kritik zafiyetlerde yalnızca klasik yama döngüsüne güvenmek yeterli değildir, KEV kataloğu, tehdit istihbaratı ve internete açıklık gibi sinyallerin hızla değerlendirilip acil durum süreçlerinin devreye girmesi gerekir.
Modern Önceliklendirme: CVSS + EPSS + KEV + Varlık Bağlamı
Uzun yıllar zafiyet önceliklendirmesi yalnızca CVSS (Common Vulnerability Scoring System) skoruna dayanıyordu. Ancak CVSS yalnızca teorik önem derecesini gösterir, bir zafiyetin gerçekten istismar edilip edilmediğini ya da sizin ortamınızda ne kadar risk oluşturduğunu göstermez. Bugün sektör dört sinyali birlikte değerlendiriyor:
| Sinyal | Ne Ölçer |
|---|---|
| CVSS | Zafiyetin teorik önem derecesi, istismar edilirse ne kadar kötü sonuçlanabileceği. |
| EPSS | Önümüzdeki 30 gün içinde gerçekten istismar edilme olasılığı (FIRST.org, v4). |
| CISA KEV | Fiilen istismar edildiği doğrulanmış zafiyetler kataloğu. |
| Varlık Bağlamı | Sistemin internete açıklığı, iş kritikliği, veri hassasiyeti ve olası etki. |
Örnek: izole bir test sistemindeki CVSS 9.8 puanlı bir zafiyet, internete açık kritik bir sistemde bulunan, KEV kataloğunda yer alan ve EPSS değeri yüksek CVSS 7.5 puanlı bir zafiyetten daha düşük operasyonel önceliğe sahip olabilir. Puan tek başına önceliği belirlemez, bağlam belirler.
KEV kaydı, bir zafiyetin gerçek saldırılarda istismar edildiğinin doğrulandığını gösteren çok güçlü bir aciliyet sinyalidir. Ancak önceliklendirmede kurumda ilgili ürünün bulunup bulunmadığı, varlığın internete açıklığı, varlık kritikliği ve mevcut telafi edici kontroller de mutlaka dikkate alınmalıdır.
CISA, Haziran 2026'da yayınladığı BOD 26-04 direktifiyle federal kurumlara artık salt CVSS skoruna göre değil, varlığın internete açıklığı, KEV durumu, istismarın otomatikleştirilebilirliği ve başarılı istismar sonrası teknik etki olmak üzere dört faktörlü bir risk modeline göre yama yapmasını zorunlu kıldı.
Zafiyet Yönetimi Kimler İçin Gerekli?
- İnternete açık sistemleri bulunan kuruluşlar
- Çok sayıda sunucu, uç nokta veya ağ cihazı yöneten kurumlar
- Kritik veya kişisel veri işleyen kuruluşlar
- Düzenleyici yükümlülüklere tabi şirketler
- Bulut ve hibrit altyapı kullanan kurumlar
- Yıl boyunca zafiyetlerin takip edilmesini isteyen kuruluşlar
Yılda bir veya birkaç kez sızma testi yaptırmak, sürekli zafiyet yönetiminin yerine geçmez. Sızma testi belirli bir andaki durumu gösterir, zafiyet yönetimi ise o andan sonraki her günü kapsar.
Zafiyet Taraması ile Zafiyet Yönetimi Arasındaki Fark
Bu iki kavram sık karıştırılır. Zafiyet taraması, belirli bir anda otomatik araçlarla açıkları tespit eden teknik bir faaliyettir, çıktısı bir liste olur. Zafiyet yönetimi ise taramanın ötesine geçer: varlık envanteri, tarama, doğrulama, önceliklendirme, iyileştirme, SLA takibi, risk kabulü ve raporlamayı kapsayan sürekli bir programdır. Tarama bir fotoğraf çeker, yönetim o fotoğrafı aksiyona dönüştürür.
Sparta'nın Zafiyet Yönetimi Metodolojisi
Zafiyetlerin nasıl önceliklendirileceğine dair metodolojik bir çerçeve sunuyor, iyileştirme süreçlerinin takibi ve kalan risklerin kurum tarafından üstlenilmesi için gereken onay akışlarını kurguluyoruz.
Varlıkların Belirlenmesi
Taranacak sistemlerin ve varlıkların envanterinin çıkarılması.
Tarama
Otomatik araçlarla bilinen zafiyetlerin tespit edilmesi.
Doğrulama
Otomatik tarama çıktıları gerekli durumlarda doğrulanmadan doğrudan nihai bulgu olarak kabul edilmez, yanlış pozitifler ayıklanır.
Triage ve Risk Bazlı Önceliklendirme
CVSS, EPSS, KEV ve varlık bağlamı birlikte değerlendirilerek zafiyetler önceliklendirilir.
SLA Tanımlama
Kritiklik seviyesine göre hedef kapatma süreleri belirlenir.
İyileştirme
Patch yönetimi süreciyle entegre şekilde zafiyetlerin kapatılması.
Yeniden Doğrulama
Kapatıldığı bildirilen zafiyetlerin gerçekten giderildiğinin teyit edilmesi.
Risk Kabulü
Kapatılamayan zafiyetler için resmi bir risk kabul akışı işletilir, kalan risk bilinçli olarak kurum tarafından üstlenilir.
Raporlama
Sürecin tamamı denetlenebilir, takip edilebilir bir raporlama modeliyle üst yönetime sunulur.
Kuruluşlar İçin Öneriler
- Düzenli zafiyet taramaları yapılmalı
- Önceliklendirme yalnızca CVSS'e değil, EPSS, KEV ve varlık bağlamına da dayanmalı
- Sistem güncellemeleri ve yamalar tanımlı SLA'lara bağlanmalı
- Yazılım bağımlılıkları (Log4Shell örneğindeki gibi) düzenli olarak envanterlenmeli
- Kapatılamayan riskler için resmi bir risk kabul süreci işletilmeli
CISA BOD 26-04, Prioritizing Security Updates Based on Risk (Haziran 2026) — cisa.gov. EPSS v4, FIRST.org — first.org. Log4Shell (CVE-2021-44228) teknik analizi — CISA Advisory AA21-356A. MOVEit / CVE-2023-34362, #StopRansomware danışma metni — CISA Advisory AA23-158A.