Yama yönetimi: güvenlik güncellemelerini ertelemek şirketinizi nasıl riske atıyor?

Yama yönetimi, sistemlerinizde çalışan yazılımlardaki güvenlik açıklarını düzenli olarak tespit edip üreticinin yayımladığı güncellemeleri (yamaları) saldırganlardan önce uygulama disiplinidir. Neden ihmal edilmemeli? Verizon'un 2026 Veri İhlali Araştırma Raporu'na (DBIR) göre yamalanmamış açıkların istismarı, saldırganların şirketlere sızmakta kullandığı bir numaralı yöntem oldu; raporun 19 yıllık tarihinde ilk kez çalınan parolaları geçti. Kısa cevap şu: güncellemeyi ertelemek, en pahalıya patlayan tasarruftur. Ama işin zor tarafı da var, çünkü çıkan her açığı aynı gün kapatmak imkânsız. Asıl mesele hangi açığı önce kapatacağınızı bilmektir.

Sorun: açık sayısı artıyor, kapatma hızı düşüyor

2024'te açık veri tabanı NVD'ye 40 binden fazla yeni güvenlik açığı (CVE) kaydedildi. Bu, bir önceki yıla göre yaklaşık %39'luk artış ve günde ortalama 108 yeni açık demek. Bu hacim güvenlik ekiplerini boğuyor. Aynı DBIR raporu tabloyu net gösteriyor: kuruluşlar, gerçekten istismar edildiği bilinen kritik açıkların yalnızca %26'sını tam olarak kapatabiliyor; bu oran bir yıl önce %38'di. Medyan yama süresi de 32 günden 43 güne çıktı. Yani açıklar birikirken onları kapatma hızımız geriliyor, ve bu makas tam da saldırganın ihtiyacı olan şey.

Yama vardı ama uygulanmadı: WannaCry

En çarpıcı örnek, kayıtlara geçen en yıkıcı fidye yazılımı saldırılarından WannaCry'dır. Microsoft, solucanın kullandığı SMB açığını kapatan MS17-010 yamasını 14 Mart 2017'de yayımladı. WannaCry ise 12 Mayıs 2017'de patladı ve 72 saat içinde 150 ülkede 300 binden fazla sistemi kilitledi. Tarihlere dikkat edin: yama, saldırıdan tam iki ay önce hazırdı. Dünya, ortada bir çözüm olmadığı için değil, o çözümü uygulamadığı için yandı. Sorun teknik bir eksiklik değildi; görünürlük ve süreç eksikliğiydi.

Bir sistemi atlamanın bedeli: Equifax

İkinci ders Equifax'tan geliyor. Apache Struts adlı web çatısındaki CVE-2017-5638 açığı 7 Mart 2017'de duyuruldu ve yaması aynı gün yayımlandı. Equifax bu yamayı sistemlerinin tümüne uygulamadı; birkaç gün sonra saldırganlar açığı şirketin çevrimiçi itiraz portalından istismar etmeye başladı. Aylarca ağ içinde ilerlediler ve 147 milyon kişinin sosyal güvenlik numarası, doğum tarihi ve adres bilgisi dışarı sızdı. Equifax sonrasında yaklaşık 700 milyon dolarlık bir uzlaşmayı kabul etti. Yamanın var olması yetmez; her sistemde uygulandığını doğrulamazsanız, atladığınız tek sunucu kapıyı açık bırakır.

Pencere saatlere indi: Log4Shell

Eskiden yama ile ilk istismar arasında haftalar vardı; bugün bu pencere saatlere indi. Log4Shell (CVE-2021-44228) bunun kanıtı. 9 Aralık 2021'de açıklanan ve 10 üzerinden 10 puanla en yüksek kritiklik notunu alan açık, duyurulduğu ilk saatlerde internet çapında taranmaya ve istismar edilmeye başlandı. Java dünyasında neredeyse her yerde kullanılan bir günlükleme kütüphanesini etkilediği için yüz milyonlarca cihaz risk altındaydı; Mirai botneti ve Conti fidye çetesi çok kısa sürede açığı kullanmaya başladı. Log4Shell aynı zamanda yazılım tedarik zinciri riskinin ders kitabı örneğidir: kimsenin bilerek seçmediği bir bileşenden miras kalan bir açık. DBIR 2025 bir uyarı daha ekliyor: uç cihazlardaki (VPN, güvenlik duvarı gibi internete bakan kutular) sıfırıncı gün açıkları, tüm açık istismarı olaylarının %22'sini oluşturdu; bir yıl önce bu oran %3'tü. İnternete açık cihazlarda gecikmenin lüksü kalmadı.

Hepsini yamalayamazsınız: doğru önceliklendirme

