Zwei Jahrzehnte lang diente die NVD (National Vulnerability Database) als de-facto-Grundlage für das Schwachstellenmanagement. Scanner, SIEM-Systeme, Patch-Tools und Compliance-Frameworks gingen alle davon aus, dass die Analysten des NIST, sobald eine CVE in der NVD erschien, umgehend die Schweregrade, Produktversionszuordnungen und kontextbezogenen Metadaten hinzufügten, die eine reine CVE-ID erst wirklich nutzbar machen.
Am 15. April 2026 war diese Annahme offiziell nicht mehr zutreffend.
Das NIST hat bekannt gegeben, dass das NVD auf ein risikobasiertes Anreicherungsmodell umstellt. Die meisten neuen CVEs, die in die Datenbank aufgenommen werden, erhalten standardmäßig keinen vom NIST hinzugefügten CVSS-Score, keine CPE-Produktzuordnung und keine unabhängige Analyse mehr. Für Organisationen, deren Schwachstellen-Workflows auf durch das NVD angereicherten Daten basieren, entsteht dadurch ein echtes und wachsendes Abdeckungsproblem. Für Entwickler und Anbieter von Sicherheitsprodukten, die diese Daten in ihre Tools einbinden, wirft dies eine noch dringlichere Frage auf: Was genau sagt Ihnen Ihr Feed jetzt noch?
Die NVD kann mit den gemeldeten Sicherheitslücken nicht mehr Schritt halten
Laut einer Mitteilung des NIST stiegen die CVE-Meldungen zwischen 2020 und 2025 um 263 %, und im ersten Quartal 2026 lagen die Meldungen bereits um fast ein Drittel über dem Wert des Vorjahreszeitraums.
Das NIST hat im Jahr 2025 fast 42.000 CVEs ergänzt, was einem Anstieg von 45 % gegenüber jedem Vorjahreszeitraum entspricht. Diese gesteigerte Produktivität reichte jedoch nicht aus, um mit der wachsenden Zahl an Meldungen Schritt zu halten, was zur Einführung eines formalisierten Triage-Systems führte.
Ab dem 15. April 2026 wird das NIST nur noch Schwachstellen ergänzen, die im KVE-Katalog (Known Exploited Vulnerabilities) der CISA, in von der Bundesregierung genutzter Software oder in Software aufgeführt sind, die gemäß der Executive Order 14028 als kritisch eingestuft wurde. Alle anderen Schwachstellen werden zwar im NVD aufgeführt, jedoch ohne die vom NIST hinzugefügten Ergänzungen, und werden nicht sofort bearbeitet.
Infolgedessen wurden fast 300.000 vor dem 1. März 2026 veröffentlichte, noch nicht bearbeitete CVEs pauschal in die Kategorie „Nicht geplant“ verschoben.
Für CVEs, die künftig nicht mehr unter die Prioritätskriterien des NIST fallen, werden die Schweregrade künftig auf der Grundlage der Angaben der CVE-Nummerierungsstelle (CNA) – häufig der Anbieter der betroffenen Software – ermittelt und nicht mehr auf der Grundlage einer unabhängigen NIST-Analyse. Das NIST wird zudem keine Neuberechnung der Schweregrade mehr vornehmen, wenn eine CNA bereits einen Wert angegeben hat.
Jeder wichtige Schwachstellenscanner, jede SIEM-Korrelationsregel, jede Risikobewertung von Drittanbietern und jedes Rahmenwerk zur Einhaltung gesetzlicher Vorschriften – von PCI DSS bis hin zu FedRAMP – stützt sich auf die NVD-Anreicherungspipeline.
Mit dem Update hat sich dieser Prozess nun offiziell verkürzt, was dazu führt, dass potenziell gefährliche CVEs nicht als solche erfasst oder nicht rechtzeitig entdeckt werden.
Es gibt einen weiteren beschleunigenden Faktor, den man im Auge behalten sollte, da die Verringerung der Anreicherung mit der rasanten Verbreitung KI-gestützter Bedrohungserkennung einhergeht.
Fortschrittliche KI-Modelle und Programmierwerkzeuge senken die Hürden für die Identifizierung ausnutzbarer Schwachstellen und komplexer Angriffspfade in Anwendungen erheblich, was zu einem sprunghaften Anstieg der CVE-Meldungen führt. Im Februar 2026 prognostizierte das Forum of Incident Response and Security Teams (FIRST), dass im Jahr 2026 eine Rekordzahl von 50.000 zusätzlichen CVEs gemeldet werden würde. Die derzeitige Infrastruktur zur Datenanreicherung ist nicht dafür ausgelegt, dieses Volumen auf dem bisherigen Qualitätsniveau zu bewältigen.
Warum Produkte, die ausschließlich auf NVD basieren, ein Problem darstellen
Ein unbearbeiteter CVE-Eintrag enthält in der Regel eine ID, eine Beschreibung und Verweise. Die Metadaten, auf denen das automatisierte Schwachstellenmanagement basiert, stammten bislang von den Analysten des NVD. Diese Daten beziehen sich auf unabhängig validierte CVSS-Schweregrade, CPE-Produktzuordnungen und CWE-Schwachstellenklassifikationen.
Aber gerade die „Anreicherung“ macht ein CVE verwertbar. Ohne sie verschlechtern sich die Arbeitsabläufe, die davon abhängen, auf vorhersehbare Weise.
Die Priorisierung auf Basis des CVSS-Scores verliert an Bedeutung
Wenn ein Scanner oder ein Patching-Tool einen von der NVD bereitgestellten Schweregrad erwartet und keinen findet, wird die Schwachstelle möglicherweise als „unbekannter Schweregrad“ ausgewiesen, fällt nicht unter SLA-gesteuerte Patch-Richtlinien oder wird in der Prioritätenliste nach hinten verschoben.
In der Aktualisierung des NIST vom April 2026 wurde bestätigt, dass:
- CVEs, die nicht unter die neuen Prioritätskriterien fallen, werden nicht automatisch einer unabhängigen Bewertung unterzogen
- Das NIST wird keinen eigenen CVSS-Wert mehr berechnen, wenn ein CNA bereits einen Wert bereitgestellt hat (selbst wenn dieser CNA der Anbieter der betroffenen Software ist)
Eine unzureichende oder fehlende CPE-Zuordnung führt zu einer mangelhaften CVE-Erkennung
In der Dokumentation von NVD wird die Produktidentifizierung als wesentlicher Bestandteil der Anreicherung beschrieben, da sie es Anwendern ermöglicht, programmgesteuert zu überprüfen, ob eine bekannte Sicherheitslücke Produkte in ihrer Umgebung betrifft.
Wenn CPE-Zuordnungen fehlen, unvollständig sind oder verspätet erfolgen, kann es vorkommen, dass Tools, die sich in erster Linie auf den CPE-Abgleich stützen, die Übereinstimmung nicht oder erst verspätet anzeigen.
Anbieter von Sicherheitsprodukten sind besonders stark betroffen, da ihre Produkte häufig auf CPE-Abgleich und CVE-Anreicherung angewiesen sind. Tools für das Patch-Management, den Endgeräteschutz, die Netzwerkzugangskontrolle und das Asset-Management sind auf genaue Informationen zu Sicherheitslücken angewiesen, um festzustellen, welche Systeme betroffen sind, wie schwerwiegend das Problem ist und welche Maßnahmen als Nächstes ergriffen werden sollten.
Für Teams, die neue Sicherheitsprodukte entwickeln, bedeutet der ausschließliche Einsatz von NVD, auf einer Grundlage aufzubauen, die möglicherweise bereits wesentliche Lücken aufweist: begrenzte Abdeckung von Zero-Day-Schwachstellen, fehlende Anreicherung für einen wachsenden Anteil von CVEs sowie Aktualisierungszyklen, die möglicherweise nicht mit der Geschwindigkeit Schritt halten können, mit der Schwachstellen mithilfe von KI entdeckt und ausgenutzt werden.
Für Teams, die bereits über Funktionen zur Patch-Verwaltung oder Schwachstellenbehebung verfügen, stellt sich das Risiko anders dar, ist aber ebenso wichtig. Eine Schwachstellenbehebungs-Engine ist nur so effektiv wie die ihr zur Verfügung stehenden Informationen zu Sicherheitslücken. Sind diese Informationen unvollständig, verspätet oder zu stark von aus dem NVD abgeleiteten Ergänzungen abhängig, kann es vorkommen, dass nachgelagerte Arbeitsabläufe betroffene Produkte übersehen, Schwachstellen mit unbekanntem Schweregrad als weniger dringlich einstufen oder nicht rechtzeitig Maßnahmen ergreifen, bevor das Risiko steigt.
Sollten diese Produkte die Schwachstellen von NVD übernehmen, könnten diese Schwachstellen auf jeden nachgelagerten Kunden übergreifen.
Genau diese Lücke soll das OESIS Framework Vulnerability Assessment schließen: Es soll Sicherheitsteams dabei helfen, ihre Erkenntnisse zu Sicherheitslücken zu verbessern, ohne sich allein auf die Anreicherung durch das NVD zu verlassen.
Wie OPSWAT dies anders OPSWAT
OPSWAT das Modul „OESIS Framework Vulnerability Assessment“ speziell für Entwickler von Sicherheitsprodukten OPSWAT , die zuverlässige und verwertbare Schwachstellendaten benötigen, die in ihre Tools integriert werden können.
Auf die Lücke zugeschnitten
Das Modul fasst mehrere Quellen zusammen, anstatt sich auf eine einzige Quelle zu stützen.
Es nutzt eine Vielzahl kommerzieller und offener Quellen für Sicherheitslücken, um eine zeitnahe und genaue Abdeckung von Hunderten von Anbietern und Anwendungen zu gewährleisten.
Der OESIS-Schwachstellenkatalog umfasst derzeit über 65.000 einzelne CVEs und mehr als 150.000 Schwachstelleninstanzen und wird fortlaufend – mehrmals täglich – aktualisiert , anstatt auf die Verarbeitungszyklen des NVD zu warten.
Ein firmeneigener Schweregrad-Score, der über CVSS hinausgeht und mehr Kontext liefert.
Die Schwachstellendaten OPSWAT umfassen den OPSWAT Score, eine firmeneigene Bewertung, die über die CVSS-Basis hinausgeht, indem sie zusätzliche Faktoren wie die CVE-Verbreitung, das Risiko einer Kompromittierung und den CVE-Lebenszyklus einbezieht.
In einem Umfeld, in dem ein wachsender Anteil der CVSS-Werte möglicherweise von den CNA selbst gemeldet wird, könnte diese unabhängige Analyseebene dazu beitragen, dass Sicherheitsprodukte ihren Nutzern ein fundierteres Signal zur Priorisierung liefern.
OESIS Vulnerability Intelligence unterstützt zwei Integrationswege, ohne dass ein aufwendiger Einarbeitungsprozess erforderlich ist:
- Katalog-Feed: Vergleichen Sie OESIS-Schwachstellendaten serverseitig mit Ihrem bestehenden Software-Inventar – ganz ohne Endpunkt-Agenten. Bestehende Produkte mit Software-Inventarfunktionen können OESIS-Daten nutzen, um Schwachstellen in allen verwalteten Systemen zu erkennen.
- Endpoint (Software Kit): Integrieren Sie das OESIS-Framework direkt in Ihr Produkt, um vulnerability detection in Echtzeit direkt auf dem Gerät vulnerability detection. Ideal für Sicherheitsprodukte, die auf Endgeräten laufen
Interne Schwachstellenforschung
Das interne Bedrohungsforschungsteam OPSWAT, Unit 515, führt kontinuierlich offensive Sicherheitsforschung, Angreifersimulationen, fortgeschrittene Tests und verantwortungsbewusste Offenlegung in den Bereichen kritische Infrastruktur und Unternehmenssoftware durch. Das Team hat mehr als 50 Zero-Day-Schwachstellen identifiziert und gemeldet, darunter kritische Befunde in weit verbreiteter Software wie ICS/OT-Plattformen wie Delta-SPSen und KI-nativen Plattformen.
Für Entwickler von Sicherheitsprodukten bedeutet dies, dass ihre Tools auch bei einer Einschränkung des Erfassungsumfangs des NVD eine umfassendere Schwachstellenabdeckung gewährleisten können – ohne dass Kunden Abstriche bei der Transparenz oder manuelle Umgehungslösungen in Kauf nehmen müssen.
Erkennung + Behebung: Der gesamte Prozess
Die Erkennung identifiziert Schwachstellen. Die Behebung behebt sie. Zusammen tragen sie dazu bei, den Risikokreislauf so weit wie möglich zu schließen. OESIS Vulnerability Assessment übernimmt die Erkennung und Priorisierung. OESIS Patch Management steht Teams zur Verfügung, die beide Funktionen in einem Rahmenwerk nutzen möchten:
- Erkennung: Anfällige Anwendungen, nach Version geordnet, OPSWAT und mit KEV-Flag gekennzeichnet
- Priorisierung: OPSWAT hilft dabei, anhand von realen Angriffssignalen zu ermitteln, welche Probleme zuerst behoben werden sollten
- Maßnahmen: Ihre bestehende Pipeline kann die OESIS-Ausgabe verarbeiten – oder OESIS Patch Management Patches installieren, Versionen erzwingen oder den Zugriff direkt sperren
- Überprüfung: OESIS führt nach der Wiederherstellung des Zugriffs einen erneuten Scan durch, um sicherzustellen, dass der Endpunkt sicher ist
Eine Erkennung ohne Behebung ist lediglich ein Bericht. Eine Erkennung mit Behebung ist ein beseitigtes Risiko. OESIS zielt darauf ab, Ihrem Produkt beides zu bieten, und hilft dabei, den Kreislauf aus Erkennung und Behebung schneller zu schließen, um besser mit den rasanten Bedrohungen durch KI Schritt zu halten.
Sicherheitslücken bei AI-Speed erfordern eine AI-Speed-Erkennung
Sicherheitsanbieter können es sich nicht leisten, Informationen zu Sicherheitslücken als träge Backend-Abhängigkeit zu behandeln. Angesichts des wachsenden CVE-Volumens und der zunehmend uneinheitlichen Anreicherung benötigen Produktteams eine Möglichkeit, ihre Workflows für Erkennung, Priorisierung und Behebung an den tatsächlichen Sicherheitsrisiken auszurichten.
Genau hier setzt das OESIS Framework Vulnerability Assessment an. Es bietet Produktentwicklern eine praktische Möglichkeit, die Abdeckung von Sicherheitslücken zu verbessern, ohne ihren Endpunkt- oder Remediation-Stack von Grund auf neu aufbauen zu müssen. Teams, die ein neues Produkt auf den Markt bringen, können damit frühzeitig eine glaubwürdige Abdeckung sicherstellen. Teams, die ein bestehendes Produkt optimieren, bietet es einen reibungslosen Weg, um die Abdeckung zu vergleichen, Verbesserungen zu validieren und zu entscheiden, wie eine tiefere Integration aussehen sollte.
