Die EUVD ist operativ - und ENISA ist eigene CVE-Root
Die European Vulnerability Database ist am 13. Mai 2025 in den Regelbetrieb gegangen. Rechtlich fußt sie auf der NIS2-Richtlinie, die ENISA den Aufbau einer europäischen Schwachstellen-Registratur aufgibt. Inhaltlich ist die EUVD ein Aggregator: Sie führt Daten aus offenen Schwachstellen-Datenbanken, Advisories und Warnungen nationaler CSIRTs, Hersteller-Guidance zu Patches und Gegenmaßnahmen sowie den Known-Exploited-Katalog der US-Behörde CISA zusammen (ENISA, Pressemitteilung zur EUVD).
Ein einzelner Eintrag enthält typischerweise eine Beschreibung der Schwachstelle, die betroffenen Produkte, Dienste und Versionen, eine Schwere-Einstufung sowie Hinweise auf verfügbare Patches oder behördliche Empfehlungen (ENISA). Die Oberfläche bietet drei Dashboard-Sichten: für kritische Schwachstellen, für ausgenutzte Schwachstellen und für EU-koordinierte Fälle (ENISA). Genau diese zweite Sicht ist der eigentliche Gewinn - dazu gleich mehr.
Die zweite Veränderung wiegt strukturell schwerer: ENISA ist seit November 2025 CVE-Root für europäische Einrichtungen in ihrem Zuständigkeitsbereich, einschließlich Schwachstellen, die von EU-CSIRTs entdeckt oder an sie gemeldet werden (ENISA). Als Root rekrutiert, schult und betreut ENISA CNAs, begleitet deren Wechsel und verantwortet die Vergabe von CVE-IDs sowie die Veröffentlichung der CVE-Records in ihrem Bereich (ENISA).
Bis Mai 2026 sind sieben CNAs von der MITRE-Root unter die ENISA-Root gewechselt, vier Organisationen sind neu als CNA unter ENISA-Root dazugekommen (ENISA, 'New CVE Numbering Authorities Under ENISA Root', 06.05.2026). Übertragungsfähig wären über 90 CNAs in Europa - von 510 CNAs aus 42 Ländern im CVE-Programm, knapp ein Fünftel weltweit (ENISA, 06.05.2026). Wichtig für den Betrieb: Die CVE-ID bleibt dieselbe. Ein Root-Wechsel ändert die Zuständigkeit für Vergabe und Pflege, nicht das Identifikator-Schema - wer heute CVE-IDs verarbeitet, muss seine Pipeline nicht umbauen.
Für KMU ist die Botschaft unaufgeregt: Es entsteht kein konkurrierendes Nummernsystem, sondern eine zweite, europäisch verankerte Anlaufstelle mit eigener Kuratierung. Die EUVD vergibt eigene IDs im Format EUVD-JJJJ-NNNNN, führt die zugehörigen CVE-IDs aber als Aliase mit - Einträge lassen sich in beide Richtungen auflösen.
Vier Feeds, vier Fragen: EUVD, CVE-Programm, NVD und KEV
Der häufigste Fehler ist die Annahme, man müsse sich für einen Feed entscheiden. Tatsächlich beantworten die vier großen Quellen unterschiedliche Fragen und ergänzen sich.
| Feed | Beantwortet die Frage | Stärke | Grenze |
|---|---|---|---|
| EUVD (ENISA) | Was ist in der EU relevant - und gilt es als ausgenutzt? | Aggregiert CVE-Daten, CSIRT-Advisories, Hersteller-Guidance und den KEV-Katalog; drei Dashboards für kritische, ausgenutzte und EU-koordinierte Einträge (ENISA) | Junger Feed, EU-Fokus; kein Ersatz für die Advisories des jeweiligen Herstellers |
| CVE-Programm (MITRE) | Welche eindeutige Kennung hat diese Schwachstelle? | Vergibt CVE-IDs über 510 CNAs aus 42 Ländern; liefert den Basis-Record mit betroffenen Produkten und Versionen (MITRE, CVE-Programm; ENISA, 06.05.2026) | Die Record-Tiefe schwankt je CNA; enthält bewusst keine Priorisierung |
| NVD (NIST) | Wie schwer ist sie technisch? | Analyse, CVSS-Bewertung und Produktzuordnung zu 366.327 CVE-Einträgen (NIST, National Vulnerability Database, Stand 15.07.2026) | CVSS misst technische Schwere, nicht Ihre Betroffenheit oder die Ausnutzung |
| KEV (CISA) | Wird sie nachweislich ausgenutzt? | 1.642 Einträge mit belegter Ausnutzung, davon 329 mit bekannter Nutzung in Ransomware-Kampagnen (CISA, Known Exploited Vulnerabilities Catalog, Katalogversion 2026.07.14) | Fokus auf US-Behördenrelevanz; Aufnahme erst bei belastbarem Nachweis |
Die Größenordnungen zeigen, wie eng EUVD und NVD beieinanderliegen: 365.977 Einträgen in der EUVD (ENISA, Stand 15.07.2026) stehen 366.327 CVE-Einträge in der NVD gegenüber (NIST, Stand 15.07.2026). Die EUVD ist also kein Auszug, sondern ein Feed auf Augenhöhe - mit dem Unterschied, dass sie zusätzlich CSIRT-Advisories und den Exploited-Status einbezieht. Bis zum 15. Juli 2026 sind 40.654 EUVD-Einträge veröffentlicht worden (ENISA), nach 49.703 im gesamten Jahr 2025 (ENISA) - rund 207 neue Einträge pro Tag.
Bei diesem Tempo ist jede Strategie zum Scheitern verurteilt, die auf vollständiges Lesen setzt. Feeds sind keine Leselisten, sondern Nachschlagewerke. Der Wert entsteht erst durch die Abfrage: Betrifft ein Eintrag eine Komponente, die auf meiner Website läuft? Diese Frage lässt sich nur beantworten, wenn die Liste der eigenen Komponenten existiert und gepflegt ist.
Warum 'aktiv ausgenutzt' schwerer wiegt als der CVSS-Score
Die verbreitetste Priorisierungsregel lautet: erst alles mit CVSS 9,0 und höher, dann der Rest. Sie ist intuitiv und in dieser Form irreführend. Ein Blick in die Zahlen der EUVD macht das deutlich.
- 82.227 Einträge der EUVD tragen einen CVSS-Basiswert von 7,0 bis 10,0 - rund 22 Prozent des gesamten Katalogs (ENISA, EUVD, Stand 15.07.2026). Eine Arbeitsliste dieser Größe ist keine Priorisierung, sondern eine Kapitulation.
- 17.659 Einträge liegen bei CVSS 9,0 bis 10,0, also im kritischen Bereich (ENISA, EUVD, Stand 15.07.2026). Auch das sind knapp 5 Prozent des Katalogs - noch weit jenseits dessen, was ein KMU-Team abarbeiten kann.
- 1.647 Einträge sind in der EUVD als aktiv ausgenutzt markiert (ENISA, EUVD Exploited-Filter, Stand 15.07.2026). Das sind 0,45 Prozent des Katalogs - eine Größenordnung, die operativ handhabbar ist.
Entscheidend ist der Vergleich der beiden Mengen. Von den 17.659 kritischen Einträgen gelten lediglich 562 zugleich als ausgenutzt (ENISA, EUVD, Stand 15.07.2026) - also 3,2 Prozent. Wer strikt nach CVSS 9,0 abarbeitet, verbringt den überwiegenden Teil der Zeit mit Schwachstellen, für die kein Ausnutzungsnachweis vorliegt.
Die Gegenprobe ist noch aufschlussreicher: 1.085 der 1.647 als ausgenutzt markierten Einträge liegen unterhalb von CVSS 9,0 - 66 Prozent (ENISA, EUVD, Stand 15.07.2026). Eine reine CVSS-Sortierung schiebt also zwei Drittel der nachweislich ausgenutzten Schwachstellen nach hinten. 200 dieser Einträge tragen einen Basiswert unter 7,0 (ENISA, EUVD, Stand 15.07.2026) und würden in vielen Prozessen als 'mittel' abgelegt - obwohl sie angegriffen werden.
CVSS beschreibt, wie schlimm eine Schwachstelle wäre, wenn jemand sie ausnutzt. Der Exploited-Status beschreibt, dass es jemand tut. Für die Reihenfolge der Arbeit ist die zweite Aussage die relevantere.
— Einordnung auf Basis der EUVD-Daten (ENISA, Stand 15.07.2026)
Das ist kein Argument gegen CVSS. Der Score bleibt nützlich, um innerhalb einer Gruppe zu sortieren und Schwachstellen ohne Ausnutzungsdaten einzuschätzen - er ist nur der falsche erste Filter. Wie eng die Exploited-Sichten beieinanderliegen, zeigt der Abgleich: Die EUVD führt 1.647 ausgenutzte Einträge (ENISA, Stand 15.07.2026), der KEV-Katalog 1.642 (CISA, Katalogversion 2026.07.14) - die EUVD speist ihre Exploited-Sicht unter anderem aus dem KEV-Katalog (ENISA).
Ein Eintrag ohne Exploited-Markierung bedeutet, dass den Katalogbetreibern kein belastbarer Ausnutzungsnachweis vorliegt - nicht, dass die Schwachstelle ungefährlich ist. KEV und EUVD nehmen Einträge erst bei ausreichender Evidenz auf, und diese Evidenz entsteht typischerweise mit Verzögerung. Die Exploited-Sicht ist deshalb ein Beschleuniger für die Reihenfolge, kein Ersatz für regelmäßiges Patchen. Bis zum 15. Juli 2026 sind 158 Einträge neu in den KEV-Katalog aufgenommen worden (CISA, Katalogversion 2026.07.14) - rund 23 pro Monat.
Die Priorisierungs-Regel: ausgenutzt, exponiert, Rest
Aus den Zahlen lässt sich eine Regel bauen, die ohne Werkzeugkette auskommt: drei Stufen, in dieser Reihenfolge abgearbeitet.
- Bekannt ausgenutzt - sofort. Trifft ein Eintrag aus dem EUVD-Exploited-Filter oder dem KEV-Katalog eine Komponente aus Ihrem Inventar, ist das die Aufgabe des Tages: patchen, und ohne verfügbaren Patch die vom Hersteller oder CSIRT empfohlene Gegenmaßnahme umsetzen. Nur ein Bruchteil der 1.647 ausgenutzten Einträge (ENISA, Stand 15.07.2026) betrifft einen typischen Website-Stack.
- Internetexponiert und kritisch - geplant. Alles mit CVSS 9,0 bis 10,0 auf einer öffentlich erreichbaren Komponente kommt in den nächsten Wartungslauf. Die Exposition ist das entscheidende Zusatzkriterium: Eine kritische Lücke in einer Bibliothek, die nur im internen Build läuft, ist weniger dringend als dieselbe Lücke im öffentlich erreichbaren CMS.
- Alles Übrige - im Turnus. Der Rest wandert in den regulären Patch-Rhythmus, monatlich ist für die meisten KMU-Websites ein tragfähiger Takt. Wichtig ist nicht die Frequenz, sondern dass der Turnus dokumentiert stattfindet und nicht in der ersten stressigen Woche ausfällt.
Diese Regel hat einen unterschätzten Nebeneffekt: Sie macht Nichtstun begründbar. Wer dokumentiert, dass ein Eintrag weder als ausgenutzt markiert noch internetexponiert ist und deshalb im Turnus läuft, hat eine nachvollziehbare Entscheidung getroffen - gegenüber Auftraggebern, Versicherern oder Prüfern deutlich belastbarer als eine Liste, die niemand abarbeiten konnte. Wie sich solche Nachweise gegenüber Dritten führen lassen, behandelt der Beitrag zu NIS2-Anforderungen an Lieferkette und Dienstleister.
Bevor Sie in die Score-Diskussion einsteigen, klären Sie eine simplere Frage: Ist die betroffene Komponente überhaupt aus dem Internet erreichbar? Ein Admin-Interface hinter einer IP-Beschränkung, eine Bibliothek, die nur zur Build-Zeit läuft, oder ein deaktiviertes Plugin verschieben die Dringlichkeit erheblich. Diese Einordnung kostet Minuten und spart erfahrungsgemäß mehr Zeit als jede Feinjustierung am CVSS-Vektor.
Ohne Inventar ist jeder Feed wertlos
Hier liegt der eigentliche Engpass. Ein Feed liefert Aussagen über Produkte und Versionen. Um daraus eine Aufgabe zu machen, braucht es die Gegenseite: eine gepflegte Liste dessen, was auf der eigenen Website tatsächlich läuft. Fehlt sie, ist selbst der beste Feed nur ein Nachrichtenticker.
Wie unspezifisch ein Feed ohne Inventar bleibt, zeigt eine simple Probe: Eine Volltextsuche nach 'wordpress' liefert in der EUVD 18.901 Treffer, eine nach 'apache' 3.618 (ENISA, EUVD-Suche, Stand 15.07.2026). Ohne die Information, welches Plugin in welcher Version bei Ihnen läuft, ist keine dieser Listen verwertbar; mit ihr schrumpft sie auf eine Handvoll Einträge.
Ein brauchbares Website-Inventar umfasst vier Ebenen. Sie klingen banal, werden aber selten vollständig geführt.
Name und exakte Versionsnummer des Content-Management- oder Shop-Systems. Die Hauptversion genügt nicht - Sicherheitsfixes erscheinen in Patch-Releases, und genau die entscheiden über die Betroffenheit.
Die Angriffsfläche einer KMU-Website liegt selten im CMS-Kern, sondern in Erweiterungen. Jedes Plugin mit Version, Herkunft und Wartungsstatus. Auch deaktivierte Erweiterungen gehören auf die Liste - ihr Code liegt weiterhin auf dem Server.
Eingebundene Frontend-Bibliotheken, lokal ausgeliefert oder extern nachgeladen. Sie tauchen in keiner Server-Paketliste auf und fehlen deshalb in vielen Inventaren, sind aber vollwertige Komponenten mit eigenen CVE-Einträgen.
Webserver, PHP- oder Node-Version, Datenbank, TLS-Bibliothek, Reverse-Proxy. Bei Managed-Hosting liegt diese Schicht oft außerhalb der eigenen Kontrolle - was sie nicht weniger relevant macht, sondern zu einer Frage an den Dienstleister.
Der Aufwand liegt weniger im Erstellen als im Aktuellhalten. Ein Inventar, das einmal in einer Tabelle erfasst und dann nicht gepflegt wird, ist nach wenigen Monaten schlechter als kein Inventar - es erzeugt trügerische Sicherheit. Die Systematik dazu behandelt der Beitrag zur SBOM als Software-Stückliste für Websites.
Feeds sind öffentlich, kostenlos und gut dokumentiert. EUVD, CVE-Programm, NVD und KEV lassen sich ohne Vertrag und ohne Lizenz abfragen. Der Teil, den niemand von außen liefern kann, ist die Liste Ihrer eigenen Komponenten samt Versionsstand. Genau deshalb scheitert Schwachstellen-Management in der Praxis weit häufiger am Inventar als am Feed.
Komponenten gegen die Feeds matchen - der praktische Ablauf
Der Abgleich zwischen Inventar und Feed muss nicht kompliziert sein. Für eine überschaubare Zahl von Websites trägt der folgende Ablauf ohne eigene Werkzeugkette.
- Inventar erfassen. Pro Website eine Liste aus CMS, Erweiterungen, Frontend-Bibliotheken und Serversoftware, jeweils mit Version. Einmalig der größte Aufwand - danach nur noch Fortschreibung.
- Namen normalisieren. Feeds benennen Hersteller und Produkte uneinheitlich. Legen Sie je Komponente einmal fest, unter welcher Bezeichnung sie in den Feeds geführt wird, und notieren Sie diese Schreibweise im Inventar. Dieser Schritt wird oft übersprungen und ist die häufigste Ursache für ausbleibende Treffer.
- Exploited-Sicht zuerst abfragen. Der Exploited-Filter der EUVD und der KEV-Katalog sind mit rund 1.650 Einträgen (ENISA und CISA, Stand Juli 2026) klein genug für eine vollständige Prüfung gegen das Inventar - die wichtigste Abfrage der Woche.
- Kritische Einträge gegen exponierte Komponenten prüfen. Danach die Sicht auf CVSS 9,0 bis 10,0, beschränkt auf die aus dem Internet erreichbaren Komponenten.
- Entscheidung dokumentieren. Zu jedem relevanten Treffer eine Zeile: gepatcht, mitigiert oder bewusst zurückgestellt - mit Begründung und Datum. Diese Zeile ist später der Nachweis.
- Turnus festlegen. Ein fester Termin schlägt erfahrungsgemäß jede Ad-hoc-Reaktion auf Schlagzeilen: wöchentlich für die Exploited-Sicht, monatlich für den Rest.
Der schwierigste Schritt ist der zweite. Ein Plugin heißt im Verzeichnis anders als im CVE-Record, ein Hersteller taucht unter zwei Schreibweisen auf, eine Bibliothek läuft unter dem Projekt- statt unter dem Paketnamen. Wer diese Zuordnung einmal sauber festhält, macht den Abgleich zur Routine von Minuten; wer sie überspringt, sucht bei jedem Durchlauf neu.
CRA ab 11. September 2026: mehr Feed-Qualität, mehr Handlungsdruck
Ab dem 11. September 2026 greifen die Meldepflichten aus Artikel 14 des Cyber Resilience Act (Verordnung (EU) 2024/2847, Art. 14; EU-Kommission, 'Cyber Resilience Act - Reporting obligations'). Hersteller von Produkten mit digitalen Elementen müssen dann aktiv ausgenutzte Schwachstellen melden - gestaffelt und mit engen Fristen.
| Frist ab Kenntnis | Was zu melden ist | Empfänger |
|---|---|---|
| 24 Stunden | Frühwarnung zur aktiv ausgenutzten Schwachstelle | Zuständiges CSIRT und ENISA über die Single Reporting Platform (EU-Kommission, Art. 14 CRA) |
| 72 Stunden | Vollmeldung mit Details und getroffenen Gegenmaßnahmen | Zuständiges CSIRT und ENISA (EU-Kommission, Art. 14 CRA) |
| 14 Tage | Abschlussbericht, nachdem eine Korrekturmaßnahme verfügbar ist | Single Reporting Platform (EU-Kommission, Art. 14 CRA) |
Zum selben Datum soll die Single Reporting Platform betriebsbereit sein - die zentrale Meldestelle, über die Hersteller einmal melden statt jede nationale Behörde einzeln zu adressieren (ENISA, Single Reporting Platform). Das empfangende CSIRT verteilt die Meldung anschließend an die weiteren zuständigen CSIRTs (EU-Kommission, Art. 14 CRA).
Für Website-Betreiber, die keine Hersteller im Sinne des CRA sind, folgt daraus keine eigene Meldepflicht - aber ein handfester Effekt: Wenn Hersteller ab September 2026 aktiv ausgenutzte Schwachstellen fristgebunden melden, fließt mehr belastbare Ausnutzungs-Information in die Feeds, und sie fließt früher. ENISA ist als Empfängerin dieser Meldungen zugleich Betreiberin der EUVD - der Exploited-Filter dürfte damit an Aussagekraft gewinnen.
Der Handlungsdruck steigt in beide Richtungen. Wenn eine ausgenutzte Schwachstelle künftig binnen 24 Stunden gemeldet und über die EUVD sichtbar wird, verkürzt sich die Zeitspanne, in der Nichtwissen plausibel ist. Wer eine betroffene Komponente wochenlang ungepatcht betreibt, obwohl der Ausnutzungsnachweis öffentlich einsehbar war, wird das in einem Schadensfall schwerer erklären können. Die Details der Herstellerpflichten behandelt der Beitrag zur CRA-Schwachstellen-Meldepflicht ab September 2026.
Ergänzend lohnt der Blick auf den eingehenden Kanal: Wer über eine security.txt nach RFC 9116 einen Kontaktpunkt für Schwachstellen-Meldungen bereitstellt, erfährt von Problemen mitunter, bevor sie in einem Feed auftauchen. Die Meldepflichten für Betreiber kritischer und wichtiger Einrichtungen sind im Beitrag zu den NIS2-Meldepflichten für Website-Betreiber aufbereitet.
Grenzen der Feeds ehrlich benennen
Ein realistischer Umgang mit Feeds gehört zur Sorgfaltspflicht. Drei Einschränkungen sollten Sie kennen, bevor Sie einen Prozess darauf aufbauen.
- Der Exploited-Status hinkt der Realität hinterher. Eine Schwachstelle wird ausgenutzt, bevor jemand die Ausnutzung nachweist und meldet. Die 1.647 markierten Einträge (ENISA, Stand 15.07.2026) sind das, was belegt ist - nicht das, was passiert.
- Nicht jede Komponente ist gleich gut abgedeckt. Verbreitete Systeme mit aktiver Sicherheitsforschung sind gut vertreten. Ein selten genutztes Plugin oder eine hausintern gepflegte Erweiterung erzeugt selten einen CVE-Eintrag - das Fehlen im Feed sagt dort wenig aus.
- Feeds ersetzen keine Hersteller-Advisories. Die EUVD führt Hersteller-Guidance zusammen (ENISA), aber die schnellste Information zu einer Komponente kommt weiterhin vom Projekt oder Anbieter selbst. Für die Kernkomponenten Ihres Stacks lohnt der direkte Bezug.
Oft übersehen wird der Unterschied zwischen einer Schwachstelle in Ihrer Software und einer in dem, was Ihre Seite im Browser lädt. Ein verändertes Dritt-Skript hat keine CVE-ID und taucht in keinem Feed auf - dafür braucht es die Überwachung der Integrität eingebundener Skripte per Subresource Integrity. Ähnlich gelagert ist die Verteilung von Sperrinformationen für Zertifikate; dazu ordnet der Beitrag zum Ende von OCSP und der Rückkehr zu CRL die Umstellung ein.
Schwachstellen-Feeds in den Betriebsalltag holen
Die Feed-Landschaft 2026 ist besser, als sie je war: Mit der EUVD gibt es eine europäisch verankerte, aggregierte Quelle mit explizitem Exploited-Filter, ENISA ist als CVE-Root strukturell eingebunden, und ab dem 11. September 2026 speisen verpflichtende Herstellermeldungen zusätzliche Ausnutzungs-Information ein (EU-Kommission, Art. 14 CRA). An der Verfügbarkeit von Informationen scheitert Schwachstellen-Management heute nicht mehr - es scheitert an der Verbindung zwischen Feed und eigenem Bestand. Solange niemand weiß, welche CMS-Version, welche Plugins und welche JavaScript-Bibliotheken auf einer Website laufen, bleibt jeder EUVD-Eintrag eine abstrakte Meldung über fremde Software.
Genau dort setzt das CRA-Komponenten-Cockpit von XICTRAQ an. Es hält den Tech-Stack je Website fest, erkennt veraltete Komponenten anhand des erfassten Versionsstands und eskaliert nahende CRA-Fristen rechtzeitig über die konfigurierten Alerting-Kanäle. Aus der Bringschuld, jederzeit sagen zu können, was auf der eigenen Website läuft, wird ein wiederkehrender Arbeitsablauf statt einer Tabelle, die niemand pflegt. Ergänzend prüft der Security-Scan die Angriffsfläche in einem echten Browser, die NIS2-Readiness-Funktionen bilden die Melde- und Fristenlogik ab. Das Zusammenspiel zeigt die Live-Demo; die Plan-Zuordnung steht in der Preisübersicht.
Der praktische Einstieg braucht keine große Initiative. Erfassen Sie das Inventar einer einzigen Website, prüfen Sie es gegen den Exploited-Filter der EUVD, dokumentieren Sie das Ergebnis. Sie werden mit hoher Wahrscheinlichkeit feststellen, dass die Liste der Aufgaben kurz ist - und dass Sie sie zum ersten Mal begründen können. Das ist mehr, als die meisten Schwachstellen-Prozesse leisten.
Dieser Artikel basiert auf Daten und Dokumenten von: ENISA - European Vulnerability Database (euvd.enisa.europa.eu, About-Seite, Suche und Exploited-Filter; sämtliche Katalog-Zahlen dieses Beitrags, Stand 15.07.2026); ENISA - Pressemitteilung 'Consult the European Vulnerability Database to enhance your digital security' (Start 13.05.2025, Rechtsgrundlage NIS2, aggregierte Quellen, drei Dashboard-Sichten); ENISA - 'New CVE Numbering Authorities Under ENISA Root' (06.05.2026: vier neue CNAs, sieben Wechsel von der MITRE-Root, über 90 übertragungsfähige CNAs in Europa, 510 CNAs aus 42 Ländern weltweit); ENISA - 'Stepping up our role in Vulnerability Management: ENISA Becomes CVE Root' (CVE-Root seit November 2025); ENISA - Single Reporting Platform (betriebsbereit zum 11.09.2026); MITRE - CVE Program (CNA-Struktur, CVE-Records, Vergabe von CVE-IDs); NIST - National Vulnerability Database (366.327 CVE-Einträge, Stand 15.07.2026; CVSS und Produktzuordnung); CISA - Known Exploited Vulnerabilities (KEV) Catalog (Katalogversion 2026.07.14: 1.642 Einträge, davon 329 mit bekannter Ransomware-Nutzung, 158 Neuaufnahmen 2026); Verordnung (EU) 2024/2847 (Cyber Resilience Act), Art. 14 (Meldepflicht ab 11.09.2026, Fristen 24 Stunden, 72 Stunden, 14 Tage); Europäische Kommission - 'Cyber Resilience Act: Reporting obligations' (digital-strategy.ec.europa.eu). Alle Datenbank-Zahlen wurden am 15.07.2026 direkt aus den offiziellen Beständen abgefragt.