Yama önceliklendirme, zafiyet yönetiminin en çok emek yutan ve en sık yanlış kurgulanan adımıdır. Tipik tablo şudur: tarama raporu binlerce satır döner, ekip en yüksek skorlu bulgudan başlar, listeyi yukarıdan aşağı eritmeye çalışır ve haftalar sonra hâlâ ilk sayfalardadır. Bu sırada listenin ortasında duran, “orta seviye” etiketli, internete açık bir dosya aktarım arayüzü saldırganın ilk erişim noktası olur.

Saldırgan sizin öncelik listenize bakmaz. Onun sorusu tektir: hangi zafiyetin çalışan bir istismar kodu var ve o zafiyet dışarıdan erişilebilir bir sistemde mi duruyor? Bu yazı, önceliklendirmeyi tek bir skorun insafına bırakmayan, dört veri katmanını birleştiren ve her kurumun kendi envanterine uyarlayabileceği bir karar modeli anlatıyor.

Skora göre sıralanan yama kuyruğu neden ilerlemez

Şiddet skoru (CVSS, Common Vulnerability Scoring System) bir zafiyetin teorik etkisini kurumdan bağımsız biçimde ölçer; yama kuyruğu ise tamamen kuruma özgü kısıtlarla ilerler. Aynı skoru taşıyan iki bulgudan biri tek adımda güncellenen bir istemci yazılımında, diğeri yılda iki kez durdurulabilen bir üretim veri tabanındadır. Skor bu farkı görmediği için ürettiği sıralama planlanabilir bir iş listesine dönüşmez.

İkinci sorun, kuyruğun tepesinin hiç boşalmamasıdır. Her tarama döngüsünde yeni yüksek skorlu bulgular eklenir; ekip listenin başını eritmeye çalışırken aşağıda bekleyen ve fiilen istismar edilmekte olan bir kalem aylarca sırasını bekler. Bu nedenle sıralamanın skordan değil, karar ölçütlerinden doğması gerekir.

Skorun tek başına cevaplamadığı sorular şunlardır:

• Bu zafiyet için dolaşımda çalışan bir istismar kodu var mı?
• Etkilenen sistem internetten doğrudan erişilebiliyor mu?
• Sistem kişisel veri, kimlik bilgisi veya ödeme verisi işliyor mu?
• Zafiyet bir saldırı zincirinin ilk halkası mı, yoksa ancak içeri girildikten sonra mı işe yarıyor?
• Yama uygulanamıyorsa devrede olan telafi edici kontrol (compensating control) var mı?

Yama kararını besleyen dört veri kümesi

Sağlıklı bir sıralama, dört bağımsız veri kümesinin kesişiminden çıkar. Bunlardan biri eksikse sıralama teknik olarak doğru ama iş açısından yanlış olur.

• Zafiyet verisi: CVE kimliği, etkilenen sürüm aralığı, CVSS vektörü, yamanın varlığı.
• Tehdit verisi: zafiyetin gerçek dünyada istismar edilip edilmediği, istismar kodunun kamuya açık olup olmadığı, ilgili kampanyaların hedef sektörü.
• Varlık verisi: sistemin iş kritikliği, sahibi, işlediği veri sınıfı, ağ konumu, kesinti toleransı.
• Kontrol verisi: önünde WAF var mı, uç noktada davranış tabanlı tespit çalışıyor mu, segmentasyon istismarın etkisini sınırlıyor mu?

İstismar verisi nereden okunur: KEV ve EPSS

Tehdit katmanının iki pratik girdisi vardır. CISA’nın KEV (Known Exploited Vulnerabilities) kataloğu, gerçek saldırılarda kullanıldığı doğrulanmış zafiyetleri listeler; bir CVE bu katalogdaysa öncelik tartışması biter, iş planlamaya döner. EPSS (Exploit Prediction Scoring System) ise bir zafiyetin yakın vadede istismar edilme olasılığını tahmin eden, düzenli güncellenen bir skordur.

İkisini birlikte okumak, listenin görünümünü kökten değiştirir:

