Was ist eine CVE?

CVE steht für Common Vulnerabilities and Exposures. Das CVE-Programm vergibt eindeutige Kennungen für öffentlich bekannte Sicherheitslücken, beispielsweise CVE-2021-44228 für Log4Shell. Hersteller, Sicherheitsforscher, Scanner, Advisories und Administratoren können damit zweifelsfrei über dasselbe Problem sprechen. Eine CVE ist jedoch zunächst eine Referenz – weder ein Patch noch eine vollständige Risikobewertung.

Wie ist eine CVE-Kennung aufgebaut?

Eine Kennung besteht aus dem Präfix CVE, dem Jahr und einer fortlaufenden Nummer, etwa CVE-2025-12345. Das Jahr bezeichnet grundsätzlich das Jahr der Vergabe oder Reservierung und muss nicht mit Entdeckung, Veröffentlichung oder Angriffsbeginn übereinstimmen. Der Nummernblock besitzt mindestens vier Stellen, kann bei der großen Zahl neuer Einträge aber länger sein. Aus der Kennung selbst lassen sich weder Hersteller noch Produkt, Schwachstellenart oder Schweregrad ablesen.

Welche Informationen enthält ein CVE-Eintrag?

Ein veröffentlichter CVE Record enthält mindestens die Kennung, eine kurze Beschreibung, betroffene Produkte und Versionen sowie öffentliche Referenzen. Je nach herausgebender Stelle kommen präzisere Versionsbereiche, CWE-Zuordnungen, CVSS-Werte, Workarounds oder zusätzliche Herstellerinformationen hinzu. Die verlinkten Advisories sind häufig wichtiger als die Kurzbeschreibung, weil sie Voraussetzungen, Updates und konkrete Abhilfen ausführlicher erklären.

Wie entsteht eine CVE?

1. Schwachstelle entdecken: Ein Hersteller, Forscher oder anderer Beteiligter erkennt ein Sicherheitsproblem.
2. Zuständigkeit bestimmen: Eine CVE Numbering Authority (CNA), häufig der betroffene Hersteller oder ein Koordinationszentrum, bearbeitet die Anfrage.
3. Kennung reservieren: Die CNA weist frühzeitig eine CVE-ID zu, damit alle Beteiligten dieselbe Referenz verwenden.
4. Offenlegung koordinieren: Betroffene Versionen, Lösung, Zeitplan und öffentliche Informationen werden abgestimmt.
5. Record veröffentlichen: Sobald die Pflichtangaben vorhanden sind, übermittelt die CNA den Eintrag an die CVE List.
6. Eintrag aktualisieren: Neue Versionen, Referenzen oder Korrekturen können später ergänzt werden.

Nicht jede gefundene Schwachstelle erhält sofort eine CVE. Vor einer koordinierten Veröffentlichung sollen Details häufig vertraulich bleiben, damit Hersteller einen Patch vorbereiten können. Bei Bibliotheken und weiterverwendeten Komponenten muss außerdem geklärt werden, ob die Ursache in der Komponente selbst oder erst in der Integration eines Produkts liegt.

Was bedeuten RESERVED und REJECTED?

• RESERVED:
  Eine CNA hat die Kennung reserviert, aber noch keine öffentlich nutzbaren Details veröffentlicht. Das ist kein Beleg dafür, dass Informationen absichtlich zurückgehalten werden oder die Lücke besonders kritisch ist.
• PUBLISHED:
  Der Record enthält die erforderlichen Informationen und ist öffentlich in der CVE List verfügbar.
• REJECTED:
  Die Kennung soll nicht mehr verwendet werden, beispielsweise wegen eines Duplikats oder einer fehlerhaften Vergabe. Sie bleibt sichtbar, damit alte Referenzen nachvollziehbar sind.

Was unterscheidet CVE, NVD, CWE und CVSS?

Diese Daten können von unterschiedlichen Organisationen stammen und sich zeitlich versetzt ändern. Ein Hersteller kann einen anderen CVSS-Vektor bewerten als eine externe Datenbank, weil er andere Voraussetzungen annimmt. Teams sollten deshalb Quelle, Version und Bewertungsgrundlage dokumentieren, statt nur eine einzelne Zahl zu kopieren.

Bedeutet eine CVE automatisch ein hohes Risiko?

Nein. Eine CVE sagt zunächst, dass eine konkrete öffentlich bekannte Lücke referenziert wird. Ob das eigene Unternehmen betroffen ist, hängt von Produkt, Version, Konfiguration und Verwendung ab. Eine kritische Bibliothek kann zwar installiert sein, ohne dass der verwundbare Code erreichbar ist. Umgekehrt kann eine mittel bewertete Lücke in einem öffentlich zugänglichen, geschäftskritischen System hohe Priorität besitzen.

Auch ein sehr hoher CVSS-Wert bedeutet nicht automatisch, dass Angreifer die Lücke aktiv ausnutzen. Hinweise auf reale Exploitation liefert beispielsweise der CISA Known Exploited Vulnerabilities Catalog. EPSS schätzt täglich die Wahrscheinlichkeit, dass zu einer CVE innerhalb der nächsten 30 Tage Ausnutzungsaktivität beobachtet wird. Beide Signale ergänzen, aber ersetzen nicht den eigenen Kontext.

Wie sollten Unternehmen CVEs priorisieren?

1. Betroffenheit bestätigen: Produkt, genaue Version und gegebenenfalls verwundbare Funktion mit einem verlässlichen Asset- und Softwarebestand abgleichen.
2. Exposition prüfen: Erreichbarkeit, notwendige Rechte, aktive Funktionen und vorhandene Schutzmaßnahmen untersuchen.
3. Bedrohungslage bewerten: Öffentliche Exploits, bekannte aktive Ausnutzung, EPSS und relevante Threat Intelligence einbeziehen.
4. Auswirkung bestimmen: Betroffene Daten, Geschäftsprozesse, mögliche Angriffsketten und Wiederherstellbarkeit betrachten.
5. Behandlung festlegen: Patch, Konfigurationsänderung, Workaround, Isolation oder begründete Risikoakzeptanz mit Termin und Verantwortlichem dokumentieren.
6. Erfolg verifizieren: Nach der Änderung erneut prüfen und Scanner-Findings nicht ohne Nachweis schließen.

Ein Vulnerability Scanner kann bekannte Versionen und Merkmale finden. Falsch positive Ergebnisse, Backports und unvollständige Erkennung sind dennoch möglich. Der Scanner-Fund ist deshalb der Beginn einer technischen Bewertung, nicht deren Ende.

Welche Grenzen hat das CVE-System?

Nicht jede Sicherheitslücke besitzt eine CVE, und eine fehlende Kennung beweist nicht, dass ein Produkt sicher ist. Fehlkonfigurationen, interne Anwendungen, Geschäftslogikfehler und noch nicht veröffentlichte Schwachstellen können außerhalb der Liste liegen. Ein CVE Record kann anfangs unvollständig sein oder später korrigiert werden. Außerdem ist eine installierte Paketversion allein nicht immer ausreichend, weil Anbieter Sicherheitskorrekturen zurückportieren, ohne die sichtbare Hauptversion zu ändern.

CVE schafft eine gemeinsame Referenz und ist damit ein zentraler Baustein des Schwachstellenmanagements. Wirksam wird sie erst zusammen mit einem aktuellen Asset-Bestand, Herstellerinformationen, technischer Validierung, Bedrohungssignalen und nachvollziehbarer Risikopriorisierung.