Két évtizeden át az NVD (National Vulnerability Database) jelentette a sebezhetőségkezelés tényleges alapját. A szkennerek, a SIEM-rendszerek, a javítóprogram-kezelő eszközök és a megfelelőségi keretrendszerek mind abból a feltételezésből indultak ki, hogy amikor egy CVE-azonosító megjelenik az NVD-ben, a NIST elemzői haladéktalanul hozzáadják azokat a súlyossági besorolásokat, termékverzió-társításokat és kontextusbeli metaadatokat, amelyek a nyers CVE-azonosítót valóban használhatóvá teszik.
2026. április 15-én ez a feltételezés hivatalosan is megbízhatatlanná vált.
A NIST bejelentette, hogy az NVD átáll egy kockázatalapú kiegészítési modellre. A legtöbb, az adatbázisba bekerülő új CVE alapértelmezés szerint már nem kap NIST által hozzáadott CVSS pontszámot, CPE termékmapozást és független elemzést. Azoknál a szervezeteknél, amelyek sebezhetőségi munkafolyamatai az NVD által kiegészített adatokra támaszkodnak, ez valódi és egyre növekvő lefedettségi problémát jelent. Azoknál a biztonsági termékfejlesztőknél és -forgalmazóknál, akik ezeket az adatokat beépítik eszközeikbe, ez még élesebb kérdést vet fel: pontosan mit is mond most az Önök feedje?
Az NVD már nem képes lépést tartani a bejelentett biztonsági résekkel
A NIST saját közleménye szerint a CVE-bejelentések száma 2020 és 2025 között 263%-kal nőtt, és 2026 első negyedévében már közel harmadával haladta meg az előző év azonos időszakának értékét.
A NIST 2025-ben közel 42 000 CVE-t dolgozott fel, ami 45%-os növekedést jelent az előző évekhez képest. Ez a megnövekedett termelékenység azonban nem volt elegendő ahhoz, hogy lépést tartson a beérkező bejelentések számának növekedésével, ezért hivatalos triázsrendszert vezettek be.
2026. április 15-től a NIST kizárólag azokat a sebezhetőségeket fogja kiegészítő adatokkal ellátni, amelyek szerepelnek a CISA KVE (Known Exploited Vulnerabilities, azaz ismert, kihasznált sebezhetőségek) katalógusában, a szövetségi kormány által használt szoftverekben, illetve az 14028. számú elnöki rendelet alapján kritikusnak minősített szoftverekben. Minden egyéb sebezhetőséget felvesznek az NVD-be, de a NIST által hozzáadott kiegészítő adatok nélkül, és azokat nem dolgozzák fel azonnal.
Ennek következtében a 2026. március 1. előtt közzétett, felhalmozódott közel 300 000 CVE-t egy csapásra áthelyezték a „Nem ütemezett” kategóriába.
A jövőben a NIST prioritási kritériumainak nem megfelelő CVE-k esetében a súlyossági besorolás nem a NIST független elemzésén alapul majd, hanem azon az értéken, amelyet a CVE-számozási hatóság – gyakran az érintett szoftver gyártója – saját maga jelentett be. A NIST emellett nem fogja újraszámolni a súlyossági besorolást, ha a CNA már megadott egyet.
Minden jelentős sebezhetőség-ellenőrző eszköz, minden SIEM-korrelációs szabály, minden harmadik féltől származó kockázati értékelés, valamint a PCI DSS-től a FedRAMP-ig terjedő összes szabályozási megfelelési keretrendszer az NVD kiegészítő adatfeldolgozási folyamatára támaszkodik.
A frissítéssel ez a folyamat hivatalosan is szűkült, ami azt eredményezi, hogy a potenciálisan veszélyes biztonsági sebezhetőségek nem kerülnek megfelelően nyilvántartásba, illetve nem fedezik fel őket időben.
Van még egy további gyorsító tényező, amelyet érdemes megérteni, mivel az információk mennyiségének csökkenése egybeesik a mesterséges intelligenciával támogatott fenyegetésfelismerés gyors elterjedésével.
A fejlett mesterséges intelligencia modellek és kódolási eszközök jelentősen csökkentik az alkalmazásokban kihasználható sebezhetőségek és összetett támadási útvonalak felismerésének nehézségeit, ami a CVE-bejelentések számának ugrásszerű növekedését eredményezi. 2026 februárjában az Incident Response and Security Teams (FIRST) fórum előrejelzése szerint 2026-ban rekordszámú, további 50 000 CVE-bejelentésre lehet számítani. A jelenlegi adatgazdagítási infrastruktúra nem képes ezt a mennyiséget a korábbi minőségi színvonalon kezelni.
Miért jelent problémát a kizárólag az NVD-re épülő termékek esetében?
A nyers CVE-bejegyzés általában tartalmaz egy azonosítót, egy leírást és hivatkozásokat. Az automatizált sebezhetőségkezelést irányító metaadatok eddig az NVD elemzőitől származtak. Ezek az adatok függetlenül validált CVSS-súlyossági pontszámokra, CPE-termékleképzésekre és CWE-sebezhetőségi osztályozásokra vonatkoznak.
De a „kiegészítés” az, ami a CVE-t feldolgozhatóvá teszi. Enélkül az erre épülő munkafolyamatok előre látható módon romlanak.
A CVSS-alapú prioritásrendezés gyengíti
Ha egy szkennelőprogram vagy javításkezelő eszköz az NVD által megadott súlyossági besorolást vár, de nem talál ilyet, akkor a sebezhetőség „ismeretlen súlyosságúként” jelenhet meg, kikerülhet az SLA-alapú javítási szabályzatok hatálya alól, vagy háttérbe szorulhat.
A NIST 2026. áprilisi frissítése megerősítette, hogy:
- Az új prioritási kritériumoknak nem megfelelő CVE-k nem kapnak automatikusan független értékelést
- A NIST a jövőben nem állít elő saját CVSS-pontszámot, ha egy CNA már megadott egyet (még akkor sem, ha az adott CNA az érintett szoftver gyártója)
A hiányos vagy nem megfelelő CPE-leképezés a CVE-felismerés pontatlanságát eredményezi
Az NVD saját dokumentációja a termékazonosítást a kiterjesztés alapvető elemének tekinti, mivel ez lehetővé teszi a felhasználók számára, hogy programozási úton ellenőrizzék, hogy egy ismert sebezhetőség érinti-e a környezetükben található termékeket.
Ha a CPE-leképezések hiányoznak, hiányosak vagy késnek, akkor az elsősorban a CPE-egyeztetésre támaszkodó eszközök esetleg nem jelzik az egyezést, vagy csak késve jelzik azt.
A biztonsági termékek gyártói tartoznak a leginkább érintettek közé, mivel termékeik gyakran a CPE-megfeleltetésre és a CVE-adatbázis kiegészítésére támaszkodnak. A javításkezelő, a végpontvédelmi, a hálózati hozzáférés-vezérlő és az eszközkezelő eszközök pontos sebezhetőségi információkra támaszkodnak annak megállapításához, hogy mi érintett, milyen súlyos a probléma, és milyen lépéseket kell tenni a továbbiakban.
Azok számára, akik új biztonsági termékeket fejlesztenek, ha kizárólag az NVD-re támaszkodnak, az azt jelenti, hogy olyan alapokra építenek, amelyekben máris létezhetnek komoly hiányosságok: korlátozott zero-day lefedettség, a CVE-k egyre növekvő hányadának hiányzó kiegészítő adatai, valamint olyan frissítési ciklusok, amelyek aligha tudnak lépést tartani a mesterséges intelligencia által biztosított sebességű sebezhetőségek felfedezésével és kihasználásával.
Azoknál a csapatoknál, amelyek már rendelkeznek javítás- vagy hibaelhárítási képességekkel, a kockázat más jellegű, de ugyanolyan fontos. A hibaelhárítási rendszer hatékonysága attól függ, hogy milyen minőségű sebezhetőségi információkat kap. Ha ezek az adatok hiányosak, késedelmesek vagy túlzottan támaszkodnak az NVD-ből származó kiegészítő információkra, akkor a további munkafolyamatok során előfordulhat, hogy nem veszik észre az érintett termékeket, nem kezelik megfelelő prioritással az ismeretlen súlyosságú sebezhetőségeket, vagy nem lépnek fel időben, mielőtt a kockázat fokozódna.
Ha ezek a termékek átveszik az NVD gyenge pontjait, akkor azok minden további felhasználóhoz eljuthatnak.
Az OESIS Framework sebezhetőségi értékelési rendszer éppen ezt a hiányosságot hivatott pótolni: célja, hogy segítse a biztonsági termékfejlesztő csapatokat a sebezhetőségi információk bővítésében anélkül, hogy kizárólag az NVD-adatbázis kiegészítésére támaszkodnának.
Hogyan OPSWAT ezt másképp OPSWAT ?
OPSWAT az OESIS Framework sebezhetőségértékelő modulját kifejezetten azoknak a biztonsági termékfejlesztőknek OPSWAT , akiknek megbízható, gyakorlatban is hasznosítható sebezhetőségi adatokra van szükségük eszközeikbe beépítve.
A hiányosságok figyelembevételével tervezve
A modul több forrást egyesít, ahelyett, hogy egyetlen forrásra támaszkodna.
Számos kereskedelmi és nyílt forrásból származó sebezhetőségi adatot használ fel annak érdekében, hogy több száz gyártó és alkalmazás esetében időszerű és pontos lefedettséget biztosítson.
Az OESIS sebezhetőségi adatbázis jelenleg több mint 65 000 egyedi CVE-t és több mint 150 000 sebezhetőségi esetet tartalmaz , és folyamatosan – naponta többször is – frissül, ahelyett, hogy az NVD feldolgozási ciklusaira várna.
Egy saját fejlesztésű súlyozási pontszám, amely túlmutat a CVSS-en, és több kontextust nyújt.
OPSWAT sebezhetőségi adatai tartalmazzák az OPSWAT pontszámot, egy saját fejlesztésű értékelési rendszert, amely a CVSS-alapértékeken túlmutat, mivel további tényezőket is figyelembe vesz, többek között a CVE-azonosítók elterjedtségét, a támadási kockázatot és a CVE-azonosítók életciklusát.
Egy olyan környezetben, ahol a CVSS-pontszámok egyre nagyobb hányada származhat a CNA saját jelentéseiből, ez a független elemzési szint segíthet a biztonsági termékeknek abban, hogy a felhasználók számára megalapozottabb prioritási jelzést nyújtsanak.
Az OESIS biztonsági információs rendszer kétféle integrációs lehetőséget támogat, bonyolult bevezetési folyamat nélkül:
- Katalógus-adatfolyam: Az OESIS sebezhetőségi adatait szerveroldalon összevetheti a meglévő szoftverleltárral – végpont-ügynök nélkül. A szoftverleltár-kezelési funkciókkal rendelkező meglévő termékek az OESIS adatait felhasználva felismerhetik a kezelt eszközök sebezhetőségeit.
- Endpoint (Software készlet): Az OESIS Framework közvetlenül beágyazható a termékébe, így valós idejű, eszközön belüli vulnerability detection biztosít. Kiválóan alkalmas az endpointokon futó biztonsági termékekhez
Belső sebezhetőségi kutatás
OPSWAT belső fenyegetéskutató csapata, az Unit 515, folyamatos támadó biztonsági kutatásokat, támadói szimulációkat, fejlett teszteléseket és felelősségteljes sebezhetőség-bejelentéseket végez a kritikus infrastruktúrák és a vállalati szoftverek területén. A csapat több mint 50 zero-day sebezhetőséget azonosított és jelentett, köztük kritikus eredményeket olyan széles körben elterjedt szoftverekben, mint az ICS/OT-platformok – például a Delta PLC-k – és a mesterséges intelligenciára épülő platformok.
Ennek az eredménye a biztonsági termékek fejlesztői számára az, hogy eszközeik szélesebb körű sebezhetőségi lefedettséget tudnak biztosítani akkor is, ha az NVD adatbázisának kiegészítési köre szűkül – anélkül, hogy az ügyfeleknek csökkentett átláthatóságot vagy manuális megoldásokat kellene elfogadniuk.
Felfedezés + kijavítás: a teljes folyamat
A felderítés feltárja a sebezhető pontokat. A javítás pedig orvosolja azokat. Együttesen segítik a kockázati kör lehető legnagyobb mértékű bezárását. Az OESIS Vulnerability Assessment feladata a felderítés és a prioritások meghatározása. Patch Management OESIS Patch Management azoknak a csapatoknak szól, amelyek mindkét funkciót egyetlen keretrendszerben szeretnék használni:
- Észlelés: Sebezhető alkalmazások, verzió szerint csoportosítva, OPSWAT és KEV-jelöléssel ellátva
- Prioritások meghatározása: OPSWAT a valós támadási jelek alapján segít meghatározni, hogy mely problémákat kell elsőként orvosolni
- Megoldás: A meglévő rendszer képes feldolgozni az OESIS kimeneti adatait – vagy Patch Management OESIS Patch Management közvetlenül is Patch Management a frissítéseket, érvényesítheti a verziókat, illetve blokkolhatja a hozzáférést
- Ellenőrzés: Az OESIS a hozzáférés visszaállítása előtt újra ellenőrzi a rendszerállapotot, hogy megbizonyosodjon arról, hogy a végpont tiszta-e
A felismerés javítás nélkül csupán egy jelentés. A felismerés javítással együtt pedig egy megoldott kockázat. Az OESIS célja, hogy mindkettőt biztosítsa az Ön termékének, segítve a felismerési és javítási folyamatok gyorsabb lezárását, hogy azok jobban lépést tudjanak tartani a mesterséges intelligencia sebességével.
Az AI-Speed biztonsági réseinek feltárásához az AI-Speed használata szükséges
A biztonsági termékek nem engedhetik meg maguknak, hogy a sebezhetőségi információkat lassú háttérfolyamatként kezeljék. Ahogy a CVE-bejegyzések száma növekszik, és az adatok kiegészítése egyre kevésbé következetes, a termékfejlesztő csapatoknak olyan megoldásra van szükségük, amely biztosítja, hogy az észlelési, prioritás-megállapítási és javítási munkafolyamatok összhangban legyenek a valós kockázati helyzettel.
Itt jön képbe az OESIS Framework Vulnerability Assessment. Ez a termékfejlesztők számára gyakorlati megoldást kínál a sebezhetőségek lefedettségének javítására anélkül, hogy a végpontokat vagy a javítási rendszert a nulláról kellene újraépíteniük. Az új terméket piacra dobó csapatok számára segítséget nyújt a megbízható lefedettség mielőbbi kialakításában. A meglévő termékeket fejlesztő csapatok számára pedig egyszerűbb módszert kínál a lefedettség összehasonlítására, a fejlesztések ellenőrzésére, valamint annak eldöntésére, hogy milyen formában valósítsák meg a mélyebb integrációt.
