CWE, CVE & CVSS einfach erklärt: Unterschiede & Grenzen

Wer sich mit Anwendungssicherheit und Schwachstellenmanagement beschäftigt, stolpert innerhalb weniger Minuten über ein ganzes Alphabet an Abkürzungen: CWE, CVE, CVSS, EPSS. In Ticket-Systemen und den Reports gängiger CVE-Scanner werden diese Begriffe oft durcheinandergeworfen.

Dabei beschreiben sie völlig unterschiedliche Dinge – genauer gesagt: verschiedene Stationen im Lebenszyklus einer Sicherheitslücke. Wer den Unterschied versteht, erkennt auch schnell, warum die klassische Priorisierung nach reinen Zahlenwerten heute an ihre Grenzen stößt.

1. CWE: Welche Art von Fehler liegt im Code vor?

Alles beginnt im Quellcode. Jede Sicherheitslücke hat eine technische Ursache – einen Konstruktions- oder Programmierfehler. Genau hier setzt die CWE (Common Weakness Enumeration) an.

Die CWE ist ein gemeinschaftlich gepflegter Katalog für Schwachstellentypen in Software und Hardware. Sie beschreibt noch keinen konkreten Bug in einem bestimmten Produkt, sondern die abstrakte Kategorie des Fehlers.

Jede dieser Kategorien spannt sich primär über einen bestimmten Angriffsvektor auf. Ein Angriffsvektor beschreibt den Weg und die Methode, über die ein Angreifer eine Schwachstelle ausnutzen kann – also beispielsweise, ob er manipulierte Eingaben über ein Webformular einschleust, Speicherbereiche zum Überlaufen bringt oder fehlende Berechtigungsprüfungen einer API ausnutzt.

Typische Beispiele für CWEs sind:

• CWE-89 (SQL Injection): Benutzereingaben werden ungeprüft an eine Datenbankabfrage übergeben.
• CWE-79 (Cross-Site Scripting / XSS): Angreifer können fremden Script-Code in eine vertrauenswürdige Webseite einschleusen.
• CWE-787 (Out-of-bounds Write): Das Programm schreibt Daten über das Ende eines vorgesehenen Speicherpuffers hinaus.

Kurz gesagt: Die CWE benennt die Krankheit (z. B. „SQL Injection“), aber noch nicht den konkreten Patienten.

Tools für die statische Codeanalyse (SAST) suchen in Ihrem eigenen Code genau nach solchen CWE-Mustern.

2. CVE: Vom Fund zur offiziellen Registrierungsnummer

Was passiert nun, wenn ein Sicherheitsforscher oder ein Entwickler eine konkrete Schwachstelle (also eine CWE) in einer weit verbreiteten Open-Source-Bibliothek oder einer kommerziellen Software entdeckt?

In der Regel läuft dann ein koordinierter Meldeprozess an (Coordinated Vulnerability Disclosure):

1. Meldung an den Hersteller: Der Entdecker meldet die Lücke vertraulich an den Hersteller oder die Maintainer des Projekts.
2. Vendor Advisories: Viele Projekte veröffentlichen erste Warnungen und Patches direkt über eigene Kanäle – im Open-Source-Bereich häufig als GitHub Security Advisory (GHSA) oder über Sicherheitsbulletins der Hersteller.
3. Vergabe der CVE-Nummer: Damit weltweit alle Sicherheits-Tools über exakt dieselbe Lücke sprechen, wird ein eindeutiger Bezeichner benötigt: die CVE-ID (Common Vulnerabilities and Exposures).

Verwaltet wird dieses System von der MITRE Corporation in Zusammenarbeit mit sogenannten CVE Numbering Authorities (CNAs). Große Tech-Unternehmen, Open-Source-Stiftungen (wie GitHub oder die Apache Foundation) und nationale Sicherheitsbehörden agieren selbst als CNA und dürfen eigene CVE-Nummern nach dem Schema CVE-Jahr-Laufnummer (z. B. CVE-2026-12345) vergeben.

Während die CWE also das allgemeine Fehlermuster beschreibt, ist die CVE der konkrete Fingerabdruck eines einzelnen Vorfalls in einer spezifischen Softwareversion.

3. CVSS: Wie gefährlich ist die Schwachstelle?

Sobald hunderte CVEs bekannt sind, stehen Unternehmen vor einem praktischen Problem: Welche Lücke müssen wir zuerst schließen? Um diese Frage zu beantworten, wurde das CVSS (Common Vulnerability Scoring System) geschaffen. Es übersetzt die technischen Eigenschaften einer Schwachstelle in einen numerischen Wert von 0.0 bis 10.0.

Wie wird ein CVSS-Vektor berechnet?

Ein CVSS-Score fällt nicht vom Himmel, sondern wird aus einem sogenannten Vektor-String berechnet. Dieser String fasst verschiedene Metriken zusammen (Basis-Metriken):

• Attack Vector (AV): Muss der Angreifer physischen Zugriff auf das Gerät haben, im selben lokalen Netz sein oder reicht das offene Internet (AV:N für Network)?
• Attack Complexity (AC): Wie aufwendig ist der Angriff? Braucht es spezielle Vorbedingungen (AC:H) oder klappt es auf Knopfdruck (AC:L)?
• Privileges Required (PR) & User Interaction (UI): Braucht der Angreifer vorab Admin-Rechte oder muss ein Nutzer erst auf einen präparierten Link klicken?
• Auswirkungen (Impact): Wie stark sind Vertraulichkeit (Confidentiality), Integrität (Integrity) und Verfügbarkeit (Availability) betroffen?

