Güncel Güvenlik Açıklarını İzlerken CVE Listesi Yetmez

Bir güvenlik açığı duyurulduğunda ilk refleks genellikle CVE numarasına, önem derecesine ve CVSS skoruna bakmak oluyor. Bu bilgiler gerekli. Fakat tek başına yeterli değiller.

16 Temmuz 2026 itibarıyla yayımlanan güncel güvenlik duyurularına bakınca aynı tablo tekrar görülüyor: tarayıcı ve işletim sistemi bileşenlerinde çok sayıda bellek güvenliği açığı kapatılıyor; bazıları kritik, bazıları yüksek önem derecesinde sınıflandırılıyor. Google, ChromeOS LTS-144 güncellemesinde Web Authentication, Aura, Extensions, GPU ve DOM gibi bileşenlerdeki açıkları düzeltti. Duyuruda iki açık kritik, diğerleri yüksek önem derecesinde listeleniyor. (chromereleases.googleblog.com)

Bu tablo bize yalnızca “kaç açık var?” sorusunun değil, “hangi katmanda ve hangi kullanım biçiminde etkileniyoruz?” sorusunun da önemli olduğunu gösteriyor.

Kritik etiketi tek başına karar verdirmez

CVSS, bir açığın teknik etkisini ortak bir ölçek üzerinde anlatmaya yarar. Ancak CVSS skoru, sizin sisteminizdeki gerçek maruziyeti otomatik olarak hesaplamaz.

Örneğin bir açık tarayıcının Web Authentication bileşeninde bulunabilir. Bu açık, güncel sürümü kullanan milyonlarca kullanıcı için önemlidir. Fakat bir kurumda etkiyi belirleyecek başka sorular vardır:

• Kullanıcılar hangi tarayıcı sürümünü çalıştırıyor?
• Güncelleme merkezi olarak dağıtılabiliyor mu?
• Etkilenen özellik gerçekten kullanılıyor mu?
• Tarayıcı, hassas oturumlara ve yönetim panellerine erişmek için kullanılıyor mu?
• Açığın kötüye kullanıldığına dair doğrulanmış bir işaret var mı?

Bu soruların bazıları CVE kaydında bulunmaz. Varlık envanteri, uç nokta telemetrisi, güvenlik ürünleri ve üretici duyuruları birlikte değerlendirilmelidir.

CVSS teknik önceliği anlatır; işletme önceliğini değil.

“Aktif olarak sömürülüyor” bilgisi neden daha değerlidir?

CISA’nın Known Exploited Vulnerabilities kataloğu, saldırılarda kullanıldığı bilinen açıkları ayrı bir listede topluyor. CISA bu kataloğun güvenlik açığı önceliklendirmesinde girdi olarak kullanılmasını öneriyor. Bu yaklaşım, yalnızca teorik etkiden ziyade sahadaki saldırı sinyalini dikkate alıyor. (cisa.gov)

Bu, katalogda bulunan her açığın her kurum için otomatik olarak birinci sıraya alınacağı anlamına gelmez. Yine de aktif sömürü bilgisi, önceliği belirgin biçimde yükselten bir sinyaldir.

Bir açığın değerlendirilmesinde şu ayrımı yapmak faydalı:

Sinyal	Ne anlatır?	Kararı nasıl etkiler?
CVSS	Teknik etkinin şiddetini	Genel teknik önceliği gösterir
Üretici yaması	Düzeltmenin kullanılabilir olduğunu	Güncelleme planını mümkün kılar
KEV kaydı	Gerçek saldırılarda kullanım kanıtını	Önceliği yükseltir
Varlık maruziyeti	Sizin sisteminizin etkilenip etkilenmediğini	Uygulanacak kapsamı belirler
Sürüm ve yapı bilgisi	Açığın gerçekten mevcut olup olmadığını	Yanlış alarmı azaltır

Buradaki son iki satır çoğu ekipte gözden kaçıyor. Bir açık çok ciddi olabilir; fakat etkilenmeyen bir sürüm kullanıyorsanız aynı aciliyet söz konusu değildir. Tersi de geçerli: Orta önem derecesindeki bir açık, internete açık ve yüksek ayrıcalıklı bir bileşende bulunuyorsa pratikte daha hızlı ele alınabilir.

Açık önceliklendirme eksenleri

Temmuz güncellemeleri bize ne söylüyor?

Google’ın 7 Temmuz 2026 tarihli Chrome masaüstü duyurusu, Windows ve Mac için 150.0.7871.100/.101, Linux için 150.0.7871.100 sürümünün dağıtıma çıktığını belirtiyor. Duyurunun kendisi güvenlik düzeltmelerinin ayrıntılarını listelemiyor ve tam değişiklik listesini Chromium kayıtlarına yönlendiriyor. (chromereleases.googleblog.com)

