Schluss mit der CVSS-Jagd: Warum Vulnerability-Backlogs nicht kleiner werden (und was wirklich hilft)

Das eigentliche Problem: Wir verwechseln „Severity“ mit „Risk“

CVSS (und viele Tool-Scores) beschreiben die technische Schwere einer Schwachstelle in einer generischen Umgebung. Nützlich – aber nicht dasselbe wie Risiko.

Risiko ist immer kontextabhängig:

• Impact: Was bedeutet eine Ausnutzung für unser Geschäft?
• Likelihood: Ist eine Ausnutzung in unserer Umgebung überhaupt realistisch?

Ohne diese beiden Faktoren wird „Top 10 CVEs“ zur Endlosschleife.

Warum „hoch“ nicht automatisch „priorisiert“ heißt

In der Praxis sieht man fast immer zwei Muster:

1. Hohe Severity heißt nicht automatisch hohes Risiko

Eine Schwachstelle kann auf dem Papier kritisch sein, aber in eurem Setup schwer auszunutzen. ‍

2.Niedrigere Severity kann trotzdem hohes Risiko bedeuten

Ein „Medium“ kann auf einem besonders sensiblen Asset liegen – oder in eurer Umgebung sehr leicht auszunutzen sein.

Das Ergebnis kennt jeder: viel Patch-Aktivität, aber begrenzte Risikoreduktion.

‍

Ein einfacher Fix: Von Tool-Scoring zu kontextuellem Scoring

Ein pragmatischer Ansatz ist, explizit zu kombinieren:

• Severity (was das Tool liefert),
• Impact (wie wichtig das Asset für euer Business ist),
• Likelihood (wie realistisch eine Ausnutzung in eurer Umgebung ist).

Ob ihr das als simples 1–5-Modell oder als Workflow umsetzt: Die Grundidee ist immer gleich:

Priorisiert Schwachstellen dort, wo technische Schwere auf Business-Relevanz trifft.

‍

Was „Kontext“ in der Praxis bedeutet

Kontext muss nicht kompliziert sein. Startet klein:

• Führt eine leichte Asset-Impact-Klassifikation ein (z. B. Führung/HR/Admin vs Standard-Endgeräte)
• Bewertet Likelihood anhand eurer Rahmenbedingungen (Exposure, Authentifizierung, Hardening, Segmentierung)
• Erzwingt eine kurze Begründung: „Warum ist das für uns dringend?“

Allein das verschiebt Vulnerability Management von „alles fixen“ zu „das Richtige fixen“.

‍

Warum das wichtig ist

Kontextuelles Scoring ersetzt eure Tools nicht – es macht sie handlungsfähig.

Es hilft euch:

• Aufwand dort zu investieren, wo er den größten Effekt hat,
• Prioritäten nachvollziehbar zu erklären,
• und keine Energie auf Themen zu verschwenden, die in eurer Realität kaum zu einem Incident führen.

Wenn ihr in Findings untergeht, braucht ihr nicht mehr Alerts – sondern bessere Priorisierung.

‍

Takeaway

Wenn Ihr Schwachstellen-Backlog immer weiter wächst, liegt das Problem meist nicht an der Anzahl der Findings – sondern an der Art der Priorisierung. CVSS und Tool-Scores zeigen die technische Schwere einer Schwachstelle, aber nicht, was für Ihr Unternehmen tatsächlich riskant ist.

Erst durch Kontext – also den geschäftlichen Impact eines Systems und die tatsächliche Ausnutzbarkeit in Ihrer Umgebung – wird aus einer Liste von Findings eine sinnvolle Priorisierung. Ziel ist nicht, alles sofort zu patchen, sondern die Schwachstellen zuerst zu beheben, die Ihr Unternehmen real am stärksten gefährden.