Lange Zeit war CVSS v3.1 der unangefochtene Standard. Inzwischen wurde CVSS v4.0 eingeführt, das unter anderem feinere Abstufungen bei den Systemanforderungen und den Auswirkungen auf nachgelagerte Systeme (Subsequent Systems) ermöglicht.

Das Problem mit CVSS (und warum auch EPSS nicht alles löst)

In der Theorie klingt das System nach einer perfekten Sortiermaschine für das Schwachstellenmanagement. In der Praxis hat sich das blinde Vertrauen auf den CVSS-Score jedoch zu einem echten Problem entwickelt:

1. Score-Inflation: Da der Base-Score immer vom „Worst Case“ ausgeht, landet ein enormer Teil aller neuen CVEs im Bereich High (7.0–8.9) oder Critical (9.0–10.0). Wenn im Backlog plötzlich 400 „kritische“ Tickets liegen, verliert die Einstufung ihre steuernde Wirkung.
2. Stau bei der Bewertung (NVD-Backlog): Lange Zeit hat die US-amerikanische National Vulnerability Database (NVD) fast jede neue CVE zeitnah analysiert und mit einem unabhängigen CVSS-Score versehen. Seit 2024 kommt die NVD bei der schieren Flut neuer Meldungen kaum noch hinterher. Tausende aktuelle CVEs bleiben wochen- oder monatelang ohne offizielle NVD-Bewertung, oder die vergebenen Scores von Herstellern und Datenbanken widersprechen sich massiv.
3. Fehlender Bezug zur Realität: Ein CVSS-Score von 9.8 bedeutet nur, dass eine Lücke theoretisch leicht und mit großem Schaden ausnutzbar wäre – nicht, dass es dafür überhaupt einen funktionierenden Exploit gibt.

Die Zwischenlösung: EPSS und KEV

Um diese Lücke zu schließen, wurde das EPSS (Exploit Prediction Scoring System) ins Leben gerufen. Statt den theoretischen Schaden zu messen, berechnet EPSS mithilfe von historischen Daten und Machine Learning eine Wahrscheinlichkeit (zwischen 0 und 100 %), ob eine Schwachstelle in den nächsten 30 Tagen tatsächlich „in freier Wildbahn“ ausgenutzt wird. Ergänzt wird das oft durch den KEV-Katalog (Known Exploited Vulnerabilities) der US-Behörde CISA, der Lücken auflistet, die bereits aktiv von Angreifern genutzt werden.

Doch auch EPSS hat einen blinden Fleck: Es betrachtet die Welt global. Eine Lücke mit einem niedrigen EPSS-Wert ist für Ihr Unternehmen trotzdem brandgefährlich, wenn sie genau in Ihrer öffentlich erreichbaren Authentifizierungs-Logik steckt. Umgekehrt ist eine CVE mit hohem CVSS- und EPSS-Score für Sie völlig ungefährlich, wenn die betroffene Funktion der Bibliothek in Ihrem Code überhaupt nicht aufgerufen wird.

Die Alternative: Anwendungskontext, Data-Flow-Analyse und KI

Genau weil globale Scores wie CVSS und EPSS Ihre eigene Software-Architektur nicht kennen, findet in der Anwendungssicherheit gerade ein Umdenken statt. Statt Sicherheitsteams weiter mit theoretischen Risikowerten zu überfluten, rückt der konkrete Anwendungskontext in den Mittelpunkt.

Moderne Ansätze kombinieren dafür drei Ebenen:

1. Reachability Analysis (Erreichbarkeitsanalyse): Es wird nicht mehr nur per Dependency Scanner geprüft, ob eine verwundbare Bibliothek in der SBOM steht, sondern ob der verwundbare Code-Pfad von der eigenen Anwendung überhaupt aufgerufen wird.
2. Data-Flow- & Taint-Analysis (Datenflussanalyse): Selbst wenn eine verwundbare Funktion im Code erreichbar ist, muss ein Angreifer erst einmal kontrollierte Daten dorthin schleusen können. Eine Taint Analysis verfolgt den Datenfluss durch die Anwendung: Gelangt eine externe Nutzereingabe (z. B. aus einem HTTP-Request) tatsächlich ungefiltert und ohne vorherige Validierung (Sanitization) bis zur verwundbaren Stelle?
3. KI-gestützte Kontextbewertung: Um komplexe Frameworks, individuelle Sicherheitskontrollen und Architekturentscheidungen schnell zu durchdringen, hilft heute der gezielte Einsatz von KI-Modellen. Sie unterstützen dabei, den realen Code-Kontext rund um ein Finding zu analysieren und False Positives automatisiert auszusortieren.

Von theoretischen Scores zu echter Relevanz – mit Farion

Genau diesen Ansatz verfolgen wir mit Farion. Statt Entwicklerteams mit langen Listen voller CVEs und theoretischer CVSS-Scores allein zu lassen, führt Farion die Ergebnisse Ihrer Scanner zusammen und gleicht sie direkt mit Ihrem Anwendungskontext ab.

Durch die Kombination aus Abhängigkeitsanalyse, Reachability Analysis, automatisierter Datenflussbetrachtung und KI-gestützter Auswertung erkennt Farion zuverlässig, ob eine gemeldete CVE in Ihrer spezifischen Architektur tatsächlich ausnutzbar ist. So reduzieren Sie das Rauschen im Backlog drastisch und konzentrieren Ihre Entwicklungszeit exakt auf die Schwachstellen, die für Ihr Unternehmen ein echtes Risiko darstellen.