Schweregrad und Risikobewertung mit CVSS

Was CVSS misst und was nicht

Das Common Vulnerability Scoring System (CVSS) ist ein offener, von FIRST.Org gepflegter Standard, der den Schweregrad einer Schwachstelle in einem numerischen Wert von 0.0 bis 10.0 ausdrückt. Die NVD-Definition ist dabei eindeutig: Der Base Score spiegelt die Schwere (severity) wider - CVSS ist kein Maß für Risiko (CVSS is not a measure of risk). Diese Unterscheidung ist der wichtigste Ausgangspunkt jeder Priorisierung: Der Wert beschreibt, wie schlimm ein technischer Fehler im Prinzip ist, nicht wie wahrscheinlich oder wie geschäftskritisch seine Ausnutzung in einer konkreten Umgebung wäre.

CVSS gliedert die Bewertung in Metrik-Gruppen. In CVSS v3.1 sind das Base, Temporal und Environmental. CVSS v4.0 ändert diese Struktur zu Base, Threat, Environmental und Supplemental. Die Base-Gruppe erfasst die intrinsischen, über Zeit und Umgebung konstanten Eigenschaften der Schwachstelle. Die übrigen Gruppen sind dazu gedacht, diesen Grundwert an die reale Lage anzupassen - genau hier setzen die meisten Organisationen aber aus.

In der Praxis veröffentlicht die NVD ausschließlich Base-Metriken; Threat-, Temporal- und Environmental-Werte werden laut NIST nicht bereitgestellt, weil sie umgebungs- und zeitabhängig sind. Ein veröffentlichter Score ist daher fast immer ein reiner Base Score - also bewusst der pessimistische Ausgangswert, der die Anpassung durch den Konsumenten noch vor sich hat.

CVSS-Schweregrad, EPSS und Business-Impact im Vergleich

Schweregrad-Stufen und der Vektor

CVSS bildet den numerischen Wert optional auf qualitative Schweregrad-Stufen ab. Die Schwellen sind in v3.1 und v4.0 identisch: None bei 0.0, Low bei 0.1-3.9, Medium bei 4.0-6.9, High bei 7.0-8.9 und Critical bei 9.0-10.0. Die in vielen Tools übliche Stufe Info (informativ) ist kein Teil der CVSS-Spezifikation, sondern eine Konvention von Scannern und Pentest-Werkzeugen für Befunde ohne direkten Schweregrad.

Jede Bewertung wird zusätzlich als Vektor-String ausgedrückt - eine kompakte, nachvollziehbare Notation aller verwendeten Metrikwerte. Ein v3.1-Vektor sieht etwa so aus: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N. In v4.0 entfällt die Scope-Metrik; stattdessen werden Auswirkungen getrennt nach Vulnerable System (VC/VI/VA) und Subsequent System (SC/SI/SA) erfasst, und es kommt die neue Metrik Attack Requirements (AT) hinzu. Ein vollständiger Base-Vektor lautet dann CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N.

Wichtig für die Kommunikation: v4.0 führt eine Nomenklatur ein, die offenlegt, welche Gruppen in den Wert eingeflossen sind - CVSS-B (nur Base), CVSS-BT (Base und Threat), CVSS-BE (Base und Environmental) und CVSS-BTE (alle drei). Diese Kennzeichnung soll bei jedem angezeigten Wert mitgeführt werden, damit klar ist, ob es sich um den rohen Grundwert oder um eine an die Umgebung angepasste Bewertung handelt.

Warum CVSS API-Logikfehler unterschätzt

CVSS wurde für klassische, technische Schwachstellen entworfen - Speicherfehler, Injection, fehlende Authentifizierung. Bei API-Logikfehlern stößt das Modell an eine grundsätzliche Grenze: Es bewertet die technische Schwere des Mechanismus, nicht den geschäftlichen Wert der Daten und Funktionen dahinter.

Das deutlichste Beispiel ist BOLA (Broken Object Level Authorization, API1:2023). OWASP bewertet BOLA als Exploitability: Easy, Prevalence: Widespread, Detectability: Easy und Technical Impact: Moderate - der geschäftliche Impact ist jedoch ausdrücklich als Business Specific eingestuft. Der Angriff selbst ist trivial: Ein Angreifer manipuliert eine Objekt-ID in der Anfrage und greift auf fremde Datensätze zu. Wie schwer das wiegt, hängt vollständig davon ab, was hinter dem Objekt steht - eine harmlose Anzeigeeinstellung oder die Gesundheitsdaten, Umsätze oder Fahrzeugsteuerung tausender Nutzer.

