CVE

CVE – Common Vulnerabilities and Exposures

CVE (Common Vulnerabilities and Exposures) ist ein weltweit anerkanntes System zur Identifizierung und Benennung von Cybersicherheitsschwachstellen. Jede Schwachstelle erhält eine eindeutige CVE-ID (z. B. CVE-2024-3094), die es Sicherheitsteams, Herstellern und Regulierungsbehörden ermöglicht, sich unmissverständlich auf dieselbe Schwachstelle zu beziehen. Gemäß der EU-Cyberresilienz-Verordnung ist die CVE-Überwachung unerlässlich, um die 24-Stunden-Frühwarnpflicht für aktiv ausgenutzte Schwachstellen zu erfüllen; die Frühwarnung wird über die von der ENISA betriebene einheitliche Meldeplattform übermittelt.

Wichtige Fakten

Detail	Information
Vollständiger Name	Common Vulnerabilities and Exposures
Verwaltet von	MITRE Corporation (USA, finanziert durch CISA)
ID-Format	CVE-JJJJ-NNNNN (Jahr + fortlaufende Nummer)
Gesamtanzahl veröffentlichter CVEs	Über 300.000 (Stand Anfang 2026)
Neue CVEs pro Jahr	~40.000 im Jahr 2024, ~48.000 im Jahr 2025 (Tendenz steigend)
Öffentliche Datenbank	cve.org
Datenbank mit Zusatzinformationen	NVD (National Vulnerability Database) – fügt CVSS-Scores, CPE-Übereinstimmungen hinzu
EU-Äquivalent	ENISA pflegt die EU-Schwachstellendatenbank (vorgeschrieben durch NIS2)

Funktionsweise von CVEs

Lebenszyklus einer Schwachstelle

+-------------------------------------------------------------+
|  1. ENTDECKUNG                                              |
|  Forscher/Hersteller/Angreifer findet Schwachstelle         |
+-------------------------------------------------------------+
                   ↓
+-------------------------------------------------------------+
|  2. CVE-ZUWEISUNG                                           |
|  CNA (CVE Numbering Authority) weist CVE-ID zu              |
|  Reserviert, aber noch nicht öffentlich                     |
+-------------------------------------------------------------+
                   ↓
+-------------------------------------------------------------+
|  3. VERÖFFENTLICHUNG                                        |
|  CVE-Eintrag auf cve.org veröffentlicht                     |
|  Enthält: Beschreibung, Referenzen, betroffene Produkte     |
+-------------------------------------------------------------+
                   ↓
+-------------------------------------------------------------+
|  4. ANREICHERUNG DURCH NVD                                  |
|  NVD fügt hinzu: CVSS-Score, CPE-Treffer, CWE-Kategorie     |
|  Erscheint in automatisierten Scan-Tools                    |
+-------------------------------------------------------------+
                   ↓
+-------------------------------------------------------------+
|  5. BEHEBUNG                                                |
|  Hersteller veröffentlicht Patch/Firmware-Update            |
|  Produkt-SBOM wird mit korrigierten Versionen aktualisiert  |
+-------------------------------------------------------------+

CVSS-Bewertung des Schweregrads

Jede CVE erhält einen CVSS-Score (Common Vulnerability Scoring System), der den Schweregrad angibt:

CVSS-Score	Schweregrad	Beispielhafte Auswirkung
9,0–10,0	Kritisch	Remote-Code-Ausführung, vollständige Geräteübernahme
7,0–8,9	Hoch	Privilegienerweiterung, Umgehung der Authentifizierung
4,0–6,9	Mittel	Offenlegung von Informationen, Denial-of-Service
0,1–3,9	Niedrig	Geringfügiges Informationsleck, theoretischer Exploit

Warum CVEs für Hardwarehersteller wichtig sind

Meldepflicht für Schwachstellen gemäß CRA

Die CRA schafft eine direkte Verbindung zwischen der CVE-Überwachung und rechtlichen Verpflichtungen:

