- Bazı uygulamalar 7/24 çalışmak zorundadır.
- Bazı güncellemeler hizmet kesintisi yaratabilir.
- Bazı sistemler artık üretici desteği almıyor olabilir.
- Bazı zafiyetlerin teknik puanı çok yüksek olmasına rağmen sistem saldırgan tarafından erişilebilir olmayabilir. Buna karşılık teknik puanı daha düşük bir zafiyet gerçek saldırganlar tarafından aktif olarak kullanılıyor olabilir.
1. Zafiyet yönetimi tarama yapmak değildir
- Sunucu A - CVSS 9,8
- Sunucu B - CVSS 8,1
- Sunucu A yalnızca izole laboratuvar ortamında kullanılan, gerçek veri içermeyen bir test sistemi olsun.
- Sunucu B ise internete açık, vatandaşların kullandığı kritik hizmeti sağlayan ve gerçek saldırganların kullandığı bilinen bir zafiyeti barındıran sistem olsun.
Bu durumda yalnızca CVSS puanına göre hareket etmek bizi yanlış önceliğe götürebilir. FIRST, CVSS 4.0 dokümantasyonunda CVSS Base Score'un zafiyetin teknik şiddetini ölçtüğünü, tek başına risk ölçümü olarak kullanılmaması gerektiğini özellikle vurgulamaktadır.
2. Üç kavramı ayıralım: Şiddet, risk ve öncelik
- Bir zafiyetin şiddeti, teknik olarak ne kadar ciddi sonuç doğurabileceğini anlatır.
- Risk, bu zafiyetin bizim ortamımızda kullanılması ve ortaya çıkaracağı sonucun kurum açısından önemidir.
- Öncelik ise kurumun hangi zafiyete önce müdahale edeceğine ilişkin karardır.
- İnternete kapalıysa,
- Çok güçlü biçimde segment edilmişse,
- Gerçek veri içermiyorsa,
- Aktif olarak kullanılmıyorsa
- Ve saldırganın sisteme ulaşması son derece zorsa,
- Aynı zafiyet internete açık kritik sunucudaki kadar öncelikli olmayabilir.
- Aktif olarak istismar ediliyorsa,
- İnternet üzerinden erişilebiliyorsa,
- Kritik sistemde bulunuyorsa
- Ve güçlü telafi edici kontrol bulunmuyorsa,
3. CVSS bize ne söyler?
- Ağ üzerinden gerçekleştirilebilmesi,
- Saldırının karmaşıklığı,
- Gerekli ayrıcalıklar,
- Kullanıcı etkileşimi
- Ve güvenlik etkileri değerlendirilir.
- Bu ürün bizim kurumumuzda var mı?
- Zafiyet internete açık sistemde mi?
- Bu sistemi saldırganlar gerçekten hedefliyor mu?
- Zafiyet şu anda aktif olarak istismar ediliyor mu?
- Sistem hangi kritik hizmeti destekliyor?
- Güçlü telafi edici kontrollerimiz var mı?
- Sistemin durması insan güvenliğini etkiler mi?
4. İkinci sinyal: Bu zafiyet gerçekten kullanılıyor mu?
CISA, KEV kataloğunu gerçek dünyada istismar edildiği bilinen zafiyetler için yetkili bir kaynak olarak tanımlamakta ve kurumların bu kataloğu zafiyet önceliklendirme süreçlerine girdi olarak kullanmalarını önermektedir.
5. 2026'daki NVD değişikliği bize ne anlatıyor?
Burada güncel ve dikkat çekici bir gelişme de bulunmaktadır. NIST, Nisan 2026'da National Vulnerability Database — NVD operasyonlarında yeni bir risk tabanlı önceliklendirme yaklaşımına geçtiğini açıkladı.
NIST'e göre CVE bildirimlerinin sayısı 2020–2025 arasında %263 arttı. Artan hacim nedeniyle NVD artık bütün CVE'leri aynı öncelikle zenginleştirmeye çalışmak yerine özellikle:
- CISA KEV kataloğunda bulunan zafiyetleri,
- ABD federal kurumlarında kullanılan yazılımları
- Ve kritik yazılımları
önceliklendiriyor. Bu değişiklik zafiyet yönetimindeki daha geniş bir problemi ortaya koyuyor: Zafiyet sayısı, bütün zafiyetleri aynı biçimde ele almanın pratik olmadığı bir seviyeye ulaşmıştır.
6. Üçüncü sinyal: EPSS bize ne söyler?
Bir zafiyet henüz KEV kataloğunda olmayabilir. Peki önümüzdeki dönemde saldırganların onu kullanma ihtimali nedir? Burada: Exploit Prediction Scoring System - EPSS devreye girer.
FIRST tarafından sürdürülen EPSS, yayımlanmış bir CVE'nin önümüzdeki 30 gün içerisinde gerçek dünyada istismar edilme olasılığını tahmin eden veri odaklı bir modeldir. Her CVE için 0 ile 1 arasında güncellenen bir olasılık değeri üretir.
Burada çok önemli bir ayrım vardır. EPSS: zafiyetin ne kadar zarar vereceğini ölçmez. Kurumunuzdaki sistemin önemini bilmez. Telafi edici kontrollerinizi bilmez.
EPSS yalnızca istismar olasılığı konusunda güçlü bir veri sinyali sağlar. FIRST da EPSS'nin tek başına tam bir risk skoru olmadığını özellikle belirtmektedir. Dolayısıyla:
7. EPSS neden değerlidir?
Dünyadaki CVE sayısı çok yüksektir ancak bunların tamamı gerçek saldırılarda aynı oranda kullanılmaz. EPSS bu nedenle saldırgan davranışına ilişkin gözlemlerden yararlanarak: “Hangilerinin önümüzdeki dönemde gerçekten kullanılma ihtimali daha yüksek?” sorusunu cevaplamaya çalışır.
FIRST'ün güncel EPSS modeli günlük olarak CVE'leri yeniden puanlamakta ve saldırı ekosistemindeki değişiklikleri modele yansıtmaktadır. Modelin girdileri arasında kamuya açık exploit kodları, saldırı araçlarında kullanım ve gözlenen gerçek istismar sinyalleri gibi çok sayıda özellik bulunmaktadır.
8. Dördüncü sinyal: Sistem gerçekten saldırgana açık mı?
Aynı CVE. Aynı CVSS. Aynı EPSS. Ama kurumsal maruziyet aynı değildir. Bu nedenle zafiyet yönetiminde: Exposure — Maruziyet ayrı değerlendirilmelidir.
- Sistem internete açık mı?
- Saldırganın önce VPN erişimi mi elde etmesi gerekiyor?
- Kimlik doğrulama gerekiyor mu?
- Ağ segmentasyonu var mı?
- Zafiyetli servis gerçekten aktif mi?
- Güvenlik duvarı erişimi sınırlandırıyor mu?
- Yalnızca belirli yönetim ağlarından mı ulaşılabiliyor?
Bir zafiyet mevcut olsa bile saldırganın ona ulaşabileceği bir yol yoksa risk bağlamı değişebilir. Ancak burada dikkatli olunmalıdır. “İç ağda olduğu için güvenlidir.” sonucuna otomatik olarak varılmamalıdır.
9. Beşinci sinyal: Varlık ne kadar kritik?
Risk tabanlı zafiyet yönetiminin en önemli bileşenlerinden biri budur.
Bir zafiyet: hangi sistemde? Ama bundan daha önemlisi: Bu sistem hangi kritik hizmeti destekliyor?
Teknik zafiyet aynı olsa bile olayın doğuracağı sonuç aynı değildir. CISA'nın zafiyet yönetimi rehberlerinde de, varlıkların iş açısından kritik fonksiyonlarla eşleştirilmesi ve iş sürekliliği, hassas veri, itibar ve finansal sonuçlar üzerinde daha büyük etki oluşturabilecek sistemlerin önceliklendirilmesi önerilmektedir.
10. Altıncı sinyal: Mevcut kontroller ne kadar güçlü?
Bir zafiyet sistemde bulunuyor olabilir. Ancak saldırganın zafiyeti kullanmasını zorlaştıran kontroller mevcut olabilir. Örneğin:
- WAF,
- EDR,
- Network Segmentation,
- MFA,
- Uygulama allowlist,
- IP kısıtlaması,
- Erişim kontrolü,
- Sandbox,
- IDS/IPS
gibi mekanizmalar belirli saldırı yollarını zorlaştırabilir. Bu durumda kontrol: zafiyeti ortadan kaldırmaz ama: riski azaltabilir. Bu nedenle risk tabanlı zafiyet yönetiminde: “Patch var mı?” kadar: “Patch uygulanana kadar riski hangi telafi edici kontrollerle azaltabiliriz?” sorusu da önemlidir.
Özellikle operasyonel teknoloji veya 7/24 hizmet veren kritik sistemlerde güncellemenin hemen uygulanması mümkün olmayabilir.
CISA da yama uygulamasının mümkün olmadığı veya kullanılabilirlik/güvenlik üzerinde ciddi etki oluşturabileceği durumlarda segmentasyon ve izleme gibi telafi edici kontrollerin uygulanabileceğini belirtmektedir.
11. Zafiyet önceliği için tek skor yeterli mi?
Kuruluşlar bazen bütün bu bilgileri tek bir: “Risk skoru” haline getirmek ister. Örneğin: CVSS × Varlık Kritiklik × Maruziyet gibi formüller oluşturulabilir. Böyle modeller operasyonel açıdan faydalı olabilir. Ancak dikkatli kullanılmalıdır.
Çünkü; matematiksel bir skor oluşturduğumuzda: bilmediğimiz şeyleri biliyormuşuz gibi gösterme riski doğar. Örneğin: 9,8 × 5 × 4 = 196 sonucu çıkarabiliriz. Fakat: 196'nın gerçekten ne anlama geldiği açık değilse, sayı yalnızca sahte kesinlik üretir. Bunun yerine skoru karar desteği olarak kullanmalı, kararın kendisi haline getirmemeliyiz.
12. CISA SSVC: Skordan karar ağacına
Zafiyet önceliklendirmesinde farklı bir yaklaşım: Stakeholder-Specific Vulnerability Categorization — SSVC modelidir. SSVC yalnızca tek bir sayısal skor vermek yerine karar ağacı kullanır. CISA'nın SSVC uygulamasında şu tür karar noktaları değerlendirilir:
- State of Exploitation — Aktif istismar durumu
- Technical Impact — Teknik etki
- Automatable — Saldırının otomatikleştirilebilirliği
- Mission Prevalence — Etkilenen sistemin görev açısından yaygınlığı/önemi
- Public Well-Being Impact — Kamu güvenliği ve toplumsal etki
- Mitigation Status — Azaltıcı önlemlerin durumu
Bu değerlendirme sonucunda zafiyetler örneğin: Track, Track*, Attend, Act gibi operasyonel karar kategorilerine yönlendirilebilir.
13. Örnek: Dört zafiyetimiz var, hangisi önce?
| Özellik | Zafiyet A | Zafiyet B | Zafiyet C | Zafiyet D |
|---|---|---|---|---|
| CVSS | 9,8 | 8,1 | 7,5 | 9,6 |
| KEV | Hayır | Evet | Hayır | Hayır |
| EPSS | %1 | %78 | %64 | %5 |
| İnternete açık | Hayır | Evet | Evet | Hayır |
| Sistem | Test | VPN | Vatandaş Portalı | Kritik OT |
| Kritik hizmet | Düşük | Yüksek | Çok yüksek | Çok yüksek |
| Telafi edici kontrol | Güçlü | Sınırlı | Orta | Güçlü segmentasyon |
Yalnızca CVSS'ye göre: A → D → B → C sırasıyla ilerlemek cazip görünebilir. Ancak risk bağlamını eklediğimizde B çok daha acil hale gelir.
Çünkü: gerçek dünyada aktif istismar vardır, internet üzerinden erişilebilir, kritik hizmeti destekler ve EPSS değeri yüksektir.
C de CVSS puanı daha düşük olmasına rağmen internet erişimi, kritik hizmet ve yüksek tahmini istismar olasılığı nedeniyle önemli bir öncelik olabilir.
D kritik OT sistemidir. Ancak doğrudan patch uygulamak sistemi veya fiziksel süreci tehlikeye sokabiliyorsa önce güvenli mühendislik değerlendirmesi, segmentasyon, izleme ve uygun bakım penceresi gerekebilir.
A ise teknik olarak en yüksek puana sahip olmasına rağmen izole test sisteminde bulunuyorsa diğerlerinin arkasına alınabilir.
14. Ben nasıl bir önceliklendirme modeli kullanırdım?
| Boyut | Temel soru |
|---|---|
| Teknik şiddet | Zafiyet başarılı kullanılırsa teknik olarak ne yapabilir? |
| Aktif istismar | Gerçek saldırganların bunu kullandığı biliniyor mu? |
| İstismar olasılığı | Yakın dönemde kullanılma ihtimaline ilişkin tehdit sinyali ne? |
| Maruziyet | Saldırgan zafiyetli bileşene ne kadar kolay ulaşabilir? |
| Varlık kritiklik seviyesi | Sistem hangi kritik görevi/hizmeti destekliyor? |
| Mevcut kontroller | Saldırı yolunu azaltan veya sınırlandıran kontroller var mı? |
| Olası etki | Başarılı istismar kuruma ne kaybettirir? |
Bunun sonunda tek bir otomatik skor vermek yerine dört karar kategorisi kullanılabilir:
- P1 — Acil müdahale
- P2 — Yüksek öncelikli müdahale
- P3 — Planlı düzeltme
- P4 — İzle / kabul edilmiş risk kapsamında takip et
15. P1 — Acil müdahale ne zaman düşünülmeli?
Örneğin aşağıdaki faktörlerin birkaçının birlikte bulunması, acil müdahale ihtiyacını güçlendirebilir:
- Aktif istismar kanıtı,
- İnternete açık sistem,
- Kritik iş veya kamu hizmeti,
- Yüksek veri hassasiyeti,
- Saldırının kolay otomatikleştirilebilmesi,
- Etkili telafi edici kontrol bulunmaması,
- Yüksek ayrıcalık veya uzaktan kod çalıştırma etkisi.
Burada yine otomatik kural kullanmamak gerekir. Örneğin OT ortamında aceleyle patch uygulamak üretim güvenliğini tehlikeye sokabilir.
16. Patch yapmak ile riski azaltmak aynı şey değildir
En ideal senaryoda güvenlik açığı üretici güncellemesiyle tamamen giderilebilir. Bu: remediation — düzeltme olarak düşünülebilir.
Ancak bazen güncelleme hemen mümkün değildir. O zaman: mitigation — risk azaltma uygulanabilir. Örneğin:
- Zafiyetli özelliği devre dışı bırakmak,
- Erişimi yalnızca belirli IP adresleriyle sınırlamak,
- Sistemi internetten kaldırmak,
- WAF kuralı uygulamak,
- Segmentasyonu artırmak,
- Ek izleme uygulamak
riski geçici olarak azaltabilir. CISA'nın zafiyet yönetimi yaklaşımı da remediation, mitigation ve belirli koşullarda acceptance seçeneklerini birbirinden ayırmaktadır.
17. Zafiyet kapatıldıktan sonra iş bitmez
Bir güncelleme başarıyla uygulandı. Ticket kapatıldı. Gerçekten bitti mi? Hayır. Çünkü doğrulanması gerekir. Tekrar tarama yapılabilir. Zafiyetli servis kontrol edilebilir. Güncellemenin gerçekten doğru sisteme uygulandığı doğrulanabilir. Kritik işlevlerin hâlâ çalıştığı test edilebilir.
CISA da düzeltme tamamlandıktan sonra zafiyetin gerçekten giderilip giderilmediğinin yeniden tarama veya doğrulama ile kontrol edilmesini önerir. Dolayısıyla yaşam döngüsü: Bul → Önceliklendir → Müdahale et → Doğrula şeklinde düşünülmelidir. Buna bir adım daha eklemek gerekir: Öğren.
- Neden bu sistem güncellenmedi?
- Neden bu zafiyet aylarca açık kaldı?
- Envanter eksik miydi?
- Patch süreci mi zayıftı?
- Üretici desteği mi bitmişti?
- İş birimi downtime vermedi mi?
18. “Patch borcu” oluşabilir
Bir kurumda sürekli yeni zafiyetler açılıyor ama kapatma hızı bunun gerisinde kalıyorsa zamanla birikmiş bir risk havuzu oluşur. Buna basitleştirilmiş şekilde: Zafiyet Borcu demek mümkündür. Özellikle:
- Destek süresi bitmiş sistemler,
- Sürekli ertelenen güncellemeler,
- Sahipsiz uygulamalar,
- Eski işletim sistemleri,
- Patch uygulanamayan kritik sistemler
bu borcu büyütebilir. Bu durumda tek tek zafiyetlerin peşinden koşmak yeterli değildir. Yönetim seviyesinde: “Neden sürekli risk biriktiriyoruz?” sorusu sorulmalıdır.
Sorun bazen teknik ekipte değil:
- Tedarik politikasında,
- Bütçede,
- Uygulama sahipliğinde,
- Değişiklik yönetiminde,
- İş sürekliliği planında
- Veya sistem yaşam döngüsü yönetiminde olabilir.
19. Yöneticiye nasıl raporlanmalıdır?
Üst yönetime: 12.731 kritik zafiyetimiz var. demek tek başına fazla anlam ifade etmeyebilir. Daha değerli raporlama şöyle olabilir:
- Aktif istismar edilen ve kurumda bulunan zafiyet sayısı
- İnternete açık kritik sistemlerdeki yüksek öncelikli zafiyetler
- SLA süresi geçmiş kritik zafiyetler
- Kritik hizmetlerdeki açık riskler
- Telafi edici kontrol altında çalışan sistemler
- Üretici desteği bitmiş kritik sistemler
- Son 90 günde kapatılan risk seviyesi
- Tekrar eden zafiyet nedenleri
20. Risk Tabanlı Zafiyet Önceliklendirme Zinciri
Bu çalışmanın temel modelini şöyle özetleyebiliriz:
1 — Bul
Hangi zafiyetler var?
↓
2 — Doğrula
Bulgu gerçekten ilgili sistemde mevcut mu?
↓
3 — Teknik şiddeti anla
CVSS ve zafiyet özellikleri ne söylüyor?
↓
4 — Tehdit durumunu kontrol et
KEV'de mi?
Aktif exploit var mı?
↓
5 — İstismar olasılığını değerlendir
EPSS ve diğer tehdit istihbaratı ne söylüyor?
↓
6 — Maruziyeti belirle
Saldırgan sisteme gerçekten ulaşabilir mi?
↓
7 — Kritikliği belirle
Bu sistem hangi görevi veya hizmeti destekliyor?
↓
8 — Kontrolleri değerlendir
Riski bugün ne azaltıyor?
↓
9 — Olası etkiyi belirle
İstismar gerçekleşirse ne kaybederiz?
↓
10 — Önceliklendir
Acil mi, yüksek mi, planlı mı, izleme mi?
↓
11 — Müdahale yöntemini seç
Patch, konfigürasyon, izolasyon, telafi edici kontrol veya risk kabulü.
↓
12 — Doğrula
Risk gerçekten azaldı mı?
↓
13 — Öğren
Sık yapılan zafiyet yönetimi hataları
En yaygın hata CVSS'yi risk zannetmektir. CVSS teknik şiddet açısından güçlü bir araçtır; ancak FIRST açık biçimde Base skorun tek başına risk ölçümü olmadığını belirtmektedir.
İkinci hata binlerce zafiyeti aynı SLA ile yönetmeye çalışmaktır. Bu yaklaşım ekip kapasitesini gerçekten kritik risklerden uzaklaştırabilir.
Üçüncü hata varlık kritikliğini bilmemektir. Sistem envanteri ile iş hizmeti haritası ilişkilendirilmeden risk tabanlı önceliklendirme yapmak güçleşir.
Dördüncü hata aktif istismar bilgisini dikkate almamaktır. KEV gibi kaynaklar gerçek saldırgan davranışına ilişkin güçlü kanıt sağlar.
Beşinci hata patch uygulanamıyorsa riskin yönetilemeyeceğini düşünmektir. Uygun telafi edici kontroller geçici risk azaltımı sağlayabilir.
Altıncı hata düzeltme sonrasında doğrulama yapmamaktır.
Yedinci ve belki de en önemli hata ise zafiyet yönetimini yalnızca güvenlik ekibinin görevi olarak görmektir.
Sonuç: En kritik zafiyet, puanı en yüksek olan değildir
Modern kurumların sorunu zafiyet bulamamak değildir. Çoğu zaman sorun tam tersidir: Çok fazla zafiyet bulmak. Bu nedenle gerçek yetkinlik: daha uzun zafiyet listesi üretmek değil, hangi zafiyetin neden önce ele alınması gerektiğini açıklayabilmektir.
- CVSS bize teknik şiddeti anlatır.
- KEV gerçek saldırganların ne kullandığını gösterir.
- EPSS yakın dönem istismar olasılığına ilişkin veri sağlar.
- Maruziyet saldırganın sisteme ulaşabilme şartlarını gösterir.
- Varlık kritiklik seviyesi olayın kurum açısından önemini belirler.
- Mevcut kontroller riskin ne kadar azaltılmış olduğunu gösterir.
- İş etkisi ise bütün bunların neden önemli olduğunu açıklar.
Dolayısıyla: Bir zafiyet, yalnızca yüksek CVSS puanına sahip olduğu için kurumun en önemli riski değildir.
Daha güçlü soru şudur: “Bu zafiyet gerçek bir tehdit tarafından kullanılırsa, bu sistem üzerinden hangi kritik görevimizi kaybedebiliriz ve elimizde bunu engelleyecek ne var?”
İşte bu soru sorulduğunda zafiyet taramasından: risk tabanlı zafiyet yönetimine geçmiş oluruz. Siber güvenlik uzmanının değeri yalnızca: “Açığı buldum.” demesinde değildir.
Kaynaklar:
Cybersecurity and Infrastructure Security Agency. Known Exploited Vulnerabilities Catalog. CISA, gerçek dünyada aktif olarak istismar edildiği bilinen zafiyetlerin kataloğunu yayımlamakta ve kurumların KEV bilgisini zafiyet yönetimi önceliklendirmesinde kullanmasını önermektedir.
Cybersecurity and Infrastructure Security Agency. Stakeholder-Specific Vulnerability Categorization (SSVC) Guide. SSVC; zafiyetleri yalnızca sayısal teknik puanlarla değerlendirmek yerine aktif istismar, teknik etki, otomatikleştirilebilirlik, görev etkisi ve toplumsal sonuçlar gibi karar noktaları üzerinden müdahale kategorilerine yönlendiren karar ağacı yaklaşımıdır.
Cybersecurity and Infrastructure Security Agency. Healthcare and Public Health Sector Cybersecurity Mitigation Guide. Varlıkların kritik iş fonksiyonlarıyla eşleştirilmesi, aktif istismar bilgilerinin kullanılması, CVSS, EPSS ve SSVC'nin önceliklendirme süreçlerinde birlikte değerlendirilmesi açısından uygulamaya dönük örnekler içermektedir.
FIRST. Common Vulnerability Scoring System Version 4.0 User Guide. CVSS 4.0 zafiyet şiddetinin standart biçimde ifade edilmesine yönelik güncel çerçevedir. FIRST, CVSS Base Score'un şiddeti ölçtüğünü ve tek başına risk skoru olarak kullanılmaması gerektiğini açıkça belirtmektedir.
FIRST. Exploit Prediction Scoring System (EPSS). EPSS, yayımlanmış CVE'lerin önümüzdeki 30 gün içerisinde gerçek dünyada istismar edilme olasılığını tahmin eden veri odaklı modeldir. EPSS tek başına tam risk skoru değildir; varlık bağlamı ve etki değerlendirmesiyle birlikte kullanılmalıdır.
National Institute of Standards and Technology. (2025). Prioritizing Cybersecurity Risk for Enterprise Risk Management (NIST IR 8286B Update 1). NIST, siber risklerin kurum hedefleri üzerindeki potansiyel etkilerine göre önceliklendirilmesini ve risk cevaplarının kurumsal risk yönetimiyle bütünleştirilmesini ele almaktadır.
National Institute of Standards and Technology. (2026). NIST Updates NVD Operations to Address Record CVE Growth. NIST, artan CVE hacmi karşısında NVD zenginleştirme çalışmalarında KEV, federal kullanılan yazılımlar ve kritik yazılımlar gibi risk temelli öncelik kriterlerine geçtiğini açıklamıştır.