• Yüksek CVSS + KEV kaydı → acil kulvara alınır, bakım penceresi beklenmez.
• Orta CVSS + yüksek istismar olasılığı → yüksek skorlu birçok bulgunun önüne geçer.
• Yüksek CVSS + istismarı zor, ön koşulu ağır → planlı yama takvimine bırakılır.
• Kanıtlanmış istismar + internete açık varlık → olay müdahale ekibi de bilgilendirilir.

Varlık kritikliği tanımlanmadan risk hesabı yapılamaz

Envanteri olmayan bir kurumda önceliklendirme kâğıt üzerinde kalır. ISO/IEC 27001:2022’nin teknik açıklıkların yönetimini ele alan kontrolü de bu nedenle önce varlık bilgisini şart koşar: neyin çalıştığını bilmeden neyin yamalanacağına karar verilemez. Pratikte varlıkları üç etikette toplamak yeterlidir: iş sürekliliğini doğrudan durduranlar, kimlik ve erişim altyapısını taşıyanlar, kişisel veri işleyenler.

Bu etiketleme, kurumsal siber güvenlik danışmanlığı çalışmalarının ilk çıktılarından biridir; çünkü envanter olgunlaşmadan kurulan her skorlama modeli, sonraki ay elle düzeltilen bir tabloya dönüşür. Etiketler kimlik yönetimi kayıtları, yapılandırma yönetimi veritabanı ve bulut etiketleriyle otomatik beslenmelidir.

Ağ konumu ve telafi edici kontroller sıralamayı nasıl değiştirir

Aynı zafiyetin dört farklı konumdaki karşılığı dört farklı önceliktir. İnternete bakan bir servis, kimlik doğrulaması olmadan erişilebilen bir yönetim arayüzü, segmentli üretim ağındaki bir sunucu ve çevrimdışı bir yedek sistem asla aynı kulvarda değerlendirilmez.

Telafi edici kontroller sıralamayı düşürebilir ama sıfırlamaz. Sanal yama (virtual patching), uygulama katmanında kural yazarak istismar denemesini engelleyebilir; yine de kalıcı çözüm değildir ve süreli bir istisna kaydıyla takip edilmelidir. Kontrolün gerçekten çalıştığı, üretim benzeri bir ortamda test edilerek doğrulanmalıdır.

Haftalık yama kuyruğunu kurma adımları

1. Tarama çıktısını varlık envanteriyle eşleştirin; sahibi belirsiz bulguları ayrı kuyruğa alın.
2. KEV kaydı bulunan ve internete açık varlıkta yer alan bulguları doğrudan acil kulvara taşıyın.
3. Kalan bulguları istismar olasılığı ve varlık kritikliği eksenlerinde iki boyutlu bir matrise yerleştirin.
4. Telafi edici kontrolleri kontrol edin ve etkisi doğrulananlarda bir seviye indirim uygulayın.
5. Her bulguya sahip, hedef tarih ve doğrulama yöntemi atayın; sahipsiz bulgu kapanmaz.
6. Yama sonrası taramayla kapanışı doğrulayın; sürüm numarası değişmediyse iş bitmemiştir.
7. Kapanmayan kalemleri risk kabul kaydına dönüştürün ve süre sonunda yeniden değerlendirin.

Öncelik seviyeleri ve hedef süreler

Aşağıdaki tablo, kurumların kendi kesinti pencerelerine göre uyarlayabileceği bir çerçeve sunar. Süreler sabit kurallar değil, yönetimle mutabık kalınıp yazıya dökülmesi gereken taahhütlerdir.

Yama uygulanamayan sistemlerde ne yapılır

Endüstriyel kontrol sistemleri, üretici desteği bitmiş uygulamalar ve kesinti penceresi olmayan hatlar her kurumda vardır. Buradaki hedef yamalamak değil, istismar edilebilirliği düşürmektir:

• Yönetim arayüzlerini ayrı bir ağ segmentine alın ve doğrudan erişimi kapatın.
• Erişimi kayıt altına alınan bir atlama sunucusu üzerinden zorunlu kılın.
• Protokol seviyesinde filtreleme uygulayarak beklenmeyen komutları engelleyin.
• Bu sistemlere özel tespit kuralları yazın ve istisnayı süreli tutun.

