Eine Common Vulnerability and Exposure (CVE) ist eine bekannte, katalogisierte Sicherheitslücke. Wenn eine Schwachstelle eine CVE erhält, bedeutet dies, dass die Sicherheits-Community sie identifiziert, benannt und einer öffentlichen Datenbank hinzugefügt hat (hauptsächlich cve.org mit Bewertung und Kontext, hinzugefügt durch die National Vulnerability Database (NVD) des NIST), damit jeder sie nachschlagen und darauf reagieren kann. Das Tracking von CVEs gibt der Sicherheitswelt einen gemeinsamen Referenzpunkt, damit Teams bekannte Schwachstellen priorisieren und darauf reagieren können, bevor Angreifer sie ausnutzen. In der Theorie einfach, oder?
Hier ist der Haken: Über 48.000 CVEs wurden allein im Jahr 2025 veröffentlicht. Das sind 131 neue Schwachstellen jeden einzelnen Tag. KI-Modelle und Scanning-Funktionen machen die Entdeckung von Schwachstellen schneller und zugänglicher denn je, aber die Validierung von Befunden in großem Umfang ist schwieriger, weil das schiere Volumen der Einreichungen die Infrastruktur überfordert, die zu ihrer Bewältigung aufgebaut wurde. Die NVD bricht unter dem Volumen zusammen, und eine wachsende Zahl realer Schwachstellen wird überhaupt nicht gemeldet.
Dieser Leitfaden behandelt, wie CVEs funktionieren, wie sie bewertet werden, wo das System versagt und was Teams tun, um dem entgegenzuwirken.
Was beinhaltet ein CVE-Eintrag?
Eine CVE-ID ist wie eine Seriennummer, formatiert als: 'CVE-YYYY-#####'.
Jeder Eintrag enthält:
- CVE-ID
- Beschreibung
- Referenzen
- Zuweisung von CNA
- Erstellungsdatum des Datensatzes
Ältere CVE-Einträge können auch veraltete Felder wie Phase, Stimmen, Kommentare und Vorschläge enthalten, die in neuen Einträgen nicht mehr verwendet werden.

