Was sind CVE und CVSS?
CVE stellt eindeutige Kennungen und Records für öffentlich bekannt gemachte Cybersicherheitslücken bereit; CVSS v4.0 beschreibt ihre technischen Merkmale und bewertet deren Schweregrad.
Technische Einordnung: CVE beantwortet die Frage „Welche Schwachstelle ist gemeint?“. CVSS beantwortet die davon getrennte Frage „Wie schwer sind ihre technischen Merkmale?“. Eine CVE-ID und ein CVSS-Score erfüllen deshalb unterschiedliche Aufgaben.
Für wen sind CVE und CVSS relevant?
Im CVE-Programm vergeben und veröffentlichen CVE Numbering Authorities (CNAs) CVE-IDs und Records innerhalb ihres jeweiligen Zuständigkeitsbereichs. CVSS richtet sich an Personen und Organisationen, die Schwachstellen in Software, Hardware oder Firmware bewerten, Bewertungen veröffentlichen oder für das Schwachstellenmanagement verwenden. Die Programmdokumente ordnen keine allgemeine Nutzungspflicht für alle Organisationen an.
Wie entstehen eine CVE-ID und ein veröffentlichter Record?
Der bloße Fund einer Schwachstelle erzeugt nicht automatisch eine CVE-ID oder einen veröffentlichten CVE Record. Zuständig ist eine CNA innerhalb ihres Scopes; Vergabe und Veröffentlichung richten sich nach den CVE-Regeln und den erforderlichen Angaben. Ein reservierter Bezeichner ist noch kein veröffentlichter Record. Records können die Zustände Reserved, Published oder Rejected haben; ein abgelehnter Record bleibt sichtbar, damit seine Ungültigkeit erkennbar ist.
Wie funktioniert CVSS v4.0?
Eine Bewertung entsteht durch die Auswahl der Metrikwerte nach der CVSS-v4.0-Spezifikation. Sie unterscheidet Base-, Threat-, Environmental- und Supplemental-Metriken. Base-Metriken beschreiben zeit- und umgebungsunabhängige technische Eigenschaften. Threat- und Environmental-Metriken ergänzen Bedrohungslage und Einsatzumgebung. Supplemental-Metriken liefern weiteren Kontext, beeinflussen den Score aber nicht. Für die Interpretation müssen CVSS-Version und Vektor zusammen mit dem Wert angegeben werden.
Was sagen CVE-ID und CVSS-Score nicht aus?
Eine CVE-ID beweist weder, dass eine konkrete Umgebung betroffen ist, noch dass die Schwachstelle dort ausnutzbar ist. Dafür müssen mindestens Produkt, Version und Konfiguration geprüft werden. CVSS bewertet technische Schwere, nicht das vollständige Geschäftsrisiko. Auch Threat- und Environmental-Metriken ersetzen nicht die Bewertung von Assets, Exposition, regulatorischen Anforderungen sowie Kunden-, Finanz- und Reputationsfolgen.
Welche Fristen und Schwellen gelten?
CVE und CVSS setzen weder eine allgemeine Behebungsfrist noch eine Schwelle, ab der zwingend gehandelt werden muss. CVSS v4.0 verwendet Werte von 0,0 bis 10,0 sowie die qualitativen Stufen None, Low, Medium, High und Critical. Diese Stufen sind keine universellen Risikogrenzen oder Behebungsfristen. Abweichende Vorgaben können sich nur aus gesonderten Verträgen, Produktprozessen oder anwendbaren Branchen- und Rechtsregimen ergeben.
Welche Angaben sollten dokumentiert werden?
Praxisempfehlung: Eine belastbare Dokumentation verbindet die CVE-ID mit betroffenen Produkten und Versionen, der verwendeten CVSS-Version, dem Vektor sowie dem eigenen Bedrohungs- und Umgebungskontext. Scores unterschiedlicher CVSS-Versionen sollten nur mit klarer Versionsangabe eingeordnet werden. Behandlung, Begründung und Nachverfolgung sollten sich am eigenen Risiko orientieren.
Häufige Fehlannahmen
- „Jede gefundene Lücke erhält automatisch eine CVE-ID.“ Nein. Eine zuständige CNA vergibt die Kennung innerhalb ihres Scopes nach den CVE-Regeln.
- „Eine reservierte CVE-ID ist bereits ein veröffentlichter Schwachstellen-Record.“ Nein. Reservierung und Veröffentlichung sind unterschiedliche Zustände.
- „Eine CVE-ID beweist die eigene Betroffenheit oder Ausnutzbarkeit.“ Nein. Produkt, Version, Konfiguration und Exposition müssen für die konkrete Umgebung geprüft werden.
- „Ein hoher CVSS-Score bestimmt automatisch die Behebungspriorität.“ Nein. CVSS beschreibt technische Schwere; Geschäftsrisiko und lokaler Kontext müssen zusätzlich bewertet werden.
- „Critical bedeutet eine allgemein verbindliche Behebungsfrist.“ Nein. Die qualitative Stufe legt für sich keine universelle Frist oder Handlungspflicht fest.
- „Supplemental-Metriken erhöhen oder senken den CVSS-v4.0-Score.“ Nein. Sie ergänzen Kontext, fließen aber nicht in den Score ein.
Was die Geschäftsleitung tun sollte
Autoritative technische Empfehlung: Die folgenden Schritte unterstützen einen risikobasierten Schwachstellenprozess; sie sind keine aus CVE oder CVSS selbst folgende allgemeine Rechtspflicht.
- Relevante CVE-Daten regelmäßig mit dem eigenen Asset- und Softwareinventar abgleichen.
- Betroffenheit anhand von Produkt, Version, Konfiguration und Exposition prüfen lassen.
- Bei jeder Bewertung CVSS-Version, Score und Vektor nachvollziehbar dokumentieren.
- Threat- und Environmental-Kontext ergänzen und weitere Geschäftsrisiken getrennt bewerten.
- Risikobehandlung, Verantwortlichkeit, Entscheidung und Nachverfolgung in Patch- und Konfigurationsmanagement einbetten.
Für die Geschäftsleitung
Reichweite: CVE schafft eine gemeinsame Referenz für öffentlich bekannt gemachte Schwachstellen; CVSS v4.0 beschreibt deren technische Schwere. Entscheidung: Prioritäten dürfen nicht allein aus Kennung oder Score abgeleitet werden, sondern müssen Betroffenheit, Bedrohung, Umgebung und Geschäftsfolgen berücksichtigen. Nachweis: CVE-ID, Produkt- und Versionsbezug, CVSS-Version und Vektor, Kontext, Behandlungsentscheidung und Status sollten gemeinsam nachvollziehbar festgehalten werden.