Günde 108 açık çıkarken hepsini birden kapatmak mümkün değil, gerekli de değil. İşin sırrı önceliklendirmede. Çoğu ekip yalnızca CVSS puanına bakar. CVSS, bir açığın istismar edilirse ne kadar ciddi olacağını 0 ile 10 arasında ölçer; ama gerçekten istismar edilip edilmeyeceğini söylemez, ve "kritik" etiketli açıkların büyük kısmı hiçbir zaman vahşi doğada kullanılmaz. İki ek sinyal tabloyu değiştirir. Birincisi CISA KEV listesi: gerçekten istismar edildiği kanıtlanmış açıkların herkese açık, ücretsiz kataloğu. İkincisi EPSS: bir açığın önümüzdeki 30 günde istismar edilme olasılığını tahmin eden puan. EPSS puanı %10'un altında olan açıkların %96'sı istismar edilmedi. Pratik kural: KEV'de yer alan, internete açık ve EPSS'i yüksek açıkları önce kapatın.

CISA KEV: ücretsiz öncelik filtresi

ABD siber güvenlik ajansı CISA, 2021'de yayımladığı BOD 22-01 direktifiyle federal kurumlara KEV listesindeki açıkları belirli sürede (çoğu için 14 gün) kapatma zorunluluğu getirdi. Haziran 2026'da bunu BOD 26-04 ile güncelledi: artık sabit süre yerine risk temelli kademeli bir model var ve internete açık, otomatikleştirilebilir ve aktif istismar edilen açıklar için süre yalnızca üç gün. Bu zorunluluk yalnızca ABD kamu kurumlarını bağlar. Ama KEV listesi herkese açıktır ve şirketiniz için bedava bir "önce bunları kapat" filtresi olarak kullanılabilir. Bir açık bu listeye girdiyse, teoride ne kadar ciddi olduğunu tartışmayı bırakıp yamayı planlamanın vaktidir.

Pratikte iyi bir yama süreci

İyi bir yama yönetimi altı adımdan oluşur. Önce envanter: neyin, nerede ve hangi sürümde çalıştığını bilmeden yamalama yapamazsınız (WannaCry'daki asıl sorun buydu). İkincisi kaynak takibi: üretici güvenlik bültenlerini ve KEV listesini düzenli izleyin. Üçüncüsü önceliklendirme: KEV, internete açıklık ve EPSS'e göre sıralayın. Dördüncüsü test ve bakım penceresi: kritik yamaları önce sınırlı bir ortamda deneyin, sonra planlı bir pencerede yayına alın. Beşincisi doğrulama: yamanın gerçekten ve tüm sistemlere uygulandığını kontrol edin. Altıncısı destek sonu (EOL) yazılımlar: yama gelmeyen eski işletim sistemleri ve kütüphaneler için tek çözüm değiştirmektir, çünkü onlar için bir daha güncelleme çıkmayacak.

Sık yapılan hatalar

Birkaç alışkanlık iyi niyetli bir ekibi bile açık bırakır. En yaygını "çalışıyorsa dokunma" deyip güncellemeleri süresiz ertelemektir. İkincisi yalnızca sunucuları ve bilgisayarları düşünüp güvenlik duvarını, yönlendiriciyi, yazıcıyı ve IoT cihazlarını unutmaktır; saldırılar giderek bu internete bakan cihazlardan giriyor. Üçüncüsü, bozulma korkusuyla üretim sistemlerini hiç yamamak ve riski büyütmektir. Dördüncüsü Equifax'ın hatası: yamayı bir yerde uygulayıp diğer sistemlerde eksik bırakmak. Beşincisi, desteği bitmiş yazılımı çalıştırmaya devam etmektir; eski bir Windows sürümü ya da güncellenmeyen bir PHP, OWASP Top 10'un "güvenlik açığı olan ve güncelliğini yitirmiş bileşenler" dediği şeydir: kapalı sandığınız ama sonsuza dek açık kalan bir kapı.

Yama yönetimi, en ucuz ve en çok ihmal edilen siber güvenlik yatırımıdır; çünkü çoğu ihlal sıfırıncı gün açıklarından değil, aylardır yaması bekleyen bilinen açıklardan geçer. Wedevit olarak sistem envanterinizi çıkarır, internete açık varlıklarınızı ve üzerlerinde çalışan sürümleri haritalar, KEV ile EPSS temelli bir önceliklendirme kurar, yama ve bakım penceresi süreci tasarlar, destek sonu sistemlerinizi tespit ederiz. Yama yönetimi tek başına bir çözüm değil, her erişimi yeniden doğrulayan sıfır güven (zero trust) yaklaşımının bir katmanıdır. Somut ilk adım: internete açık sistemlerinizin bir listesini çıkarmak ve her birinin yanına üzerinde çalışan yazılımın sürümünü yazmak, çünkü göremediğiniz sunucuyu yamalayamazsınız.