CVE
CVE (Common Vulnerabilities and Exposures) gibt jeder öffentlichen Schwachstelle eine ID. Wie CVE-Einträge entstehen, was sie enthalten und wie du sie nutzt.
Aktualisiert Diese Seite als Markdown
Kurz gesagt
CVE, Common Vulnerabilities and Exposures, ist der Katalog, der jeder öffentlich bekannten Schwachstelle eine Kennung gibt (zum Beispiel CVE-2024-3094), damit Advisories, Scanner und Datenbanken über denselben Bug sprechen. Das Programm betreibt MITRE, finanziert von der US-Regierung; CVE Numbering Authorities (CNAs), darunter viele Hersteller, vergeben die IDs. Die NVD und die EU-Schwachstellendatenbank ergänzen Scores und Referenzen.
Was ist eine CVE?
Eine CVE ist ein Eintrag im Katalog Common Vulnerabilities and Exposures: eine Kennung für eine öffentlich bekannt gewordene Schwachstelle in einem bestimmten Produkt. Die ID hat die Form CVE-JJJJ-NNNNN, wobei das Jahr angibt, wann die ID reserviert oder veröffentlicht wurde (nicht, wann der Bug entstanden ist), und die Nummer vier oder mehr Stellen hat. Der Eintrag enthält eine kurze Beschreibung, die betroffenen Produkte und Versionen, Verweise auf Advisories und Fixes sowie den Namen der Organisation, die ihn vergeben hat. CVE-2024-3094, die Hintertür in xz-utils, ist ein bekanntes Beispiel.
Der Zweck von CVE ist ein gemeinsamer Name. Vorher beschrieb jeder Hersteller und jeder Scanner denselben Bug anders. Heute können ein Advisory, ein Scan-Ergebnis, eine Patch-Notiz und ein Pentest-Bericht auf dieselbe ID verweisen.
Wo ist es definiert?
Das CVE Program betreibt MITRE, finanziert von der US-Regierung und gesteuert von einem Board. IDs vergeben CVE Numbering Authorities (CNAs): MITRE selbst, nationale CERTs und mehrere hundert Hersteller und Open-Source-Projekte, die Schwachstellen in ihren eigenen Produkten nach den CNA Operational Rules behandeln. Das Datenformat ist ein öffentliches JSON-Schema (CVE Record Format 5.x).
Scores sind nicht Teil von CVE. Die US-amerikanische National Vulnerability Database (NVD) reichert Einträge mit CVSS-Scores, CPE-Produktkennungen und CWE-Schwächetypen an. In der EU beauftragt NIS2 in Artikel 12 Absatz 2 die ENISA mit einer europäischen Schwachstellendatenbank; die EUVD ging 2025 in Betrieb und spiegelt CVE-Einträge mit EU-spezifischem Kontext. Die Meldepflichten des Cyber Resilience Act (Artikel 14) verlangen keine CVE, aber über eine CVE wird der Rest der Welt die Schwachstelle verfolgen, die du meldest.
Was es in der Praxis bedeutet
Für einen Produkthersteller hat CVE zwei Seiten. Eingehend gleichen deine Dependency- und Firmware-Scanner Komponentenversionen mit CVE-Einträgen ab, was nur funktioniert, wenn du deine Komponenten kennst: daher die SBOM. Ausgehend muss jemand eine CVE vergeben, wenn eine Schwachstelle in deinem eigenen Produkt gefunden wird. Als CNA für die eigenen Produkte kontrollierst du Zeitpunkt und Wortlaut; sonst vergibt MITRE oder ein CERT die ID.
Was wir in Projekten sehen:
- Keine CVE heißt nicht keine Schwachstelle. Die meisten Bugs aus einem Penetrationstest einer Individualanwendung oder eines Steuergeräts bekommen nie eine CVE, weil sie produktspezifisch sind und ohne öffentliche Offenlegung behoben werden. Embedded-Komponenten sind außerdem unterrepräsentiert: Ein RTOS oder ein Bluetooth-Stack mit wenigen öffentlichen CVEs ist meist wenig getestet, nicht sauber.
- Versionsabgleich ist grob. Ein Eintrag sagt “Versionen vor 2.4.1 sind betroffen”; deine Distribution hat den Fix in 2.3.7 zurückportiert. Scanner schlagen an, und die Sichtung muss das auflösen.
- Die Beschreibung ist oft dünn. Viele Einträge sagen kaum mehr als “ein Pufferüberlauf in Komponente X”. Ob es für deinen Einsatz relevant ist, verraten die Referenzen, nicht die Zusammenfassung.
Häufige Missverständnisse
Eine CVE ist keine Schweregradbewertung; das ist CVSS. Eine CVE ist kein Exploit; der Eintrag existiert unabhängig davon, ob jemand den Bug waffenfähig gemacht hat. Und eine CVE bedeutet nicht, dass der Hersteller einen Patch hat: Einträge werden auch für ungefixte Bugs veröffentlicht, vor allem nach Ablauf einer Offenlegungsfrist.
FAQ
Häufig gestellte Fragen
Wer vergibt eine CVE-ID?
Eine CVE Numbering Authority (CNA). MITRE ist die CNA der letzten Instanz; nationale CERTs und mehrere hundert Hersteller und Open-Source-Projekte sind CNAs für Schwachstellen in ihren eigenen Produkten. Findest du eine Schwachstelle in einem Fremdprodukt, meldest du sie dem Hersteller oder einem CERT, und diese Stelle vergibt die ID.
Sollte mein Unternehmen CNA werden?
Wenn du Software oder vernetzte Geräte auslieferst und regelmäßig Schwachstellen veröffentlichen wirst, ja. Als CNA kontrollierst du Zeitpunkt und Wortlaut der Einträge zu deinen Produkten und kannst IDs vor der Veröffentlichung reservieren. Der CRA verlangt das nicht, aber ein funktionierender Schwachstellenprozess mit CVE-Vergabe ist ein starker Nachweis für Anhang I Teil II.
Sagt mir eine CVE, wie schwer eine Schwachstelle wiegt?
Nicht für sich allein. Der CVE-Eintrag beschreibt den Bug und die betroffenen Versionen. Der Schweregrad kommt aus einem CVSS-Score, den die CNA ergänzen kann und den NVD und EUVD neben dem Eintrag veröffentlichen. Ob er für dich relevant ist, hängt von deinem Einsatz ab, und den kennt keine Datenbank.
Quellen
Passende Seiten
- GlossarCVSSCVSS, das Common Vulnerability Scoring System, bewertet den Schweregrad einer Schwachstelle von 0 bis 10. Was der Score misst, was nicht, wie du ihn im Bericht nutzt.
- GlossarSchwachstellenscanEin Schwachstellenscan prüft Systeme automatisiert gegen eine Datenbank bekannter Lücken. Was Scanner finden, was sie übersehen und wie du sie sinnvoll einsetzt.
- GlossarSBOMEine SBOM listet jede Softwarekomponente eines Produkts mit Version und Lieferant. Formate, Mindestinhalte, was der Cyber Resilience Act verlangt, wie du sie nutzt.
- GlossarResponsible DisclosureResponsible oder Coordinated Vulnerability Disclosure (CVD): eine Schwachstelle dem Hersteller melden und vor der Veröffentlichung beheben. Regeln, Fristen, Rechtslage.
- InsightsDie CRA-Meldepflicht in 24 Stunden: Was Hersteller tun müssenDie CRA-Meldepflicht gilt seit dem 11. September 2026. Die Fristen (24 Stunden, 72 Stunden, 14 Tage, ein Monat), was sie auslöst und wie du vorbereitet bist.
- LeistungenMach deine Produkte CRA-konform, ohne die Entwicklung auszubremsen.Cyber Resilience Act umsetzen: Gap-Analyse, sichere Entwicklung, Schwachstellenmanagement, SBOM und Penetrationstest für Produkte mit digitalen Elementen.
