Yirmi yıl boyunca NVD (Ulusal Güvenlik Açığı Veritabanı), güvenlik açığı yönetiminin fiili temeli olarak işlev gördü. Tarayıcılar, SIEM’ler, yama araçları ve uyumluluk çerçevelerinin tümü, bir CVE’nin NVD’de yayınlandığında NIST analistlerinin, ham CVE kimliğini gerçekten kullanışlı hale getiren ciddiyet puanlarını, ürün sürümü eşlemelerini ve bağlamsal meta verileri derhal ekleyeceği varsayımına dayanıyordu.
15 Nisan 2026'da bu varsayım resmi olarak geçerliliğini yitirdi.
NIST, NVD'nin risk temelli zenginleştirme modeline geçeceğini duyurdu. Veritabanına giren yeni CVE'lerin çoğu artık varsayılan olarak NIST tarafından eklenen CVSS puanı, CPE ürün eşlemesi ve bağımsız analiz almayacak. Güvenlik açığı iş akışları NVD tarafından zenginleştirilmiş verilere bağlı olan kuruluşlar için bu durum, gerçek ve giderek büyüyen bir kapsama sorunu yaratıyor. Bu verileri araçlarına entegre eden güvenlik ürünü geliştiricileri ve satıcıları için ise daha da keskin bir soru ortaya çıkıyor: Feed'iniz size şu anda tam olarak ne söylüyor?
NVD, Bildirilen Güvenlik Açıklarını Artık Takip Edemiyor
NIST’in kendi açıklamasına göre, CVE bildirimleri 2020 ile 2025 yılları arasında %263 arttı ve 2026’nın ilk çeyreğindeki bildirim sayısı, bir önceki yılın aynı dönemine kıyasla şimdiden neredeyse üçte bir oranında daha yüksek seviyedeydi.
NIST, 2025 yılında yaklaşık 42.000 CVE'yi zenginleştirdi; bu, önceki yıllara kıyasla %45'lik bir artışa tekabül ediyor. Ancak bu verimlilik artışı, artan bildirim sayısına ayak uydurmak için yeterli olmadı ve bunun sonucunda resmi bir önceliklendirme sistemi oluşturuldu.
15 Nisan 2026 tarihinden itibaren NIST, yalnızca CISA’nın KVE (Bilinen ve İstismar Edilen Güvenlik Açıkları) kataloğunda yer alan, federal hükümet tarafından kullanılan yazılımlar veya 14028 sayılı Başkanlık Kararnamesi kapsamında kritik olarak belirlenen yazılımlarla ilgili güvenlik açıklarını detaylandıracaktır. Diğer tüm güvenlik açıkları NVD’de listelenecek, ancak NIST tarafından detaylandırılmayacak ve hemen işleme alınmayacaktır.
Sonuç olarak, 1 Mart 2026 tarihinden önce yayınlanmış yaklaşık 300.000 adet birikmiş CVE, toplu olarak "Planlanmamış" kategorisine aktarılmıştır.
Bundan böyle, NIST’in öncelik kriterlerinin dışında kalan CVE’ler için, ciddiyet puanları artık bağımsız bir NIST analizinden ziyade, CVE Numaralandırma Otoritesi (CNA) tarafından bildirilen değerlere göre belirlenecektir; bu otorite genellikle etkilenen yazılımın satıcısıdır. Ayrıca NIST, bir CNA tarafından halihazırda bir ciddiyet puanı verilmiş olması durumunda, bu puanı yeniden hesaplamayacaktır.
Tüm önemli güvenlik açığı tarayıcıları, tüm SIEM korelasyon kuralları, tüm üçüncü taraf risk puanları ve PCI DSS'den FedRAMP'a kadar tüm yasal uyumluluk çerçeveleri, NVD zenginleştirme sürecine dayanmaktadır.
Bu güncellemeyle birlikte söz konusu süreç resmi olarak daraldı; bu durum, potansiyel olarak tehlikeli güvenlik açıklarının (CVE'ler) bu şekilde sınıflandırılmamasına veya zamanında tespit edilememesine yol açıyor.
Zenginleştirmedeki azalma, yapay zeka destekli tehdit tespitinin hızla yaygınlaşmasıyla çakıştığı için, dikkate alınması gereken bir başka hızlanma faktörü daha var.
Gelişmiş yapay zeka modelleri ve kodlama araçları, uygulamalardaki istismar edilebilir zayıflıkların ve karmaşık saldırı yollarının tespit edilmesindeki engelleri önemli ölçüde azaltmakta ve bu durum CVE bildirimlerinde ani bir artışa yol açmaktadır. Şubat 2026’da, Olay Müdahale ve Güvenlik Ekipleri Forumu (FIRST), 2026 yılında rekor kıran bir rakam olan 50.000 yeni CVE’nin bildirileceğini öngörmüştür. Mevcut zenginleştirme altyapısı, bu hacmi önceki kalite düzeylerinde yönetebilecek donanıma sahip değildir.
Neden Yalnızca NVD Üzerine Kurulu Ürünlerde Sorun Yaşanıyor?
Bir ham CVE kaydı genellikle bir kimlik numarası, bir açıklama ve referanslar içerir. Otomatik güvenlik açığı yönetimini yönlendiren meta veriler, geçmişte NVD analistleri tarafından sağlanıyordu. Bu veriler, bağımsız olarak doğrulanmış CVSS ciddiyet puanlarını, CPE ürün eşlemelerini ve CWE zayıflık sınıflandırmalarını ifade eder.
Ancak bir CVE'yi eyleme geçirilebilir kılan şey "zenginleştirmedir". Bu olmadan, buna bağlı iş akışları öngörülebilir şekillerde bozulur.
CVSS Temelli Önceliklendirme Etkisini Kaybediyor
Bir tarayıcı veya yama aracı, NVD tarafından sağlanan bir ciddiyet puanı beklerken böyle bir puan bulamadığında, söz konusu güvenlik açığı "ciddiyeti bilinmeyen" olarak görünür, SLA'ya dayalı yama politikalarının kapsamı dışında kalabilir veya önceliği düşebilir.
NIST'in Nisan 2026 tarihli güncellemesi şunu doğruladı:
- Yeni öncelik kriterlerinin dışında kalan CVE’ler otomatik olarak bağımsız puanlama almayacaktır
- Bir CNA zaten bir CVSS puanı sağlamışsa (bu CNA, etkilenen yazılımın satıcısı olsa bile), NIST artık kendi CVSS puanını oluşturmayacaktır
Zayıf veya Eksik CPE Eşlemesi, CVE Algılamasında Sorunlara Neden Olur
NVD'nin kendi belgelerinde, ürün tanımlama işleminin zenginleştirmenin temel bir parçası olduğu belirtilmektedir; zira bu, kullanıcıların bilinen bir güvenlik açığının kendi ortamlarındaki ürünleri etkileyip etkilemediğini programlı olarak kontrol etmelerine olanak tanır.
CPE eşleştirmeleri eksik, yetersiz veya gecikmişse, esas olarak CPE eşleştirmesine dayanan araçlar eşleşmeyi tespit edemeyebilir veya geç tespit edebilir.
Güvenlik ürünleri satıcıları, en çok etkilenenler arasında yer almaktadır; zira ürünleri genellikle CPE eşleştirmesine ve CVE zenginleştirmesine dayanmaktadır. Yama yönetimi, uç nokta koruması, ağ erişim kontrolü ve varlık yönetimi araçları, hangi sistemlerin etkilendiğini, sorunun ne kadar ciddi olduğunu ve bundan sonra hangi önlemlerin alınması gerektiğini belirlemek için doğru güvenlik açığı bilgilerine dayanmaktadır.
Yeni güvenlik ürünleri geliştiren ekipler için, yalnızca NVD'den yola çıkmak, halihazırda önemli eksikliklerin bulunabileceği bir temele dayanmak anlamına gelir: sınırlı sıfırıncı gün koruma kapsamı, giderek artan CVE payı için eksik veri zenginleştirme ve yapay zeka hızındaki güvenlik açığı keşfi ve istismarlarına ayak uydurmakta zorlanabilecek güncelleme döngüleri.
Halihazırda yama uygulama veya düzeltme yeteneklerine sahip ekipler için risk farklı olmakla birlikte, aynı derecede önemlidir. Bir düzeltme motorunun etkinliği, aldığı güvenlik açığı istihbaratının kalitesine bağlıdır. Bu istihbarat eksik, gecikmiş veya NVD kaynaklı zenginleştirmeye aşırı bağımlıysa, sonraki iş akışlarında etkilenen ürünler gözden kaçabilir, ciddiyeti bilinmeyen güvenlik açıklarına öncelik verilmeyebilir veya maruz kalma riski artmadan önce gerekli önlemler alınamayabilir.
Eğer bu ürünler NVD'nin zayıf yönlerini devralırsa, bu zayıf yönler tüm alt müşterilere de yansıyabilir.
OESIS Çerçeve Güvenlik Açığı Değerlendirmesi, tam da bu boşluğu doldurmak üzere tasarlanmıştır: güvenlik ürün ekiplerinin, yalnızca NVD verilerinin zenginleştirilmesine güvenmek yerine güvenlik açığı istihbaratını güçlendirmelerine yardımcı olmak.
OPSWAT Bu Konuya Farklı OPSWAT
OPSWAT , araçlarına güvenilir ve eyleme geçirilebilir güvenlik açığı verilerinin entegre edilmesini isteyen güvenlik ürünü geliştiricileri için özel olarak OESIS Framework Güvenlik Açığı Değerlendirme modülünü OPSWAT .
Boşluk Etrafında Tasarlanmış
Modül, tek bir kaynağa bağlı kalmak yerine birden fazla kaynağı bir araya getirir.
Yüzlerce satıcı ve uygulamayı kapsayan zamanında ve doğru bir kapsama sağlamak için çeşitli ticari ve açık kaynaklı güvenlik açığı kaynaklarından yararlanır.
OESIS güvenlik açığı kataloğu şu anda 65.000'den fazla benzersiz CVE'yi ve 150.000'den fazla güvenlik açığı örneğini kapsamaktadır ve NVD'nin işleme döngülerini beklemek yerine , günde birkaç kez olmak üzere sürekli olarak güncellenmektedir.
CVSS'nin ötesine geçen ve daha fazla bağlam bilgisi sunan tescilli bir ciddiyet puanı.
OPSWAT güvenlik açığı verileri, CVE popülerliği, istismar riski ve CVE yaşam döngüsü gibi ek göstergeleri de dikkate alarak CVSS temel puanının ötesine geçen, tescilli bir derecelendirme sistemi olan OPSWAT Puanını içerir.
CVSS puanlarının giderek artan bir kısmının CNA tarafından kendi beyanına dayalı olabileceği bir ortamda, bu bağımsız analiz katmanı, güvenlik ürünlerinin kullanıcılarına daha sağlam temellere dayanan bir önceliklendirme sinyali sunmasına yardımcı olabilir.
OESIS güvenlik açığı istihbaratı, karmaşık bir hazırlık süreci gerektirmeden iki farklı entegrasyon yolunu destekler:
- Katalog Beslemesi: OESIS güvenlik açığı verilerini, sunucu tarafında mevcut yazılım envanterinizle eşleştirin — uç nokta ajanı gerekmez. Yazılım envanterine sahip mevcut ürünler, OESIS verilerini kullanarak yönetilen varlıklardaki güvenlik açıklarını tespit edebilir.
- Endpoint (Software Kiti): Gerçek zamanlı, cihaz üzerinde vulnerability detection için OESIS Çerçevesini ürününüze doğrudan entegre edin. Uç noktada çalışan güvenlik ürünleri için son derece uygundur
İç güvenlik açıkları araştırması
OPSWAT iç tehdit araştırma ekibi Unit 515, kritik altyapı ve kurumsal yazılımlar kapsamında sürekli olarak saldırı odaklı güvenlik araştırmaları, saldırgan simülasyonlar, gelişmiş testler ve sorumlu ifşa çalışmaları yürütmektedir. Ekip, Delta PLC'ler gibi ICS/OT platformları ve yapay zeka tabanlı platformlar gibi yaygın olarak kullanılan yazılımlarda tespit edilen kritik bulgular da dahil olmak üzere 50'den fazla sıfır gün güvenlik açığını tespit etmiş ve raporlamıştır.
Bunun güvenlik ürünü geliştiricileri için net sonucu, NVD’nin veri zenginleştirme kapsamı daralsa bile araçlarının daha geniş bir güvenlik açığı kapsamını sürdürebilmesidir — üstelik müşterilerin daha sınırlı görünürlük veya manuel geçici çözümleri kabul etmelerine gerek kalmadan.
Tespit + Düzeltme: Tam Döngü
Tespit, hangi unsurların güvenlik açığına sahip olduğunu belirler. Düzeltme ise bu açıkları giderir. Bu iki süreç bir araya geldiğinde, risk döngüsünü mümkün olduğunca kapatmaya yardımcı olur. OESIS Güvenlik Açığı Değerlendirmesi, tespit ve önceliklendirme işlemlerini yürütür. OESIS Patch Management, her iki özelliği de tek bir çerçeve altında kullanmak isteyen ekipler için sunulmaktadır:
- Tespit: Güvenlik açığı bulunan uygulamalar, sürüm uyumlu, OPSWAT ve KEV tarafından işaretlenmiş
- Önceliklendirme: OPSWAT , gerçek hayattaki istismar sinyallerine dayanarak hangi sorunların öncelikle giderilmesi gerektiğini ortaya koyar
- Çözüm: Mevcut sisteminiz OESIS çıktısını işleyebilir — ya da OESIS Patch Management , yamaları Patch Management , sürümleri zorunlu kılabilir veya erişimi doğrudan engelleyebilir
- Doğrulama: OESIS, erişim yeniden sağlanmadan önce uç noktanın temiz olduğunu doğrulamak amacıyla düzeltme işleminden sonra yeniden tarama yapar
Tespit işlemi düzeltme olmadan sadece bir rapordur. Tespit ve düzeltme birlikte yapıldığında ise risk ortadan kalkmış olur. OESIS, ürününüze her ikisini de sunmayı hedefleyerek, AI hızındaki tehditlere daha iyi ayak uydurmak için tespit ve düzeltme döngülerinin daha hızlı tamamlanmasına yardımcı olur.
AI-Speed Güvenlik Açıkları, AI-Speed Tespiti Gerektirir
Güvenlik ürünleri, güvenlik açığı istihbaratını yavaş işleyen bir arka uç bağımlılığı olarak ele almaya devam edemez. CVE sayısının artması ve verilerin zenginleştirilmesinin tutarlılığının azalmasıyla birlikte, ürün ekipleri tespit, önceliklendirme ve düzeltme iş akışlarını gerçek dünyadaki maruz kalma durumlarıyla uyumlu tutmanın bir yolunu bulmalıdır.
İşte burada OESIS Çerçeve Güvenlik Açığı Değerlendirmesi devreye giriyor. Bu çözüm, ürün geliştiricilere uç nokta veya düzeltme altyapılarını sıfırdan yeniden kurmaya gerek kalmadan güvenlik açığı kapsamını güçlendirmeleri için pratik bir yol sunuyor. Yeni bir ürün piyasaya süren ekipler için, bu çözüm daha erken aşamada güvenilir bir kapsam oluşturmaya yardımcı olabilir. Mevcut bir ürünü geliştiren ekipler için ise, kapsamları karşılaştırmak, iyileştirmeleri doğrulamak ve daha derin entegrasyonun nasıl olması gerektiğine karar vermek için daha sorunsuz bir yol sunuyor.