Bu sistemlerde beklenmeyen bir hesap oluşturma veya olağandışı bir dış bağlantı, uç nokta üzerindeki tek bulgudan daha güçlü bir sinyaldir.

Öncelik modelini saldırgan gözüyle doğrulamak

Bir öncelik modelinin doğru olup olmadığı, ancak gerçek bir saldırı zinciri denendiğinde anlaşılır. MITRE ATT&CK çerçevesiyle eşlenmiş bir tatbikat, hangi zafiyetin ilk erişimi verdiğini, hangisinin yanal hareketi (lateral movement) mümkün kıldığını ve hangisinin pratikte hiçbir işe yaramadığını gösterir. Keşiften raporlamaya uzanan beş aşamalı bir red team hizmetiyle çıkarılan saldırı zinciri, “listede 400. sıradaki bulgu aslında birinci sıradaymış” tespitini somut kanıtla ortaya koyar.

Bu doğrulama, bir sızma testinden farklı bir soruya yanıt verir. Sızma testi belirli bir sistemdeki teknik zafiyetleri 1-2 haftalık odaklı bir çalışmayla çıkarır; 2-6 haftaya yayılan bir kırmızı takım çalışması ise zafiyetlerin birbirine nasıl bağlandığını ve savunmanın bu zinciri hangi adımda gördüğünü ölçer. Öncelik modeli için ikincisi, listeyi yeniden sıralatacak veriyi üretir.

Sık sorulan sorular

Yama önceliklendirmede CVSS 7.0 eşiği yeterli mi?

Tek başına yeterli değildir. Bu eşik, istismar edilmekte olan orta seviyeli zafiyetleri kapsam dışında bırakırken, hiçbir zaman istismar edilmeyecek yüksek skorlu kalemleri ekibin gündemine sokar. Eşiği skorla değil, “doğrulanmış istismar” ve “varlık kritikliği” koşullarıyla birlikte tanımlamak gerekir.

KEV kataloğunda yer almayan bir zafiyet güvenli sayılır mı?

Hayır. KEV, istismar edildiği doğrulanmış zafiyetleri listeler; doğrulanmamış olması istismar edilmediği anlamına gelmez. Katalog bir alt sınırdır, üst sınır değildir; kendi sektörünüze yönelik tehdit istihbaratı ve istismar olasılığı skorları bu resmi tamamlar.

Yama sonrası doğrulamayı nasıl yapmalıyız?

Değişiklik kaydını kapatmadan önce aynı varlığı kimlik doğrulamalı taramadan geçirin ve sürüm bilgisini kontrol edin. Servis yeniden başlatılmadıysa ya da yalnızca ikili dosya güncellenip yapılandırma eski kaldıysa zafiyet açık kalmaya devam eder.

Sıfırıncı gün zafiyeti duyurulduğunda öncelik listesi nasıl değişir?

Yama yayımlanana kadar odak, üreticinin önerdiği geçici önlemler ve tespit kurallarıdır. Etkilenen sürümlerin envanterden hızlıca çıkarılabilmesi, bu senaryoda kazanılan zamanın tamamını belirler; bu nedenle envanter tazeliği kriz anında en değerli veridir.

Zafiyet taraması ile sızma testi aynı öncelik sırasını mı üretir?

Üretmez. Tarama, tek tek bulguları şiddetine göre listeler; sızma testi ise bu bulguların birleşiminden doğan gerçek erişim yollarını gösterir. İki çıktıyı birlikte okumak, teorik şiddeti yüksek ama etkisi sınırlı kalemleri geri plana atmayı kolaylaştırır.

Sonuç

Yama önceliklendirmesi bir skorlama değil, bir karar sürecidir: zafiyet verisini istismar gerçekliği, varlık kritikliği ve mevcut kontrollerle birleştirmeden üretilen her liste, ekibi meşgul eder ama riski azaltmaz. Envanterinizi etiketleyin, KEV ve istismar olasılığı verisini akışa katın, her bulguya sahip ve tarih yazın, sonucu saldırgan bakış açısıyla test edin; sıralamanız o zaman gerçek riski takip etmeye başlar.

Bilgilendirme: Bu içerik genel bilgilendirme amaçlıdır; kurumunuzun risk profiline özel değerlendirme için uzman desteği alınmalıdır.