Bu ayrıntı küçük görünebilir ama operasyon açısından önemlidir. Bir üretici “güncelleme yayımlandı” dediğinde, ekiplerin yalnızca haber başlığını okumaması gerekir. Hangi kanalın etkilendiği, sürümün kademeli dağıtılıp dağıtılmadığı ve ayrıntılı düzeltme listesinin nerede bulunduğu kontrol edilmelidir.

ChromeOS LTS-144 duyurusu ise daha açıklayıcıdır. CVE-2026-8514 ve CVE-2026-12443 kritik; CVE-2026-12467, CVE-2026-13029, CVE-2026-12033, CVE-2026-11673, CVE-2026-11668, CVE-2026-10006, CVE-2026-9931 ve CVE-2026-9897 yüksek önem derecesinde listeleniyor. Duyuruda bunların bir bölümü use-after-free, out-of-bounds read, race ve uninitialized use sınıflarıyla tanımlanıyor. (chromereleases.googleblog.com)

Bu sınıflar, özellikle tarayıcı gibi karmaşık ve dış girdiyi işleyen yazılımlarda bellek güvenliğinin hâlâ büyük bir sorun alanı olduğunu gösteriyor. Ancak üretici duyurusu, her açığın nasıl sömürüldüğünü veya saldırı zincirinde hangi koşulların gerektiğini söylemiyorsa, bunları olduğundan daha kesin bir dille yorumlamamak gerekir.

Bir CVE’nin teknik adı, saldırının tamamını anlatmaz.

Ekipler neyi ölçmeli?

Güvenlik açığı yönetimini yalnızca “yama çıktı mı?” sorusuna indirmek yerine daha küçük ama düzenli bir karar döngüsü kurmak daha sağlıklı olur.

Önce etkilenen ürün ve sürümler varlık envanteriyle eşleştirilir. Ardından internete açıklık, ayrıcalık seviyesi, kullanıcı yoğunluğu ve hassas veriye erişim gibi bağlamlar eklenir. Son olarak aktif sömürü sinyali, üretici önerisi ve güncellemenin uygulanabilirliği birlikte değerlendirilir.

Bu süreçte ölçülebilecek birkaç pratik gösterge var:

• Etkilenen varlıkların kaçının bilindiği
• Kritik ve KEV kapsamındaki açıkların ne kadar sürede kapatıldığı
• Güncellenemeyen sistemlerin kaçının geçici önlemle korunduğu
• Eski sürümlerin ve internet-facing varlıkların sayısı
• Güncelleme sonrasında hizmet kesintisi veya uyumluluk sorunu oluşup oluşmadığı

Özellikle son madde önemlidir. “En hızlı yamalayan ekip” olmak tek başına güvenlik başarısı değildir. Yanlış sürüm dağıtmak, bazı sistemleri envanter dışında bırakmak veya güncellenemeyen varlıkları görünmez saymak daha büyük bir risk yaratabilir.

Güvenlik açığı yönetiminin amacı bütün CVE’leri aynı anda çözmek değil, gerçek saldırı ihtimali ile gerçek varlık maruziyetini doğru eşleştirmektir.

Bugün için daha doğru öncelik sırası

16 Temmuz 2026’daki tabloya bakarken tek bir “en tehlikeli açık” seçmek yanıltıcı olur. Çünkü güncel risk, ürün sürümüne ve sistemin kullanım biçimine göre değişir.

Daha sağlam bir sıralama şöyle kurulabilir:

1. Aktif olarak sömürüldüğü doğrulanan ve sizin ortamınızda bulunan açıklar
2. İnternete açık, yüksek ayrıcalıklı veya kimlik doğrulama altyapısına yakın bileşenlerdeki açıklar
3. Üreticinin kritik olarak sınıflandırdığı ve kolayca güncellenebilen ürünler
4. Kullanılmayan ya da erişimi kısıtlı bileşenlerdeki açıklar
5. Etkilenmeyen sürümlerle karıştırılan veya yalnızca başlıkta görülen kayıtlar

Bu yaklaşım, güvenlik haberlerini küçümsemiyor. Tam tersine, haber ile operasyon arasında bir doğrulama katmanı kuruyor.

Güncel açıkları takip eden ekiplerin işi yalnızca yeni CVE’leri toplamak değil. Üretici duyurusunu okumak, sürüm bilgisini doğrulamak, aktif sömürü sinyalini kontrol etmek ve kendi varlıklarının gerçekten etkilenip etkilenmediğini bilmek zorundalar.

Güvenlikte hız önemli. Fakat doğru varlığı, doğru nedenle ve doğru sürüme güncellemek daha önemli.