CRA-Anforderung	Verbindung zu CVE
24-Stunden-Frühwarnung (an das als Koordinator benannte CSIRT und die ENISA)	Wird ausgelöst, wenn eine Schwachstelle in Ihrem Produkt aktiv ausgenutzt wird
Keine bekannten ausnutzbaren Schwachstellen bei der Bereitstellung	CVEs, die mit den Komponenten Ihrer SBOM übereinstimmen, müssen bewertet werden; die im Produkt ausnutzbaren müssen behoben werden, bevor es auf dem Markt bereitgestellt wird
Behandlung von Schwachstellen während des Unterstützungszeitraums (mindestens 5 Jahre, sofern das Produkt nicht voraussichtlich kürzer genutzt wird)	Die CVE-Überwachung muss über den gesamten Unterstützungszeitraum fortgesetzt werden
Sicherheitsupdates (zum Beispiel per OTA)	Korrekturen für ausnutzbare Schwachstellen müssen bereits in Betrieb genommene Geräte unverzüglich erreichen

Die Verbindung zwischen SBOM und CVE

Die SBOM Ihres Produkts ist der Schlüssel zur automatisierten CVE-Überwachung:

SBOM-Komponente	CVE-Risikobeispiel
FreeRTOS-Kernel 10.4.2	CVE-2021-31571 – Ganzzahlüberlauf bei der Erstellung von Queues
mbedTLS 2.28.0	CVE-2023-43615 – Buffer-Overread in TLS-Cipher-Suiten mit Stromchiffren
lwIP 2.1.3	CVE-2026-119053 – Out-of-Bounds-Lesezugriff im SNMP-Agenten
U-Boot 2023.04	CVE-2024-57256 – Speicherüberschreibung durch präpariertes ext4-Dateisystem
Linux-Kernel 5.15	Hunderte von CVEs pro Jahr – kontinuierliche Überwachung unerlässlich

Die automatisierte Pipeline: SBOM → CPE-Abgleich → CVE-Datenbankabfrage → Filterung nach Schweregrad → Entwurf der CRA-Meldung → Bereitstellung des Patches per OTA. Das ist es, was unser SBOM Monitoring Service bietet.

CVE-Überwachung für eingebettete Produkte

Spezifische Herausforderungen bei Embedded/IoT

Herausforderung	Beschreibung
Lange Bereitstellungszyklen	IoT-Geräte sind 10–15 Jahre im Einsatz; CVEs sammeln sich im Laufe der Zeit an
Begrenzte Ressourcen	Geräten fehlt möglicherweise die Bandbreite/der Speicher für häufige Patches
Komponentenverzug	Embedded-Anbieter verwenden oft ältere Versionen von Open-Source-Komponenten
Benutzerdefiniertes BSP	Board Support Packages von Chipherstellern können nicht nachverfolgte Komponenten enthalten
Verschachtelte Abhängigkeiten	Transitive Abhängigkeiten (Abhängigkeiten von Abhängigkeiten) sind oft nicht in der SBOM enthalten
Kein zentraler Updater	Anders als bei mobilen Betriebssystemen verwaltet jeder Hersteller seine eigene Update-Pipeline

Empfohlener Überwachungs-Workflow

SBOM generieren zur Build-Zeit (SPDX- oder CycloneDX-Format).
Komponenten zu CPE-Identifikatoren zuordnen für den Abgleich mit der NVD-Datenbank.
Kontinuierliches CVE-Scannen – automatisierte tägliche oder Echtzeit-Prüfungen gegen NVD/EPSS-Feeds.
Risikobasierte Triage – Priorisierung nach CVSS-Score, EPSS (Exploit Prediction Scoring System) und Produktexposition.
Patchen oder mitigieren – Korrekturen per OTA-Update bereitstellen oder Anleitungen zur Risikominderung veröffentlichen.
Über die einheitliche Meldeplattform der ENISA melden – bei aktiver Ausnutzung die 24-Stunden-Frühwarnung, die 72-Stunden-Meldung und den Abschlussbericht auslösen.

Offizielle Referenzen

CVE Program – MITRE Corporation – MITRE (CVE-Datenbank und Nummerierungsautorität)
National Vulnerability Database (NVD) – NIST (angereicherte CVE-Daten mit CVSS-Scores)