Zafiyet kaydı nasıl okunur? CVE'den yerel karara

Bir scanner kaydında aynı anda CVE kimliği, CWE numarası, CVSS skoru, exploit bilgisi ve düzeltme önerisi görebilirsin. Bu alanlar tek bir “risk puanı”nın parçaları değildir; farklı soruları yanıtlayan ayrı veri kaynaklarıdır. Profesyonel analiz, bu işaretleri birbirine karıştırmadan ürün ve yerel varlık kanıtıyla birleştirir.

En güvenli okuma alışkanlığı, önce kaydın neyi bildiğini, sonra neyi varsaydığını ayırmaktır. Scanner bir servis sürümünden eşleşme yapmış olabilir, yerel paket listesini okumuş olabilir veya yalnız bir HTTP cevabındaki işareti kullanmış olabilir. Aynı CVE etiketi, farklı kanıt kalitesine sahip sonuçlarda görünebilir.

CVE: ortak kimlik ve kayıt

CVE Programı, kamuya açıklanmış belirli zafiyetleri ortak kimlikle tanımlar. CVE-YYYY-NNNN... biçimindeki ID, farklı üretici bülteni, scanner ve veri tabanlarının aynı zafiyet hakkında konuşmasını sağlar. CVE ID'si tek başına skor, exploit veya yama değildir.

Published bir CVE kaydı en az açıklama, etkilenen ürün ve sürümler ile ilgili referansları içerir. Kayıt bir CVE Numbering Authority tarafından yayımlanır. RESERVED, henüz asgari ayrıntıları yayımlanmamış bir kimliği; REJECTED ise artık kullanılmaması gereken kaydı gösterir. Özellikle güncel olaylarda kayıt durumu ve son güncelleme tarihi kontrol edilmelidir.

Önce üretici adını, ürün ailesini, edition veya platformu ve etkilenen sürüm aralığını oku. Aynı isimli farklı ürün, cloud hizmeti ile on-premise sürüm veya backport uygulanmış Linux paketi eşleşmeyi değiştirebilir. Bir ürünün kurumda bulunması, otomatik olarak etkilenen sürümün bulunduğunu göstermez.

CWE: zayıflığın türü

Common Weakness Enumeration, zafiyetlere yol açabilen yazılım ve donanım zayıflık türlerini sınıflandırır. Örneğin bir CVE belirli ürün ve sürümdeki somut problemi gösterirken, ilgili CWE girdi doğrulama, sınır kontrolü veya yetki yönetimi gibi daha genel kök neden ailesini anlatabilir.

CWE düzeltme ekibine tasarım dilini kazandırır: yalnız tek CVE'yi kapatmak yerine aynı zayıflık sınıfının başka yerde tekrar edip etmediği araştırılabilir. Ancak “CWE-79 var” demek, uygulamada belirli bir XSS'nin doğrulandığı anlamına gelmez. CWE kimlik değil, sınıflandırmadır.

Okuma modeli

Beş alan, beş ayrı soru

CVE: Hangi yayımlanmış zafiyet? CWE: Hangi zayıflık türü? CVSS: Teknik şiddetin özellikleri ne? EPSS: Yakın dönemde sömürülme olasılığı ne? KEV: Doğada sömürü kanıtı var mı?

CVSS: teknik şiddeti vektörle anlatmak

FIRST CVSS v4.0, teknik özellikleri Base, Threat, Environmental ve Supplemental metrik gruplarıyla ifade eder. Sayı kadar vektörü de oku. Ağdan erişim, gerekli yetki, kullanıcı etkileşimi, saldırı koşulu ve gizlilik-bütünlük-erişilebilirlik etkileri aynı skora giden yolun nasıl kurulduğunu gösterir.

