Was ist ein CVE (Common Vulnerabilities and Exposures)?
Ein CVE, kurz für Common Vulnerabilities and Exposures, ist eine standardisierte Kennung, die eine öffentlich bekannt gemachte Sicherheitslücke referenziert. Der Zweck besteht darin, dass alle Beteiligten im Sicherheitsökosystem über dasselbe Problem sprechen, sobald eine Schwachstelle entdeckt wird.
Vor der Einführung von CVEs beschrieben Anbieter, Forscher und Sicherheitstools dieselbe Schwachstelle oft unterschiedlich. Das erschwerte die Koordination. Es war nicht immer klar, ob sich zwei Advisories auf denselben Fehler bezogen oder auf verschiedene. CVEs lösten dieses Problem durch ein einheitliches, gemeinsames Benennungssystem.
Erhält eine Schwachstelle einen CVE, bedeutet das: Das Problem ist anerkannt, dokumentiert und öffentlich referenzierbar. Es bedeutet nicht, dass die Schwachstelle schwerwiegend ist. Es bedeutet nicht, dass sie in jeder Umgebung ausnutzbar ist. Und es bedeutet nicht, dass sie sofort behoben werden muss.
Diese Unterscheidung ist entscheidend. CVEs beantworten eine eng gefasste Frage: Wie lassen sich bekannte Schwachstellen über Produkte, Anbieter und Tools hinweg konsistent identifizieren und nachverfolgen? Sie beantworten keine weiterreichenden Fragen zu Risiko, Auswirkung oder Priorisierung.
In der Praxis bilden CVEs das Bindegewebe des vulnerability management. Sicherheitsscanner melden Funde über CVE-Kennungen. Anbieter nutzen sie in Advisories und Patch-Hinweisen. Incident-Response-Teams verständigen sich damit über aktive Bedrohungen. Ohne CVEs würde diese Koordination zusammenbrechen.
Das CVE-Programm selbst wird von MITRE betreut, das festlegt, wie Schwachstellen benannt, nachverfolgt und veröffentlicht werden. Diese Rolle unterstreicht, dass CVEs ein neutrales Referenzsystem sind und kein Framework zur Risikobewertung.
Zu verstehen, was ein CVE ist und ebenso wichtig, was er nicht ist, bildet die Grundlage für ein wirksames vulnerability management. CVEs sagen, was existiert. Alles Weitere dreht sich darum, zu bestimmen, was wirklich zählt.
Was ein CVE tatsächlich bezeichnet
Ein CVE bezeichnet eine bestimmte, öffentlich bekannt gemachte Schwachstelle in einem definierten Produkt, einer Version oder einer Komponente. Im Kern beantwortet ein CVE eine sehr enge Frage: Über welches Problem sprechen wir?
Ein CVE-Eintrag enthält typischerweise eine kurze Beschreibung der Schwachstelle, Angaben zur betroffenen Software sowie Verweise auf Advisories oder Patches. Diese Informationen sind bewusst begrenzt. Ein CVE beschreibt nicht, wie sich eine Schwachstelle in der eigenen Umgebung verhält, ob sie erreichbar ist oder welchen Schaden sie bei einer Ausnutzung realistisch anrichten könnte.
Diese Begrenzung ist kein Mangel des CVE-Systems, sondern eine bewusste Entscheidung. CVEs sorgen für Konsistenz und Koordination in einem globalen Sicherheitsökosystem aus Anbietern, Forschern, Tools und Verteidigern. Um diese Rolle zu erfüllen, müssen CVEs umgebungsunabhängig bleiben.
Behandeln Teams CVEs als Risikobewertungen statt als Kennungen, beginnen die Probleme. Ein CVE kann auf dem Papier alarmierend wirken, in der Praxis aber völlig irrelevant sein. Ein anderer CVE mag unauffällig erscheinen, liegt jedoch auf einem kritischen attack path in einer Produktivumgebung. Der CVE selbst enthält nicht die Informationen, um diese beiden Fälle zu unterscheiden.
CVE-Kennungen im Detail
CVE-Kennungen folgen einem einfachen, standardisierten Format, etwa CVE-2021-44228. Die Kennung codiert das Jahr der Zuweisung und eine eindeutige Nummer, sagt aber nichts über Schweregrad, Ausnutzbarkeit oder Priorität aus.
Nach der Zuweisung durchläuft ein CVE einen Lebenszyklus. Details lassen sich aktualisieren, sobald mehr Informationen vorliegen. In manchen Fällen wird ein CVE angefochten oder zurückgezogen, wenn sich das Problem nicht bestätigen lässt oder sich später als keine Schwachstelle herausstellt. Während dieses Prozesses bleibt die Kennung der Anker, an dem sich Tools und Advisories ausrichten.
Vulnerability Scanner, Systeme für patch management und Sicherheits-Advisories stützen sich auf CVE-Kennungen, um Funde zu korrelieren. Mehrere Anbieter verweisen in unterschiedlichen Kontexten auf denselben CVE, doch die Kennung stellt sicher, dass alle über dasselbe zugrunde liegende Problem sprechen.
Das CVE-Programm wird von MITRE betreut, das die Zuweisung und Pflege der Kennungen steuert. Diese Rolle unterstreicht, dass CVEs neutrale Referenzen sind und keine Meinungen über Risiko oder Dringlichkeit.
CVE und CWE im Vergleich
CVEs werden oft mit CWEs verwechselt, doch sie erfüllen unterschiedliche Zwecke.
Ein CVE beschreibt eine bestimmte Schwachstelle in einer bestimmten Software. Ein CWE, kurz für Common Weakness Enumeration, beschreibt die übergeordnete Klasse von Schwäche, die zu der Schwachstelle geführt hat, etwa unzureichende Eingabevalidierung oder unsichere Authentifizierungslogik.
Praktisch gesehen ist ein CVE die konkrete Instanz, während ein CWE das Muster beschreibt. Viele verschiedene CVEs lassen sich auf denselben CWE zurückführen. Das Verständnis der CWE-Kategorien erklärt, warum ähnliche Schwachstellen immer wieder in unterschiedlichen Produkten und Versionen auftauchen.
CWE ersetzt CVE jedoch nicht. CVEs bleiben nötig, um einzelne Probleme nachzuverfolgen, die Offenlegung zu koordinieren und die Behebung zu steuern. CWE liefert Einblick in die Ursachen, während CVEs die gemeinsamen Referenzen bereitstellen, auf die sich die Abläufe im vulnerability management stützen.
Diese Unterscheidung verdeutlicht, warum Schwachstellendaten allein nicht genügen. CVEs und CWEs beschreiben, was existiert und warum es existiert. Um zu bestimmen, ob es zählt, braucht es zusätzlichen Kontext.
Schwachstelle und Angriffsfläche in Cloud-Umgebungen
Eine Schwachstelle und eine Angriffsfläche sind nicht dasselbe, auch wenn beide oft gleichgesetzt werden. Den Unterschied zu verstehen, ist entscheidend, um CVEs in modernen Cloud-Umgebungen einordnen zu können.
Eine Schwachstelle ist ein Fehler in Software, der sich potenziell ausnutzen lässt. Ein CVE zeigt, dass ein solcher Fehler existiert. Die Angriffsfläche beschreibt, ob dieser Fehler in einer realen Umgebung tatsächlich erreichbar und für einen Angreifer nutzbar ist. Sie hängt davon ab, wie die verwundbare Komponente betrieben wird, worauf sie zugreifen kann und wie sie mit dem restlichen System verbunden ist.
In klassischen On-Premises-Umgebungen war der Abstand zwischen Schwachstelle und Angriffsfläche oft kleiner. Systeme waren langlebig, Netzwerkgrenzen relativ statisch und Zuständigkeiten leichter nachzuvollziehen. In Cloud-Umgebungen vergrößert sich dieser Abstand erheblich.
Cloud-Architekturen bringen Abstraktions- und Dynamik-Ebenen mit sich, die verändern, wie ein Risiko entsteht. Dienste kommunizieren über APIs. Workloads skalieren automatisch. Container werden häufig neu gebaut. Identitäten und Zugriffsberechtigungen bestimmen die Erreichbarkeit oft stärker als die Netzwerktopologie allein. Dadurch kann eine verwundbare Komponente existieren, ohne ein nennenswertes Risiko zu bedeuten, während eine scheinbar geringfügige Schwachstelle unter den richtigen Bedingungen kritisch wird.
Deshalb tun sich CVEs allein schwer, in der Cloud das reale Risiko abzubilden. Ein CVE sagt nicht, ob ein verwundbarer Dienst aus dem Internet erreichbar oder isoliert ist. Er sagt nicht, ob die Workload mit minimalen Berechtigungen oder mit weitreichenden Administratorrechten läuft. Er sagt nicht, ob der Dienst auf sensible Daten zugreifen kann oder ob er auf einem Pfad liegt, den ein Angreifer realistisch durchlaufen könnte.
Ein Risiko entsteht dort, wo Schwachstelle und Angriffsfläche zusammentreffen.
Warum die Angriffsfläche den Unterschied macht
Die Angriffsfläche verwandelt eine theoretische Schwäche in eine praktische Bedrohung. In Cloud-Umgebungen wiegen einige Kontextfaktoren weit schwerer als die reine Zahl der Schwachstellen.
Erreichbarkeit aus dem Internet
Eine Schwachstelle in einer öffentlich erreichbaren API oder einem Load Balancer unterscheidet sich grundlegend von derselben Schwachstelle in einem internen Dienst ohne externen Zugriff. Die Erreichbarkeit entscheidet, ob ein Angreifer eine Ausnutzung überhaupt versuchen kann.
Identitäts- und Berechtigungskontext
Cloud-Workloads sind durch die Berechtigungen definiert, die sie tragen. Eine Schwachstelle in einem Dienst mit geringen Rechten hat begrenzte Auswirkungen, während dieselbe Schwachstelle in einer Workload mit weitreichenden IAM-Berechtigungen lateral movement oder privilege escalation ermöglicht.
Zugriff auf sensible oder regulierte Daten
Die Angriffsfläche wächst stark, wenn eine verwundbare Komponente auf Kundendaten, Finanzdaten, Zugangsdaten oder regulierte Informationen zugreifen kann. In solchen Fällen können selbst scheinbar geringfügige Schwachstellen ernste Folgen haben.
Attack Paths und Kombinationen
In der Cloud entstehen schwere Vorfälle oft aus Kombinationen und nicht aus einzelnen Fehlern. Ein CVE wird mitunter erst gefährlich, wenn er mit einer Fehlkonfiguration, einem offengelegten Secret oder zu weit gefassten Identitätsrichtlinien zusammentrifft. Diese attack paths bleiben selten sichtbar, solange Schwachstellen isoliert bewertet werden.
Diese Unterscheidung erklärt, warum vulnerability management scheitert, sobald Teams sich allein auf CVE-Listen und Schweregrad-Bewertungen verlassen. Die meisten Umgebungen enthalten zu jedem Zeitpunkt Tausende Schwachstellen. Nur ein kleiner Teil davon ist so erreichbar, dass ein reales Risiko entsteht.
Wirksames CVE-Management verlagert den Fokus, gerade in der Cloud, vom Zählen der Schwachstellen zum Verstehen der Angriffsfläche. Sobald Teams erkennen, welche CVEs erreichbar, folgenreich und mit kritischen Ressourcen verbunden sind, wird die Priorisierung nachvollziehbar statt zum Ratespiel.
CVSS-Bewertungen und ihre Grenzen
Das Common Vulnerability Scoring System, kurz CVSS, gilt oft als maßgeblich für den Schweregrad einer Schwachstelle. In der Praxis wurde CVSS entwickelt, um eine deutlich engere Frage zu beantworten, als die meisten Sicherheitsteams erwarten.
CVSS beschreibt auf standardisierte Weise die mögliche Auswirkung einer Schwachstelle in Isolation. Es bewertet Faktoren wie die Art der Ausnutzung und die möglichen Folgen einer erfolgreichen Ausnutzung. Damit eignet sich CVSS für Vergleich und Koordination über Tools und Anbieter hinweg, besonders wenn nur wenig Kontext vorliegt.
Was CVSS nicht leistet, ist die Bewertung des Risikos in einer konkreten Umgebung. CVSS-Bewertungen sind bewusst statisch und umgebungsunabhängig. Sie berücksichtigen nicht, wie Software betrieben wird, ob eine verwundbare Komponente erreichbar ist, mit welchen Berechtigungen sie läuft oder auf welche Daten sie zugreifen kann. Diese Faktoren liegen außerhalb des Bewertungssystems.
Deshalb kann derselbe CVE mit derselben CVSS-Bewertung in unterschiedlichen Umgebungen völlig verschiedene Risikoniveaus bedeuten. Eine als „kritisch" bewertete Schwachstelle mag in der Praxis nicht erreichbar sein, während ein Problem mittleren Schweregrads auf einem erreichbaren Dienst mit Zugriff auf sensible Daten liegt. CVSS behandelt beide Fälle gleich, weil es den umgebenden Kontext nicht sieht.
In Cloud-Umgebungen tritt diese Grenze deutlicher hervor. Die Infrastruktur ist dynamisch, Identitäten sind mächtig und Dienste sind auf Weisen vernetzt, für die CVSS nie ausgelegt war. Schweregrad-Bewertungen bleiben als Signal nützlich, taugen aber allein nicht als Entscheidungsgrundlage.
CVSS wird von FIRST gepflegt, und seine Rolle als gemeinsames Framework ist wertvoll. Probleme entstehen erst, wenn CVSS mehr leisten soll, als vorgesehen war.
Für ein wirksames vulnerability management, gerade in der Cloud, sollte CVSS als einer von vielen Faktoren gelten. Es hebt Probleme hervor, die Aufmerksamkeit verdienen; um zu bestimmen, was zuerst zu beheben ist, braucht es jedoch weitere Signale, vor allem zu Angriffsfläche, Identität und Auswirkung. Ohne diesen Kontext treiben Schweregrad-Bewertungen allein eine mengenbasierte Behebung an statt risikobasierten Handelns.
Wie CVEs zugewiesen und veröffentlicht werden
CVEs entstehen nicht automatisch, sobald eine Schwachstelle entdeckt wird. Jede Kennung durchläuft einen definierten Prozess der Zuweisung und Offenlegung, der Konsistenz, Koordination und verantwortungsvolle Veröffentlichung im Sicherheitsökosystem sicherstellt.
Wird eine Schwachstelle entdeckt, melden sie in der Regel Forscher, Anbieter oder Sicherheitsteams. Diese Meldung prüft eine CVE Numbering Authority, kurz CNA. CNAs sind Organisationen, die Schwachstellen validieren und CVE-Kennungen innerhalb eines bestimmten Bereichs zuweisen dürfen, etwa einer Produktlinie, einem Anbieter-Ökosystem oder einem Forschungsgebiet.
Das CVE-Programm selbst überwacht MITRE, das die Regeln für die Zuweisung festlegt und für Konsistenz im Ökosystem sorgt. Die Rolle von MITRE ist administrativ und koordinativ. MITRE bewertet weder Schweregrad noch Ausnutzbarkeit oder geschäftliche Auswirkung. Die Aufgabe besteht darin, ein vertrauenswürdiges, neutrales Identifikationssystem zu pflegen.
Sobald eine CNA bestätigt, dass ein Problem die Kriterien für einen CVE erfüllt, wird eine Kennung zugewiesen. In dieser Phase kann der CVE reserviert, aber noch nicht öffentlich bekannt gemacht sein. So erhalten Anbieter Zeit, Fixes zu entwickeln und eine verantwortungsvolle Offenlegung abzustimmen. Bei der Offenlegung wird der CVE mit einer ersten Beschreibung und Verweisen veröffentlicht und steht dann Schwachstellendatenbanken, Scannern und Advisories zur Verfügung.
Auch Sicherheitsforschungs-Organisationen können als CNAs auftreten. Wiz ist eine CVE Numbering Authority. Das bedeutet: Schwachstellen, die das Wiz-Forschungsteam entdeckt, erhalten direkt CVE-Kennungen und werden ohne unnötige Verzögerung an die breite Sicherheits-Community offengelegt. So werden cloud-spezifische Schwachstellen als Teil des öffentlichen CVE-Ökosystems schnell dokumentiert und geteilt.
Der zeitliche Ablauf von Zuweisung und Veröffentlichung variiert stark. Manche CVEs werden innerhalb weniger Tage zugewiesen und offengelegt. Andere brauchen Wochen oder Monate, etwa wegen aufwendiger Validierung, der Abstimmung mit Anbietern oder Embargo-Fristen. In dieser Zeit können sich Details ändern, sobald Forscher Auswirkung und betroffene Komponenten klarer verstehen.
Nicht jede gemeldete Frage wird am Ende ein gültiger CVE. Manche Kennungen werden zurückgezogen oder als angefochten markiert, wenn sich die Schwachstelle nicht reproduzieren lässt, sich als Konfigurationsproblem statt als Softwarefehler erweist oder die Kriterien für eine Offenlegung nicht erfüllt. Selbst nach der Veröffentlichung lassen sich CVE-Einträge aktualisieren, sobald neue Informationen vorliegen.
Dieser Prozess unterstreicht einen wichtigen Punkt. CVEs dokumentieren und verfolgen bekannte Schwachstellen auf konsistente Weise. Sie bilden weder aktuelle Exploit-Aktivität noch die Angriffsfläche in der Umgebung oder das geschäftliche Risiko ab. Die Existenz eines CVE zeigt, dass ein Problem besteht und wie es zu referenzieren ist. Ob es tatsächlich zählt, lässt sich erst mit zusätzlichem Kontext jenseits des Zuweisungsprozesses bestimmen.
Die eigentliche Herausforderung des CVE-Managements in der Cloud
An diesem Punkt tritt das Problem des CVE-Managements in Cloud-Umgebungen klar hervor. CVEs sind nützliche Kennungen. CVSS liefert ein allgemeines Signal zum Schweregrad. Zuweisung und Veröffentlichung folgen einem strukturierten Prozess. Und dennoch tun sich Sicherheitsteams schwer, eine einfache Frage zu beantworten: Was sollten wir zuerst beheben?
Die zentrale Herausforderung ist die Menge. Moderne Cloud-Umgebungen enthalten zu jedem Zeitpunkt routinemäßig Tausende oder Zehntausende CVEs. Viele dieser Schwachstellen werden über Basis-Images, Bibliotheken von Drittanbietern oder Managed Services vererbt. Jeden CVE als einzelne Aufgabe zu behandeln, überfordert die Kapazität zur Behebung rasch, selbst bei gut ausgestatteten Teams.
Cloud-Infrastruktur verändert sich zudem fortlaufend. Container werden neu gebaut, serverless Functions neu bereitgestellt und Dienste skalieren automatisch nach oben und unten. Manche Schwachstellen bestehen nur kurz. Andere halten sich hartnäckig, weil sie tief in gemeinsam genutzten Images oder Abhängigkeiten stecken. Diese ständige Bewegung erschwert es, sich auf statische Scans oder regelmäßige Reviews zu verlassen, um ein genaues Bild des Schwachstellenrisikos zu wahren.
Eine weitere Herausforderung ist die Zuständigkeit. In Cloud-Umgebungen ist das Team, das einen CVE-Alarm erhält, nicht immer das Team, das ihn beheben kann. Schwachstellen entstehen mitunter in Basis-Images, gemeinsam genutzten Plattformen oder vorgelagerten Bibliotheken, die anderswo gepflegt werden. Ohne klare Zuordnung zwischen einem CVE und den verantwortlichen Teams, Repositories oder Pipelines stockt die Behebung.
Vor allem scheitert CVE-Management in der Cloud, wenn Schwachstellen isoliert bewertet werden. Ein einzelner CVE erzählt selten die ganze Geschichte. Reales Risiko entsteht oft dort, wo Schwachstellen mit Angriffsfläche, Identitätsberechtigungen und Fehlkonfigurationen zusammentreffen. Ein CVE mit geringem Schweregrad wird kritisch, sobald er auf einem aus dem Internet erreichbaren Dienst mit Zugriff auf sensible Daten liegt. Umgekehrt birgt ein CVE mit hohem Schweregrad wenig Risiko, wenn er nicht erreichbar und eng eingegrenzt ist.
Deshalb geraten viele Organisationen in einen Kreislauf aus Rauschen. Dashboards füllen sich mit CVEs. SLAs werden verfehlt. Patch-Rückstände wachsen. Und doch bleibt die tatsächliche Risikoreduktion aus. Das Problem ist kein Mangel an Daten. Es ist ein Mangel an Kontext.
Wirksames CVE-Management in der Cloud erfordert einen anderen Ansatz. Statt zu fragen, wie viele Schwachstellen existieren, müssen Teams verstehen, welche Schwachstellen erreichbar sind, welche zählen und welche realistische Pfade zu Schaden eröffnen. Ohne diesen Wandel werden CVE-Programme zu Compliance-Übungen statt zu wirksamen Treibern von Sicherheitsergebnissen.
Wie Wiz Erkennung und Priorisierung von CVEs verändert
Wiz betrachtet CVE-Management durch die Linse von Unified Vulnerability Management (UVM). Statt Schwachstellen, Fehlkonfigurationen und Angriffsflächen als getrennte Problemfelder zu behandeln, bewertet Wiz sie gemeinsam als Teile derselben Risikooberfläche.
Klassisches vulnerability management behandelt CVEs als primäre Arbeitseinheit. Funde werden erzeugt, bewertet und weitgehend isoliert zur Behebung eingereiht. In Cloud-Umgebungen versagt dieses Modell, weil Schwachstellen selten allein auftreten. Reales Risiko entsteht daraus, wie Schwachstellen mit Angriffsfläche, Identität und Konfiguration zusammentreffen.
Wiz beginnt mit einer kontinuierlichen, agentless Erkennung von CVEs über Cloud-Workloads hinweg, darunter virtual machines, Container, serverless Functions und Managed Services. Das sichert eine breite Abdeckung in Umgebungen, in denen Workloads kurzlebig sind und sich ständig ändern. Doch die Erkennung ist nur der Einstieg, nicht das Ergebnis.
Im UVM-Modell gilt ein CVE als eines von vielen Signalen. Wiz korreliert jede Schwachstelle mit Laufzeitkontext wie Erreichbarkeit aus dem Internet, Identitätsberechtigungen und Zugriff auf sensible Daten. Diese vereinte Sicht macht es möglich, zwischen theoretisch schweren Schwachstellen und solchen zu unterscheiden, die in der Praxis reales Risiko schaffen.
Der Wiz Security Graph steht im Zentrum dieses Ansatzes. Er verknüpft CVEs mit Fehlkonfigurationen, zu weit gefassten Identitäten und erreichbaren attack paths. Eine Schwachstelle wird nicht allein wegen ihrer CVSS-Bewertung zur hohen Priorität, sondern weil sie auf einem Pfad liegt, der zu privilegiertem Zugriff oder kritischen Daten führt. Umgekehrt lassen sich CVEs ohne Angriffsfläche oder nennenswerte Auswirkung zurückstufen, ohne das Risiko zu erhöhen.
Hier verändert Wiz UVM die Diskussion. Statt zu fragen, welche CVEs existieren, erkennen Teams, welche Schwachstellen im Kontext ihrer Cloud-Architektur tatsächlich zählen. Schwachstellen, Angriffsflächen und attack paths werden gemeinsam bewertet und ergeben eine priorisierte Menge an Risiken, die nachvollziehbar und umsetzbar ist.
UVM erhöht zudem die Reaktionsgeschwindigkeit. Wird ein neuer CVE oder eine zero-day-Schwachstelle bekannt gemacht, können Teams mit Wiz rasch feststellen, ob betroffene Workloads vorhanden, erreichbar und mit sensiblen Ressourcen verbunden sind. Indem Wiz Schwachstellen mit Cloud-Ressourcen, Identitäten und Zuständigkeiten verknüpft, richtet sich die Behebung auf die Risiken, die sofortiges Handeln erfordern.
Schließlich reduziert UVM das Rauschen an der Quelle. Viele CVEs stammen aus gemeinsam genutzten Basis-Images und vererbten Komponenten. Wiz schafft Transparenz über diese Risikoquellen und ermöglicht es Teams, sie systematisch anzugehen, statt dieselben Probleme immer wieder über einzelne Workloads hinweg zu sichten.
In diesem Modell bleiben CVEs wichtig, sind aber nicht länger der Schwerpunkt. Unified Vulnerability Management verlagert den Fokus von Schwachstellenzahlen zur Risikoreduktion, indem es bewertet, wie sich Schwachstellen in realen Cloud-Umgebungen verhalten. Dieser Wandel erlaubt es Sicherheitsteams, von reaktiver CVE-Sichtung zu einem vorausschauenden, kontextbasierten Risikomanagement überzugehen.