Yükleniyor...
Yükleniyor...
Her yıl on binlerce yeni CVE kaydı açılıyor. Hiçbir güvenlik ekibi bu listeyi baştan sona okuyamaz, okumasına da gerek yoktur. Anlamlı soru "bu hafta hangi zafiyetler yayımlandı" değil, "yayımlananların hangisi benim çalıştırdığım sürüme dokunuyor" sorusudur. Bu iki soru arasındaki mesafeyi kapatan şey, sürüm seviyesinde tutulan bir teknoloji envanteridir.
Kısa özet
Bir CVE'nin sizi ilgilendirmesi için envanterinizde o zafiyetten etkilenen sürümün çalışıyor olması gerekir. Sürüm bilgisi olmayan envanterde CVE eşlemesi gürültüye dönüşür; doğru zincir varlık, üzerinde çalışan teknoloji ve o sürümün zafiyetleri şeklinde kurulur.
Genel CVE veritabanı ile size temas eden CVE listesi aynı şey değildir
Genel CVE veritabanı bir kütüphanedir; sizi ilgilendiren CVE listesi ise o kütüphanenin yalnızca sizin raflarınızla kesişen kısmıdır. Aradaki fark büyüklük farkı değil, cins farkıdır: biri dünyada bilinen zafiyetleri, diğeri sizin maruziyetinizi anlatır.
Ekiplerin çoğu bu işi bugün iki uçtan biriyle yapıyor. Ya bültenleri takip edip "bizde var mı" diye tek tek soruyorlar — bu, envanteri her seferinde yeniden hatırlamayı gerektirir. Ya da bir tarayıcının ürettiği bulgu listesini alıp doğrudan bilete dönüştürüyorlar — bu da neyin neden orada olduğunu kaybettirir.
Rakamlar bu ayrımın pahalı olduğunu gösteriyor. Verizon 2026 DBIR'a göre zafiyet istismarı, on dokuz yılda ilk kez ilk erişim vektörleri arasında birinci sıraya yükseldi ve payı %31'e çıktı (önceki yıl %20). Kritik zafiyetlerin medyan giderme süresi 43 gün — önceki yıl 32 gündü. CISA KEV kataloğundaki, yani fiilen istismar edildiği bilinen zafiyetlerin tam kapatılma oranı ise %26'ya geriledi (önceki yıl %38). [1][2] Sorun, bilinmeyen zafiyetler değil; bilinen zafiyetlerin hangi sistemde durduğunun bilinmemesi.
Zinciri kurun: Assets → Technologies → CVEs
Kullanılabilir bir zafiyet görünümü tek bir listeden değil, üç halkalı bir zincirden doğar: hangi varlık var, o varlığın üzerinde ne çalışıyor, o sürümün hangi zafiyetleri var.
Ornis Recon bu üç halkayı ayrı modüller olarak tutar ve aralarındaki bağı korur:
Zincirin ortadaki halkası köprüdür. Assets tek başına "neyim var" sorusunu yanıtlar, CVEs tek başına "dünyada ne var" sorusunu. İkisini birbirine bağlayan tek şey teknoloji katmanıdır. Ornis Recon'un Investigations modülündeki graf de bu ilişkiyi aynı biçimde adlandırır: düğümler Asset (A), Technology (T), Exposure Item (E) ve Organization (O) olarak ayrılır, aralarındaki kenar "runs" etiketiyle çizilir — yani bir varlık bir teknolojiyi *çalıştırır*.
Bu köprü kurulmadığında iki tipik hata çıkar. Birincisi, gerçekte kullanılmayan bir bileşen için acil yama süreci başlatmak. İkincisi, envanterde görünmediği için hiç ele alınmayan bir sürümün aylarca ayakta kalması.
Sürüm tespiti belirleyicidir: `VENDOR` ve `VERSION` neden ayrı alanlarda durur
"openssh" demek bir zafiyet ifadesi değildir; 7.4 mü, 8.0 mı, 8.9p1 mi sorusunun yanıtı tamamen farklı CVE kümelerine karşılık gelir. Bu yüzden Technologies ekranında ürün adı, üretici ve sürüm tek bir metin alanında birleştirilmez.
Ayrı alan tutmanın üç pratik sonucu var:
Ornis Recon'un teknoloji tespiti dışarıdan, ajansız çalışır. Bu, dürüstlük gereği söylenmesi gereken bir sınırı da beraberinde getirir: dışarıdan görünmeyen bir bileşen bu listede yer almaz. Ekran, sunucunun kendi paket envanterinin yerine geçmez; dışarıya sızan sürüm izlerini toplar.
Technologies ekranında hangi alanlar var
Technologies ekranı, tespit edilen her ürün-sürüm çiftini tek satırda ve yanında hem risk hem de yayılım bilgisiyle gösterir. Böylece "ne kadar kötü" ile "kaç yerde" soruları aynı satırda yanıtlanır.
Ekrandaki filtreler Vendor, Criticality, Creation Method ve History başlıklarında toplanır. Creation Method, kaydın nasıl oluştuğunu ayırır; History ise pasifleştirilmiş kayıtları dahil etmeyi sağlar. Technologies ekranında Excel dışa aktarımı vardır.
Aynı ürünün farklı sürümleri neden ayrı satırlarda görünür
Ayrı satır, ayrı zafiyet kümesi demektir. Sürümleri tek satırda toplamak, farklı yama sorumluluklarını tek kutuya sıkıştırmak olur. Örnek bir demo ortamında ekran şu tabloyu üretiyor:
*(Yukarıdaki sayılar örnek bir demo ortamına aittir, gerçek müşteri verisi değildir.)*
Tabloda okunması gereken üç şey var. Birincisi, üç openssh satırının risk skoru aynı görünse de CVE sayıları farklı: 25, 23 ve 19. Aynı üründe kalmak ile aynı zafiyet yüküne katlanmak farklı şeylerdir. İkincisi, bu üç satır büyük ihtimalle farklı ekiplerin ve farklı bakım pencerelerinin sorumluluğundadır; tek satırda birleşirlerse hiçbiri sahiplenilmez. Üçüncüsü, ASSETS kolonu her satır için ayrı sayı verdiğinden, hangi sürümü yükseltmenin kaç sistemi birden kapatacağı doğrudan görülür — düzeltme sırasını çoğu zaman bu belirler.
Ömrünü doldurmuş yazılım: yama yoktur, tek çıkış sürüm yükseltmedir
`RISK SCORE` ile `CVES` sayısının birlikte tırmandığı satır, çoğu zaman destek dışı kalmış bir sürümü işaret eder. Demo tablosundaki php 5.4.16 satırı bunun tipik görüntüsüdür: risk 10.0, eşleşen CVE sayısı 220.
Bu tablo şu anlama gelir: sürüm yıllardır güvenlik güncellemesi almadığı için, yayımlanan her yeni zafiyet listeye eklenmiş ve hiçbiri düşmemiştir. Destek almayan bir sürümde "yamayı uygula" seçeneği yoktur; yama üretilmemektedir. Geriye üç seçenek kalır:
Bu satırların pratik değeri teknik olmaktan çok bütçeseldir. "220 CVE" sayısı, yükseltme talebini bir tercih olmaktan çıkarıp gerekçelendirilmiş bir kalem haline getirir.
CVEs ekranı: skorun kendisi kadar skorun bağlamı
CVEs ekranı zafiyet kaydının kendisini gösterir: `CVE ID`, görsel bir bar olarak `CVSS SCORE`, `SEVERITY`, `CVSS VERSION`, `PUBLISHED`, `LAST MODIFIED` ve `DESCRIPTION`. Severity filtresi ve CVE araması vardır. Bu ekranda Excel dışa aktarım butonu bulunmaz.
İki kolon, ilk bakışta gereksiz görünüp aslında yanlış karar önlediği için ayrı duruyor.
`CVSS VERSION` (2.0 / 3.x). CVSS 2.0 ile 3.x aynı ölçek değildir; metrikleri ve hesaplama mantığı farklıdır. 2.0'da hesaplanmış bir 10.0 ile 3.x'te hesaplanmış bir 9.8 doğrudan kıyaslanamaz, çünkü ikisi aynı soruyu aynı biçimde sormaz. [3] Bu kolon olmasa, tek bir sayı sütununa bakıp sıralama yapmak ve iki farklı ölçeği aynı cetvelde okumak kaçınılmaz olurdu. Kolonun görevi, kıyaslamayı yapmadan önce "hangi cetvel" sorusunu zorunlu kılmaktır.
`LAST MODIFIED`. Bir CVE kaydı yayımlandıktan sonra durağan değildir; açıklaması genişletilebilir, etkilenen sürüm aralığı düzeltilebilir, skoru yeniden hesaplanabilir. [4] Yalnızca PUBLISHED tarihine bakıp "bu eski, değerlendirmiştik" demek bu yüzden hatalıdır. İki tarihin arasının açık olduğu kayıtlar, daha önce verilmiş kararın tekrar bakılmayı hak ettiği kayıtlardır.
Önceliklendirmede üç katmanı birleştirin
CVSS tek başına bir önceliklendirme yöntemi değildir; ne kadar yaygın olduğunu ve gerçekten erişilebilir olup olmadığını söylemez. Ornis Recon'un iki ekranı, kararı üç katmanın kesişiminde kurmaya elverişlidir.
Üçüncü katman genellikle sıralamayı tersine çevirir. İnternete kapalı bir sistemdeki 9.8 ile internete açık, kimlik doğrulama ekranı dışarıya bakan bir sistemdeki 7.5 aynı aciliyette değildir. İkincisi bugünün işi, birincisi bu çeyreğin.
Sınırı da söylemek gerekir: CVEs ekranı CVSS tabanlı bir görünüm sunar, istismar olasılığını tahmin eden bir EPSS kolonu içermez. Fiilen istismar edilen zafiyetlerin ayrı bir katalogdan takibi ise ayrı bir disiplindir ve CISA'nın KEV kataloğu bu iş için açık bir kaynaktır. [5] Ornis Recon'un teknoloji ve CVE ekranları bu tür dış kaynakların yerini almaz; hangi sürümün kurumda çalıştığını söyleyerek onları uygulanabilir kılar.
Sıkça sorulan sorular
Sürüm bilgisi olmadan CVE takibi yapılabilir mi?
Yapılabilir ama sonucu güvenilir olmaz. Sürüm alanı boş olan bir kayıt için eşleme ya ürünün tüm zafiyet geçmişini listeler ya da hiç kurulamaz. İkisi de yanlış: biri gereksiz iş üretir, diğeri gerçek riski gizler.
Aynı ürünün farklı sürümleri neden tek satırda birleştirilmiyor?
Çünkü ayrı sürüm ayrı zafiyet kümesi demektir. Demo ortamındaki openssh 7.4, 8.0 ve 8.9p1 satırları sırasıyla 25, 19 ve 23 CVE ile eşleşiyor. Birleştirme, farklı ekiplerin farklı yama sorumluluklarını tek kutuya sıkıştırır ve hiçbirini sahiplendirmez.
`RISK SCORE` yüksekse hemen müdahale etmeli miyim?
Tek başına yeterli sinyal değildir. Skorun yanında ASSETS sayısına, CRITICALITY alanına ve bileşenin dışarıdan gerçekten erişilebilir olup olmadığına bakın. İnternete kapalı bir sistemdeki yüksek skor, açık bir sistemdeki orta skordan sonra gelebilir.
CVSS 2.0 ile 3.x skorlarını neden karşılaştıramıyorum?
İki sürüm farklı metrikler ve farklı hesaplama mantığı kullanır. 2.0'daki 10.0 ile 3.x'teki 9.8 aynı cetvelin iki noktası değildir. CVSS VERSION kolonu tam da bu yanlış kıyaslamayı engellemek için ayrı durur; sıralama yapmadan önce hangi ölçekte olduğunuzu görürsünüz.
`LAST MODIFIED` tarihine niçin bakmam gerekiyor?
Bir CVE kaydı yayımlandıktan sonra güncellenebilir: skoru yeniden hesaplanabilir, etkilenen sürüm aralığı düzeltilebilir. Yalnızca yayım tarihine bakıp "eski, değerlendirmiştik" demek bu nedenle risklidir. İki tarih arasında fark varsa kayıt yeniden okunmayı hak eder.
Ömrünü doldurmuş bir sürüm için yama yoksa ne yapmalıyım?
Kalıcı çözüm sürüm yükseltmedir; destek dışı bir üründe yama üretilmez. Ara çözüm olarak erişimi daraltmak riski azaltır, ortadan kaldırmaz. Üçüncü seçenek olan risk kabulü ise yazılı, süreli ve sahibi belli olduğunda anlamlıdır.