CVSS Base skoru makul en kötü teknik durumu ortak dille karşılaştırmaya yarar; kurumuna özgü risk puanı değildir. FIRST, Base ile Threat ve Environmental metriklerinin kullanıldığını belirtmek için CVSS-B, CVSS-BT, CVSS-BE ve CVSS-BTE adlandırmasını ayırır. Bu yüzden yalnız “9.8 critical” satırını okumak; varlığın gerçek maruziyetini, mevcut kontrolleri ve iş etkisini gözden kaçırır.

Scanner CVSS v3.1, üretici CVSS v4.0 kullanıyor olabilir. Skoru kopyalarken sürümü ve vektörü birlikte kaydet. Farklı sürümlerdeki sayıları doğrudan aynı ölçekmiş gibi karşılaştırma.

EPSS: zaman damgalı sömürü olasılığı

FIRST EPSS verisi, bir CVE'nin skor yayımlandıktan sonraki 30 gün içinde doğada sömürülme olasılığına ilişkin 0–1 arası tahmin sunar. percentile, skorun diğer CVE'lere göre konumunu gösterir. EPSS teknik etkiyi veya kurumundaki varlığın kritikliğini ölçmez.

EPSS günlük üretilir ve model sürümü zaman içinde değişebilir. Bu nedenle rapora yalnız değeri değil, sorgu tarihini de yaz. Yüksek EPSS hızlı doğrulama için güçlü bir sinyaldir; düşük EPSS ise internetten erişilebilen kritik bir kimlik sistemindeki zafiyeti otomatik olarak önemsiz yapmaz.

CISA KEV: gözlenmiş aktif sömürü

CISA Known Exploited Vulnerabilities Catalog, doğada sömürüldüğüne ilişkin kanıt bulunan CVE'leri yayımlar. KEV üyeliği tahmin değil, gözlenmiş sömürü sinyalidir ve önceliklendirmede güçlü ağırlık taşır. Katalogdaki due date alanları ABD federal sivil kurumları için bağlayıcı direktif bağlamına sahiptir; diğer kuruluşlar kendi SLA ve risk yönetimi sürecini uygular.

Bir CVE'nin KEV'de olmaması “sömürülmüyor” veya “güvenli” anlamına gelmez. Katalog belirli kabul ölçütlerine dayanan yaşayan bir listedir. Üyelik durumunu ve kontrol tarihini kaydet; statik raporda sonsuza kadar geçerli bir özellik gibi kullanma.

Kaydı yerel karara dönüştür

Bir scanner bulgusunu şu sırayla incele:

1. Kaynak: Plugin hangi kanıtı kullandı; banner, paket, dosya veya HTTP davranışı mı?
2. Eşleşme: Ürün, sürüm, platform ve yapılandırma resmi kayıttaki etkilenen aralıkla aynı mı?
3. Ön koşul: Ağ erişimi, yetki, kullanıcı etkileşimi veya belirli özellik gerekiyor mu?
4. Teknik etki: CVSS vektörü hangi güvenlik hedeflerinin etkilendiğini söylüyor?
5. Tehdit: Güncel EPSS tarihi ve KEV üyeliği ne gösteriyor?
6. Yerel bağlam: Varlık internete açık mı, kritik veri işliyor mu, telafi edici kontrol var mı?
7. Düzeltme: Üretici önerisi, sabit sürüm, geçici azaltım ve yeniden başlatma ihtiyacı ne?

Sonuç “critical” etiketini tekrar etmek değil, savunulabilir sonraki adımdır. Ürün eşleşmesi belirsizse doğrulama iste; KEV'de ve internete açık doğrulanmış varlıksa acil düzeltme yoluna al; etkilenen özellik kapalıysa kanıtla ve istisna süresini belirle; ürün mevcut değilse false-positive gerekçesini varlık kanıtıyla kaydet.

Bu yöntem otomasyonu reddetmez. Otomasyon verileri toplar ve eşler; analist ise kaynağın tarihini, kanıt kalitesini ve yerel bağlamı görünür tutarak kararın nedenini korur.