Zum Inhalt springen
Inovasense

CVE

CVE (Common Vulnerabilities and Exposures) ist der globale Standard zur Identifizierung von Cybersicherheitsschwachstellen, wobei jeder Schwachstelle eine eindeutige CVE-ID zugewiesen wird.

Definition
CVE (Common Vulnerabilities and Exposures) ist der globale Standard zur Identifizierung von Cybersicherheitsschwachstellen, wobei jeder Schwachstelle eine eindeutige CVE-ID zugewiesen wird.

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 Meldepflicht für Schwachstellen innerhalb von 24 Stunden gegenüber der ENISA zu erfüllen.

Wichtige Fakten

DetailInformation
Vollständiger NameCommon Vulnerabilities and Exposures
Verwaltet vonMITRE Corporation (USA, finanziert durch CISA)
ID-FormatCVE-JJJJ-NNNNN (Jahr + fortlaufende Nummer)
Gesamtanzahl veröffentlichter CVEs~240.000+ (Stand Anfang 2026)
Neue CVEs pro Jahr~25.000–30.000 (Tendenz steigend)
Öffentliche Datenbankcve.org
Datenbank mit ZusatzinformationenNVD (National Vulnerability Database) – fügt CVSS-Scores, CPE-Übereinstimmungen hinzu
EU-ÄquivalentENISA 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-ScoreSchweregradBeispielhafte Auswirkung
9,0–10,0KritischRemote-Code-Ausführung, vollständige Geräteübernahme
7,0–8,9HochPrivilegienerweiterung, Umgehung der Authentifizierung
4,0–6,9MittelOffenlegung von Informationen, Denial-of-Service
0,1–3,9NiedrigGeringfü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-AnforderungVerbindung zu CVE
24-Stunden-Meldung an ENISAWird ausgelöst, wenn eine CVE, die Ihr Produkt betrifft, aktiv ausgenutzt wird
Keine bekannten Schwachstellen bei AuslieferungAlle CVEs, die mit den Komponenten Ihrer SBOM übereinstimmen, müssen vor dem Inverkehrbringen behoben werden
5-jähriges SchwachstellenmanagementDie CVE-Überwachung muss über die gesamte Support-Lebensdauer des Produkts fortgesetzt werden
OTA-UpdatesDurch CVEs ausgelöste Patches müssen an bereits in Betrieb genommene Geräte verteilt werden

Die Verbindung zwischen SBOM und CVE

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

SBOM-KomponenteCVE-Risikobeispiel
FreeRTOS 10.4.3CVE-2021-31571 – Pufferüberlauf im TCP/IP-Stack
mbedTLS 2.28.0CVE-2023-43615 – Umgehung der Zertifikatsvalidierung
lwIP 2.1.3CVE-2023-36321 – Denial-of-Service durch fehlerhaftes Paket
U-Boot 2023.04CVE-2024-xxxxx – Umgehung von Secure Boot durch manipuliertes Image
Linux-Kernel 5.15Hunderte von CVEs pro Jahr – kontinuierliche Überwachung unerlässlich

Die automatisierte Pipeline: SBOM → CPE-Abgleich → CVE-Datenbankabfrage → Filterung nach Schweregrad → Erstellung des ENISA-Berichts → 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

HerausforderungBeschreibung
Lange BereitstellungszyklenIoT-Geräte sind 10–15 Jahre im Einsatz; CVEs sammeln sich im Laufe der Zeit an
Begrenzte RessourcenGeräten fehlt möglicherweise die Bandbreite/der Speicher für häufige Patches
KomponentenverzugEmbedded-Anbieter verwenden oft ältere Versionen von Open-Source-Komponenten
Benutzerdefiniertes BSPBoard Support Packages von Chipherstellern können nicht nachverfolgte Komponenten enthalten
Verschachtelte AbhängigkeitenTransitive Abhängigkeiten (Abhängigkeiten von Abhängigkeiten) sind oft nicht in der SBOM enthalten
Kein zentraler UpdaterAnders als bei mobilen Betriebssystemen verwaltet jeder Hersteller seine eigene Update-Pipeline

Empfohlener Überwachungs-Workflow

  1. SBOM generieren zur Build-Zeit (SPDX- oder CycloneDX-Format).
  2. Komponenten zu CPE-Identifikatoren zuordnen für den Abgleich mit der NVD-Datenbank.
  3. Kontinuierliches CVE-Scannen – automatisierte tägliche oder Echtzeit-Prüfungen gegen NVD/EPSS-Feeds.
  4. Risikobasierte Triage – Priorisierung nach CVSS-Score, EPSS (Exploit Prediction Scoring System) und Produktexposition.
  5. Patchen oder mitigieren – Korrekturen per OTA-Update bereitstellen oder Anleitungen zur Risikominderung veröffentlichen.
  6. An ENISA melden – bei aktiver Ausnutzung den 24h/72h/14d-Melde-Workflow auslösen.

Verwandte Begriffe

  • SBOM – Die Komponenten-Stückliste, die den automatisierten CVE-Abgleich ermöglicht.
  • ENISA – Die EU-Agentur, die durch CVEs ausgelöste Schwachstellenmeldungen erhält.
  • CRA – Die Verordnung, die CVE-Überwachung und Schwachstellenmanagement vorschreibt.
  • OTA-Update – Der Bereitstellungsmechanismus für durch CVEs ausgelöste Sicherheitspatches.

Offizielle Referenzen