Genau diesen Kontext kann ein Base Score nicht abbilden. Eine massenhafte Datenexposition über einen GET-Endpunkt erscheint als Confidentiality impact, ohne den Faktor zu kennen, dass dieselbe Lücke über alle Objekte iterierbar ist und damit den gesamten Datenbestand offenlegt. Auch BFLA (fehlende Funktionsebenen-Autorisierung) und Fehler in Business Flows teilen dieses Muster: technisch unscheinbar, geschäftlich potenziell existenzbedrohend. Wer ausschließlich nach CVSS-Wert priorisiert, schiebt solche Befunde systematisch nach hinten - obwohl sie laut OWASP zu den häufigsten und folgenschwersten API-Risiken zählen.

Kombination mit Business-Impact und EPSS

Belastbare Priorisierung entsteht erst, wenn der CVSS-Schweregrad um zwei Dimensionen ergänzt wird: die Wahrscheinlichkeit der Ausnutzung und den geschäftlichen Impact.

Für die Wahrscheinlichkeit liefert das EPSS (Exploit Prediction Scoring System, ebenfalls von FIRST.Org) einen empirischen Wert. EPSS schätzt als Wahrscheinlichkeit zwischen 0 und 1, dass eine veröffentlichte CVE in den nächsten 30 Tagen in freier Wildbahn ausgenutzt wird, und aktualisiert diesen Wert täglich. EPSS ersetzt subjektive Schweregrad-Urteile durch beobachtete Ausnutzungssignale und ist damit eine sinnvolle Ergänzung, nicht ein Ersatz für CVSS: CVSS sagt, wie schlimm es wäre, EPSS sagt, wie wahrscheinlich es passiert. Zu beachten ist, dass EPSS an CVE-Einträge gebunden ist und für die meisten API-Logikfehler, die keine CVE erhalten, schlicht keinen Wert liefert.

Für den Business-Impact bietet die OWASP Risk Rating Methodology ein einfaches Gerüst: Risk = Likelihood × Impact, wobei der Impact in Technical Impact (Vertraulichkeit, Integrität, Verfügbarkeit, Nachvollziehbarkeit) und Business Impact (finanzieller Schaden, Reputationsschaden, rechtliche Folgen, Datenschutzverletzung) zerfällt. OWASP betont, dass dieses Modell für die jeweilige Organisation angepasst werden muss - was technisch ein Medium ist, kann geschäftlich Critical sein, wenn personenbezogene Daten betroffen sind und damit Meldepflichten nach DSGVO greifen.

Befunde priorisieren in der Praxis

Für die Priorisierung von API-Befunden hat sich ein dreistufiges Vorgehen bewährt, das CVSS als Eingangsgröße nutzt, aber nicht als alleinige Entscheidung:

1. Schweregrad bestimmen (CVSS Base): Den technischen Grundwert und Vektor ermitteln und sauber als CVSS-B kennzeichnen, damit niemand ihn für eine fertige Risikobewertung hält.
2. Umgebung anrechnen (Environmental, Business-Impact): Den Base Score über die Environmental-Metriken und die OWASP-Faktoren an die konkrete API anpassen - welche Daten, welche Nutzergruppen, welche Compliance-Pflichten hängen am Befund? Bei BOLA und BFLA ist diese Stufe die eigentlich entscheidende.
3. Wahrscheinlichkeit gewichten (EPSS, Threat): Wo eine CVE existiert, EPSS und die Threat-Metrik Exploit Maturity (Stadium der Exploit-Verfügbarkeit) heranziehen, um bekannte und aktiv ausgenutzte Schwachstellen vorzuziehen.

Für Logikfehler ohne CVE-Bezug ersetzt der manuelle Erkenntnisgewinn aus einem API-Penetrationstest die fehlenden EPSS-Daten: Nur das tatsächliche Nachvollziehen des Angriffspfads zeigt, ob eine BOLA-Lücke über alle Objekte iterierbar ist oder ob ein Business Flow missbraucht werden kann. Der CVSS-Wert dokumentiert dann die technische Schwere; die Priorisierung folgt aus dem belegten Business-Impact. Diese Verbindung von messbarem Befund und nachvollziehbarer Bewertung ist auch der Kern von Warum API Security als eigenständige Disziplin: Generische Schweregrad-Werte allein bilden die spezifischen Risiken einer Schnittstelle nicht ab.

Quellen

• CVSS v4.0 Specification Document FIRST.Org, 2023
• CVSS v3.1 Specification Document FIRST.Org, 2019
• Vulnerability Metrics (CVSS) NIST National Vulnerability Database, 2024
• Exploit Prediction Scoring System (EPSS) FIRST.Org, 2024
• OWASP Risk Rating Methodology OWASP, 2023
• API1:2023 Broken Object Level Authorization - OWASP API Security Top 10 2023 OWASP, 2023