Wer pflegt die CVE-Datenbank?
Die kurze Antwort lautet: Keine einzelne Organisation tut dies. Und das ist zunehmend das Problem.
Die MITRE Corporation überwacht das CVE-Programm selbst, vergibt IDs und pflegt die offizielle Liste, und alle CVE-Datensätze können kostenlos durchsucht und verwendet werden. Die NVD war historisch der Ort, an dem diese rohen CVE-Einträge mit CVSS-Scores, Patch-Details und technischem Kontext angereichert wurden. Hier beziehen auch die meisten Sicherheitstools ihre Daten. Die Cybersecurity and Infrastructure Security Agency (CISA) leistet finanzielle Unterstützung. Andere Datenbanken, wie die CERT/CC Vulnerability Notes Database und GitHub Advisory, füllen zusätzliche Lücken.
Doch keine davon war jemals wirklich vollständig, und im Jahr 2026 sind die Risse kaum noch zu übersehen. NIST hat einen „risikobasierten“ Ansatz gewählt, der CVEs für US-Regierungssoftware und solche im Known Exploited Vulnerabilities (KEV)-Katalog priorisiert, während der Rest unaufbereitet bleibt und der wachsende Rückstand effektiv auf „nicht geplant“ verschoben wird. Das CVE-Programm von MITRE sah sich mit Finanzierungsproblemen konfrontiert. Die EU hat eine eigene Alternative, die European Vulnerability Database (EUVD), ins Leben gerufen, aber es ist noch zu früh, und sie ist immer noch stark auf die Synchronisierung mit der NVD angewiesen. Es gibt keine einzige Quelle der Wahrheit mehr, und die Abhängigkeit von einer einzelnen Datenbank bedeutet, dass Sie weniger Abdeckung und Sichtbarkeit haben, als Sie erhoffen. Genau dieses Problem sollte Aikido Intel lösen: Millionen von Open-Source-Paketen auf sicherheitsrelevante Patches zu überwachen, die es nie in eine offizielle Datenbank schaffen, und die Ergebnisse direkt in die Aikido-Plattform einzuspeisen, damit Nutzende automatisch benachrichtigt werden.
Wie werden CVEs gefunden und zugewiesen?
Jeder kann eine Schwachstelle melden: Sicherheitsunternehmen, unabhängige Forschende, einzelne Entwickelnde, sogar interessierte Nutzende. Viele Organisationen betreiben Bug-Bounty-Programme, die Forschende für gültige Funde bezahlen, und Open-Source-Projekte verlassen sich typischerweise auf die Offenlegung durch die Community.
Sobald eine Schwachstelle gemeldet wird, validiert eine CVE Numbering Authority (CNA) diese, weist eine CVE-ID zu, verfasst eine kurze Beschreibung und fügt Referenzen hinzu, bevor sie in der offiziellen CVE-Liste veröffentlicht wird. CNAs sind von MITRE autorisierte Organisationen, die CVEs innerhalb eines definierten Umfangs zuweisen dürfen, darunter große Anbieter wie Microsoft, Google und RedHat, Open-Source-Stiftungen wie die Python Software Foundation, Sicherheitsforschungsunternehmen sowie Plattformen wie Django und GitLab. Typischerweise wird eine CVE-ID zugewiesen, bevor die Schwachstelle öffentlich gemacht wird. Anbieter halten die Details geheim, während sie einen Fix entwickeln und testen, und legen dann alles auf einmal offen. Dies wird als Coordinated Disclosure bezeichnet, der weithin empfohlene Standard für die verantwortungsvolle Meldung von Schwachstellen, unterstützt von CISA, ENISA und FIRST.
Nicht jedes gemeldete Problem qualifiziert sich. Drei Kriterien müssen erfüllt sein:
- Unabhängig behebbar: Der Fehler kann eigenständig behoben werden, unabhängig von anderen Bugs.
- Vom Anbieter bestätigt: Der Anbieter bestätigt, dass das Problem ein Sicherheitsrisiko darstellt, oder ein Drittbericht demonstriert dessen Auswirkungen.
- Betrifft eine Codebasis: Wenn eine Schwachstelle mehrere Produkte betrifft, erhält jedes seine eigene CVE. Datensätze werden so isoliert wie möglich gehalten.
Wie finde ich CVE-Einträge?
CVE-Informationen sind kostenlos und öffentlich zugänglich. Für einen Live-Feed neuer Einträge folgen Sie @CVEnew auf X. Bei der aktuellen Rate von über 130 neuen CVEs pro Tag geht es schnell voran. Für den Massenzugriff auf historische Datensätze bis zurück ins Jahr 1999 bietet CVE.org/Downloads die vollständige Datenbank über ein GitHub-Repository im JSON 5.0/5.1-Format an, das etwa alle sieben Minuten aktualisiert wird. CVEdetails.com bietet eine zugänglichere, durchsuchbare Oberfläche mit täglichen Updates.
Wie ordnet man Ihre Bibliotheken der richtigen CVE zu?
Bei der Analyse einer Schwachstelle ist es entscheidend, Paketnamen und Versionsnummer abzugleichen, um sicherzustellen, dass Sie die richtige CVE für Ihre spezifische Abhängigkeit betrachten. Tools wie Aikido übernehmen dies automatisch, indem sie Paketnamen und Versionen mit Schwachstellendatenbanken abgleichen, sodass Sie dies nicht manuell tun müssen.
Was ist CVSS-Scoring?
Das CVSS (Common Vulnerability Scoring System) ist der Standard zur Bewertung des Schweregrads einer Schwachstelle auf einer Skala von 0,0 bis 10,0. Die meisten CVE-Einträge enthalten einen CVSS-Score, der Sicherheitsteams einen schnellen Überblick über die Schwere eines Fehlers gibt. CVSS-Scores werden typischerweise von der NVD zugewiesen als Teil ihres Anreicherungsprozesses, obwohl CNAs ebenfalls Scores bereitstellen können. Bei Uneinigkeit können beide aufgeführt werden.
Wie wird ein CVSS-Score berechnet?
CVSS v4.0 setzt sich aus vier Metrikgruppen zusammen:
- Basis: erfasst die intrinsischen Merkmale einer Schwachstelle, die über die Zeit konstant bleiben
- Bedrohung: spiegelt wider, wie sich diese Merkmale basierend auf realen Exploitation-Aktivitäten ändern
- Umgebung: berücksichtigt Faktoren, die spezifisch für die Einrichtung Ihrer Organisation sind
- Zusätzlich: fügt zusätzlichen Kontext hinzu, ohne den Endscore zu beeinflussen
Was ist die CVSS-Bewertungsskala?
Die aktuelle (v4.0) CVSS-Bewertungsskala umfasst fünf Kategorien:
- Kritisch (9.0–10.0)
- Hoch (7.0–8.9)
- Mittel (4.0–6.9)
- Niedrig (0.1–3.9)
- Keine (0.0)

