CVE

CVE steht für „Common Vulnerabilities and Exposures“. Eine CVE-Kennung ist nichts weiter als eine eindeutige Nummer für eine öffentlich bekannte Schwachstelle, gebildet nach dem Muster CVE-Jahr-Nummer, etwa CVE-2021-44228 für die Schwachstelle, die als Log4Shell bekannt wurde.

Der Wert liegt genau in dieser Eindeutigkeit. Ohne gemeinsame Kennung müsste jede Datenbank, jedes Werkzeug und jeder Sicherheitshinweis dieselbe Schwachstelle über Beschreibungen identifizieren. Automatisieren lässt sich das nicht.

Wofür Sie CVE-Kennungen brauchen

Der Cyber Resilience Act (CRA) erwähnt CVE nicht ein einziges Mal. Er verlangt aber, Schwachstellen der eigenen Produkte zu ermitteln und zu dokumentieren. Genau dafür ist die Kennung das praktische Bindeglied:

• Die Software-Stückliste (SBOM) nennt Komponenten mit Version und eindeutigen Kennungen.
• Schwachstellendatenbanken ordnen CVEs den betroffenen Versionsbereichen zu.
• Der automatisierte Abgleich beider Seiten liefert die Liste möglicher Treffer.

Ohne CVEs bliebe von diesem Ablauf nur manuelles Nachlesen übrig.

Wie eine Kennung entsteht

Der Weg von der Entdeckung zur veröffentlichten CVE verläuft in festen Schritten:

1. Sicherheitsforschende, ein Kunde oder ein internes Team melden eine Schwachstelle.
2. Eine zuständige Vergabestelle reserviert eine Kennung. Ab diesem Moment existiert die Nummer, aber noch keine öffentliche Beschreibung.
3. Hersteller und Meldende koordinieren die Behebung. Die Kennung bleibt reserviert, damit alle Beteiligten schon über dieselbe Nummer sprechen können.
4. Mit der Veröffentlichung wird der Eintrag um betroffene Versionen, Beschreibung und Verweise ergänzt.

Deshalb begegnet Ihnen gelegentlich eine CVE-Nummer ohne Inhalt: Sie ist reserviert, aber noch nicht veröffentlicht. Einträge können außerdem als zurückgewiesen oder als strittig markiert werden. Strittig heißt, dass Hersteller und Meldende die Einordnung unterschiedlich sehen.

Für Sie als Hersteller heißt das: Eine Kennung frühzeitig zu reservieren, ist kein Eingeständnis, sondern gute Praxis. Sie schafft eine gemeinsame Bezeichnung, bevor die Behebung abgeschlossen ist.

Wo die Daten liegen und was in Europa dazukommt

Die CVE-Liste selbst enthält nur die Grunddaten. Für die praktische Arbeit greift man auf angereicherte Quellen zurück, die zusätzlich Bewertungen, betroffene Versionsbereiche und Verweise auf Sicherheitshinweise führen.

Für europäische Hersteller ist dabei eine Quelle besonders relevant: Die EU-Agentur für Cybersicherheit ENISA betreibt seit April 2025 die European Vulnerability Database (EUVD). Sie geht auf Artikel 12 der NIS-2-Richtlinie zurück, ist kostenlos zugänglich und führt neben den Schwachstellendaten auch Angaben zu Gegenmaßnahmen und zum aktuellen Ausnutzungsstatus.

Gerade der letzte Punkt ist für den CRA unmittelbar praktisch: Die Frage, ob eine Schwachstelle bereits ausgenutzt wird, entscheidet darüber, ob eine Aktiv ausgenutzte Schwachstelle vorliegt, und damit, ob die 24-Stunden-Frist läuft.

Was eine CVE nicht ist

Keine Bewertung. Die Kennung sagt nichts über Schweregrad oder Ausnutzbarkeit. Dafür gibt es CVSS, ein separates System, das häufig mitgeliefert, aber oft mit der Kennung verwechselt wird.

Kein Betroffenheitsnachweis. Dass eine Komponente in Ihrem Produkt steckt und für diese Komponente eine CVE existiert, heißt noch nicht, dass Ihr Produkt verwundbar ist. Die verwundbare Funktion kann in einer Version stecken, die Sie nicht verwenden, oder in einem Codepfad, den Ihr Produkt nie erreicht.

Keine vollständige Abdeckung. Längst nicht jede Schwachstelle bekommt eine CVE. Intern gefundene und still behobene Fehler tauchen dort nie auf. Wer sein Schwachstellenmanagement allein auf CVE-Abgleich stützt, sieht nur den öffentlich dokumentierten Teil.

Der praktische Ablauf

Aus dem Abgleich von Stückliste und Datenbank entsteht zunächst eine Liste möglicher Treffer. Erst die Bewertung jedes einzelnen Treffers macht daraus eine belastbare Aussage: Ist die betroffene Version wirklich im Einsatz? Ist der verwundbare Codepfad erreichbar? Gibt es mildernde Umstände in der Konfiguration?

Diese Bewertung ist der eigentliche Aufwand. Sie ist zugleich der Grund, warum ein reiner Scanner-Report noch keine Schwachstellenanalyse ist.