Um die Skala in den Kontext zu setzen, hier einige reale Beispiele:
- Kritisch: CVE-2021-44228 (Log4Shell). CVSS v3.1-Score: 10.0. Eine Remote Code Execution in Apache Log4j. Ein Angreifer könnte durch das Senden einer speziell präparierten Log-Nachricht beliebigen Code auf einem Server ausführen. Eine der schwerwiegendsten jemals veröffentlichten Schwachstellen.
- Hoch: CVE-2017-0144 (EternalBlue). CVSS v3.1-Score: 8.8. Eine Schwachstelle in Windows SMB (Server Message Block). Ursprünglich von der NSA als Exploit entwickelt, wurde sie 2017 geleakt und fast unmittelbar in den WannaCry- und NotPetya-Ransomware-Angriffen eingesetzt, die weltweit Schäden in Milliardenhöhe verursachten.
Für die niedrigeren Stufen sind bekannte Beispiele seltener, da Schwachstellen mit geringer Schwere selten Schlagzeilen machen. In der Praxis:
- Mittel: Umfasst typischerweise Schwachstellen, die spezifische Bedingungen für ihre Ausnutzung erfordern, zum Beispiel eine Cross-Site-Scripting-Schwachstelle, die Benutzerinteraktion benötigt, oder eine Fehlkonfiguration, die nicht-kritische Daten offenlegt.
- Niedrig: Schwachstellen, die lokalen Zugriff oder ungewöhnliche Bedingungen erfordern, zum Beispiel eine Konfigurationsdatei mit Standard-Zugangsdaten, auf die nur lokal zugegriffen werden kann.
- Keine: Ein gemeldetes Problem ohne bestätigte Sicherheitsauswirkungen
Laden Sie eine Kopie des vollständigen Benutzerhandbuchs zum CVSS-Bewertungssystem herunter.
Wie finde ich einen CVSS-Score für einen CVE-Eintrag?
CVSS-Scores werden direkt auf der Datensatzseite jeder CVE im NVD angezeigt, mit Unterstützung für v3.x- und v4.0-Scores, wo verfügbar. Beachten Sie, dass mit der Einschränkung der NVD-Anreicherung Scores fehlen oder ausschließlich auf der Bewertung des Einreichenden statt auf unabhängiger Analyse basieren können. Aikido's vulnerability database ist eine nützliche Querverweisquelle, die auf mehreren Quellen statt nur auf dem NVD basiert.
Was ist ein CWE?
Common Weakness Enumeration (CWE) ist eine von der Community entwickelte Liste gängiger Software- und Hardwareschwachstellen, die von MITRE gepflegt wird. Das Hauptziel von CWE ist es, Schwachstellen an der Quelle zu stoppen und die häufigsten Fehler zu eliminieren, bevor Produkte ausgeliefert werden. Es bietet Entwickelnden zudem ein gemeinsames Framework zur Diskussion und Behebung von Sicherheitsbedrohungen, mit direkten Zuordnungen zu Schwachstellendatenbanken wie CVE.
Der Hauptunterschied: CWE beschreibt die zugrunde liegende Schwäche, die zu einer Schwachstelle führt, während CVE eine spezifische Instanz dieser Schwachstelle identifiziert. Stellen Sie sich CWE als die Kategorie und CVE als das Vorkommen vor. Wie CVE verfügt CWE über ein eigenes Schweregrad-Bewertungssystem mittels CWSS und CWRAF.
Werfen Sie einen Blick auf die 25 gefährlichsten CWEs für 2025.
Warum das CVE-Monitoring schwieriger wird
Das Volumenproblem ist real: Die CVE-Einreichungen stiegen zwischen 2020 und 2025 um 263 %, und die Einreichungen in den ersten drei Monaten des Jahres 2026 sind fast ein Drittel höher als im gleichen Zeitraum des Vorjahres. Dieses Wachstum beschleunigt sich nur, und Open-Source-Registries sind ein wichtiger Grund dafür.
KI hat die Hürde für die Veröffentlichung von Open-Source-Paketen drastisch gesenkt, und die Registries spüren dies. Die Menge der eingehenden Pakete bedeutet, dass eine sinnvolle Überprüfung zunehmend seltener wird, und die Infrastruktur zur Verfolgung und Kontextualisierung von Schwachstellen steht unter dem gleichen Druck.
Das NVD wurde entwickelt, um jede CVE anzureichern, indem es CVSS-Scores, Produktlisten und technischen Kontext hinzufügt, die rohe CVE-Datensätze tatsächlich nutzbar machen. NIST reicherte 2025 fast 42.000 CVEs an, was 45 % mehr ist als in jedem Vorjahr. Doch diese gesteigerte Produktivität reichte nicht aus, um mit den wachsenden Einreichungen Schritt zu halten. Wie oben erwähnt, hat NIST die Anreicherung für die Mehrheit der CVEs nun depriorisiert. Die Tools, auf die Ihr Team angewiesen ist, um Schwachstellen aufzudecken und zu bewerten, arbeiten für einen wachsenden Teil des CVE-Universums mit unvollständigen Daten, ohne Sie darüber zu informieren.
Die Grenzen von CVEs: Was nicht gemeldet wird
Das NVD-Problem ist nur ein Teil der Geschichte. Das tiefere Problem ist, dass CVEs nur das abdecken, was offengelegt wird, und vieles eben nicht.
In einer einzigen Woche des Aikido Intel-Monitorings hatten 12 von 16 markierten Schwachstellen überhaupt keine CVE zugewiesen bekommen. Dies waren auch keine obskuren Randfälle. Axios, mit 56 Millionen wöchentlichen npm-Downloads, patchte stillschweigend eine Prototype Pollution-Schwachstelle, die immer noch keine CVE hat. Apache ECharts patchte ein Cross-Site-Scripting-Problem und legte es nie offen. Von den Schwachstellen, die schließlich eine CVE erhielten, betrug die durchschnittliche Zeit vom Patch bis zur Offenlegung 27 Tage, wobei einige bis zu neun Monate dauerten.
Anstatt sich auf zentralisierte Datenbanken zu verlassen, nutzt Intel maßgeschneiderte LLMs, um Changelogs, Release Notes und Commit-Nachrichten über Millionen von Open-Source-Paketen hinweg zu scannen. So werden sicherheitsrelevante Patches aufgedeckt, bevor sie eine CVE-ID erhalten, und mit fünf wichtigen Schwachstellendatenbanken für eine breitere Abdeckung abgeglichen. Wenn keine Offenlegung existiert, validieren und veröffentlichen Aikido-Sicherheitsingenieure eine Warnmeldung mit einer Aikido Vulnerability ID. Im ersten Jahr wurden 67 % der von Intel markierten Schwachstellen noch nie in einer öffentlichen Datenbank offengelegt. Intel speist direkt in die Aikido-Plattform ein, sodass Benutzer bei einer neuen Schwachstelle automatisch benachrichtigt werden, noch bevor ihr eine CVE zugewiesen wurde.
Was kann ich tun, um eine starke Security Posture aufrechtzuerhalten?
Nicht jede CVE ist Ihr Problem. Sie benötigen einen mehrschichtigen Ansatz. CVSS-Scores sind ein nützlicher Ausgangspunkt, berücksichtigen aber nicht Ihren spezifischen Kontext. Ein aussagekräftigeres Signal ist der KEV-Katalog von CISA: Wenn dort eine CVE aufgeführt ist, wird sie aktiv in der Praxis ausgenutzt. Doch KEV deckt weniger als 1 % aller CVEs ab und neigt zu Schwachstellen im Netzwerkperimeter, ist also bei weitem nicht erschöpfend.
Das Exploit Prediction Scoring System (EPSS) ist eine weitere nützliche Schicht. Es prognostiziert die Wahrscheinlichkeit, dass eine Schwachstelle innerhalb der nächsten 30 Tage ausgenutzt wird, basierend auf realer Bedrohungsaufklärung, und hilft Ihnen, die große Anzahl von CVEs zu depriorisieren, die wahrscheinlich nie als Waffe eingesetzt werden. Aikido unterstützt die EPSS-basierte Priorisierung nativ und stuft Probleme mit geringem Risiko automatisch herab, damit sich Ihr Team auf das Wesentliche konzentrieren kann.
Bevor Sie eine Schwachstelle eskalieren, beachten Sie:
- Erreichbarkeit: Die anfällige Funktion ist in Ihrer Anwendung möglicherweise nicht erreichbar, ein Hauptgrund, warum die Erreichbarkeitsanalyse und nicht rohe CVSS-Scores Ihre Priorisierung bestimmen sollte.
- Geschäftliche Auswirkungen: Die betroffene Komponente berührt möglicherweise keine kritischen Systeme, Kundendaten oder Kernoperationen.
- Einzigartige Umgebung: Benutzerdefinierte oder Legacy-Systeme können andere Risikoprofile aufweisen, als die Standard-CVE-Beschreibung annimmt.
- Bestehende Kontrollen: Möglicherweise haben Sie bereits Abwehrmaßnahmen implementiert, die das Risiko neutralisieren.
- Ressourcenbeschränkungen: Alles zu beheben ist unrealistisch. Priorisieren Sie, was tatsächlich ausnutzbar und wirkungsvoll ist.
Einen Vulnerability Scanner erhalten
Der beste Ausgangspunkt ist Aikido Security, eine Plattform, die speziell entwickelt wurde, um das Rauschen zu durchbrechen, das die meisten CVE-Scanner anstrengend macht. Herkömmliche Scanner zeigen Hunderte von rohen Warnmeldungen an, unabhängig davon, ob eine Schwachstelle in Ihrer Umgebung tatsächlich ausnutzbar ist. Die Erreichbarkeitsanalyse von Aikido verfolgt Ausführungspfade durch Ihren Code, um zu bestimmen, welche Schwachstellen tatsächlich erreicht und ausgelöst werden können. Dabei werden nicht erreichbare Probleme, Fehlalarme und irrelevante Ergebnisse herausgefiltert, wodurch oft eine Rauschreduzierung von bis zu 95 % erreicht wird.

Dem CurVE zuvorkommen
CVEs beschreiben Schwachstellen, die bereits identifiziert und katalogisiert wurden. Bis eine CVE veröffentlicht wird, hatten Angreifende möglicherweise bereits Tage oder Wochen Zeit, darauf zu reagieren. Und wie wir oben gesehen haben, erhalten viele Schwachstellen überhaupt keine CVE.
Vorausschauend zu handeln bedeutet mehr als nur reaktives Patchen. Halten Sie Abhängigkeiten auf dem neuesten Stand und prüfen Sie Ihren Code anhand der OWASP Top 10 2025 und der CIS Compliance-Benchmarks, den Standardwerkzeugen zur Identifizierung der häufigsten Schwachstellen und grundlegenden Sicherheitsfehlkonfigurationen. Sie können Ihre OWASP- und CIS-Scores direkt in Aikido überprüfen. Für Bedrohungen, die noch nicht katalogisiert wurden, überwacht Aikido Intel über 4,3 Millionen Open-Source-Pakete, um Schwachstellen zu erkennen, bevor sie eine CVE-ID erhalten.
Sehen Sie, welche CVEs Ihre Codebasis tatsächlich betreffen.
{{cta}}

