Schwachstellen-Triage: CVSS allein steuert falsch

Operative Teams priorisieren oft nach Score und Ticket-Alter statt nach erreichbarer Angriffsfläche. Für DACH-Umgebungen zählt die Einordnung nach Exposition, Asset-Kritikalität und realer Exploit-Nähe. CVSS bleibt dabei nützlich. Allein steuert der Score die Ticket-Queue jedoch in die falsche Reihenfolge.

Verwandt: CTEM: Warum Continuous Threat Exposure Management den Vulnerability Scan ablöst  ·  Patch-Priorisierung: Warum CVSS allein dein SOC bremst

Was CVSS misst und was er bewusst auslässt

CVSS (Common Vulnerability Scoring System) bewertet die technische Schwere einer Schwachstelle. Die Metriken erfassen unter anderem Angriffsvektor, Komplexität, benötigte Privilegien, Nutzerinteraktion und Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. Laut der CVSS-v4.0-Spezifikation von FIRST (Forum of Incident Response and Security Teams) gliedert sich das Framework in die Metrikgruppen Base, Threat, Environmental und Supplemental. Der Base Score spiegelt die intrinsischen Eigenschaften einer Schwachstelle wider, die über Zeit und Einsatzumgebung konstant bleiben. Threat- und Environmental-Metriken passen die Bewertung an aktuelle Ausnutzung und den konkreten Betriebskontext an. So entsteht eine vergleichbare Basis für die technische Einordnung über Produkte und Umgebungen hinweg.

Was der Base Score bewusst auslässt, ist der Betriebskontext. Er kennt weder das konkrete Asset im Netz noch die Datenklasse noch die Frage, ob die betroffene Komponente aus dem Internet erreichbar ist. Auch aktive Ausnutzung, Exploit-Reife und unternehmensspezifische Kompensationen gehören nicht in den Base Score. Die US-amerikanische National Vulnerability Database (NVD) stellt das klar: „CVSS is not a measure of risk.“ Die NVD liefert zu CVE-Einträgen in der Regel nur Base-Metriken. Threat-, Environmental- und Supplemental-Werte müssen Organisationen selbst setzen. Der FIRST User Guide zu CVSS v4.0 betont denselben Punkt: Der Base Score misst Schwere statt Risiko und eignet sich allein nicht für die Risikobewertung.

Wer denselben CVSS-Wert auf ein isoliertes Testsystem und auf einen internet-facing Identity-Broker anwendet, erhält denselben Startpunkt und zwei völlig verschiedene Risiken. Genau hier entsteht die Fehlsteuerung in vielen Vulnerability-Management-Queues.

Drei zusätzliche Prioritätsachsen für den Betrieb

Für die operative Triage braucht es neben dem Score drei Achsen, die sich in Ticket-Feldern und SLA-Regeln abbilden lassen: Exposition, Exploit-Nähe und Asset-Kritikalität. Exposition beschreibt, wie leicht ein Angreifer die Schwachstelle erreichen kann. Exploit-Nähe beschreibt, wie nah die technische Ausnutzbarkeit an der eigenen Landschaft liegt. Asset-Kritikalität beschreibt, was bei Kompromittierung fachlich und regulatorisch auf dem Spiel steht.

Exposition ist die erste Filterfrage im Alltag. Eine Schwachstelle in einem öffentlich erreichbaren Dienst steht vor einer gleich bewerteten Schwachstelle in einem strikt segmentierten Backend. Auch interne Exposition zählt, wenn laterale Bewegung über Admin-Pfade oder Management-Interfaces möglich ist. Die Frage lautet nicht nur „hoch oder niedrig“. Entscheidend ist: von wo und mit welchem Vorwissen erreichbar.

Exploit-Nähe trennt theoretische Schwere von aktueller Bedrohung. Hinweise aus Advisories, öffentliche Exploit-Codes, aktive Kampagnen und die Passung zum eigenen Stack verändern die Dringlichkeit. Das BSI fordert im NIS-2-Infopaket zu Sicherheitsmaßnahmen und Schwachstellenmanagement die priorisierte Behandlung sicherheitskritischer Schwachstellen und die Priorisierung nach Risiko und Einfluss auf Geschäftsprozesse. Die US-Cyberbehörde CISA ergänzt diesen Ansatz mit dem Known Exploited Vulnerabilities Catalog (KEV): Organisationen sollen Schwachstellen mit nachgewiesener aktiver Ausnutzung vorrangig schließen. Ohne diese Achse rutschen lautstarke, aber schwer erreichbare Findings vor stille, aber greifbare Angriffspfade.

Asset-Kritikalität verhindert, dass die Queue nach reiner Ticketdichte sortiert. Ein CVSS-hoher Befund auf einem reinen Demo-Host hat eine andere Behandlungsfrist als ein mittlerer Befund auf dem System, das Authentifizierung, Zahlungsdaten oder Produktionssteuerung trägt. Kritikalität muss vor dem Scan-Lauf gepflegt sein. Sonst bleibt sie ein Nachgedanke im Incident.

Asset-Kontext: Internet-facing, Privilegien, Datenklasse

Drei Kontextmerkmale reichen für die erste operative Schärfung: Internet-facing ja/nein, benötigte und erreichbare Privilegien sowie Datenklasse des Assets. Internet-facing markiert Systeme, die ohne VPN oder Zero-Trust-Zugang ansprechbar sind. Privilegien klären, ob die Schwachstelle unauthentifiziert greift, ob sie Rechteausweitung ermöglicht und ob die betroffene Identität weitreichende Admin- oder Service-Rechte besitzt. Die Datenklasse ordnet ein, ob öffentliche Inhalte, interne Geschäftsdaten oder schutzbedürftige personenbezogene bzw. operative Daten betroffen sind.

Diese Merkmale gehören in die CMDB (Configuration Management Database) bzw. ins Asset-Inventory und von dort in jedes Vulnerability-Ticket. Fehlen sie, priorisiert das Team notgedrungen nach Score und Alter. Mit ihnen entsteht eine nachvollziehbare Matrix: hohe Exposition plus hohe Privilegienwirkung plus hohe Datenklasse ergibt die Vorderreihe – unabhängig vom reinen Marketing des CVE-Titels.

Ein Praxisbeispiel macht den Unterschied greifbar. Im November 2024 veröffentlichte Palo Alto Networks das Advisory zu CVE-2024-0012 (PAN-SA-2024-0015): ein Authentifizierungs-Bypass in der Management-Weboberfläche von PAN-OS. Der CVSS-v4-Vektor nennt Attack Vector Network, Privileges Required None und User Interaction None; Exploit Maturity steht auf Attacked, der CVSS-BT-Score liegt bei 9.3 (Critical). CISA nahm die CVE am 18. November 2024 in den KEV-Katalog auf. Das Advisory selbst stellt klar: Das Risiko sinkt stark, wenn der Zugang zur Management-Oberfläche auf vertrauenswürdige interne Adressen beschränkt bleibt. Liegt dieselbe Komponente bei einem Unternehmen nur hinter MFA-geschütztem Admin-Zugang und strenger Segmentierung, sinkt die Sofortpriorität. Liegt sie internet-facing vor dem IdP-Pfad, gehört der Fall in die nächste Wartungs- und Kommunikationsrunde – auch wenn andere Tickets älter sind.

Patch- vs. Kompensationspfad dokumentieren

Nicht jeder kritische Befund endet am selben Tag im Patch. Change-Fenster, Vendor-Abhängigkeiten, Zertifizierungsauflagen und Nebenwirkungen in Fachanwendungen erzwingen mitunter einen Kompensationspfad. Operativ brauchbar ist die Entscheidung erst, wenn Patch- und Kompensationsoptionen gleichwertig dokumentiert werden: was wird getan, bis wann, wer freigibt und welche Restexposition bleibt.

Der Patch-Pfad beschreibt Version, Zieltermin, Rollback und Verifikation. Der Kompensationspfad beschreibt Kontrollen wie Netzrestriktion, WAF-Regel, Deaktivieren einer Funktion, härtere Authentifizierung oder Monitoring auf Exploit-Indikatoren. Beide Pfade brauchen ein Ablaufdatum. Kompensation ohne Enddatum wird zur stillen Dauerlösung und verfälscht das Risikobild gegenüber dem CISO.

Für die Queue-Logik folgt daraus eine einfache Regel: Priorität steuert den Start der Behandlung, nicht zwingend den sofortigen Produktiv-Patch. Ein hoch priorisiertes Ticket darf in Kompensation gehen, wenn die Exposition damit nachweislich sinkt und der Patch-Termin verbindlich nachgezogen wird. Ein niedrig priorisiertes Ticket darf warten, wenn Exposition und Kritikalität das erlauben. So bleibt die Ersatzlogik operationalisierbar und verhindert den reinen Score-Stau.

Reporting an CISO: Risiko statt Ticketstau

CISO-Reporting, das nur offene Tickets und Durchschnitts-CVSS zeigt, misst Aktivität und nicht Risiko. Brauchbarer ist eine Sicht nach Expositionsklassen, offenen internet-facing Findings mit hoher Exploit-Nähe und Assets mit kritischer Datenklasse ohne wirksame Kompensation. Ticketalter bleibt ein Prozessindikator. Es ersetzt aber nicht die Frage, welche Angriffsfläche real offen ist.

Ein knappes Risikobild beantwortet drei Leitfragen: Welche erreichbaren Schwachstellen betreffen kritische Assets? Wo greifen Kompensationen und wo sind sie überfällig? Welche Entscheidungen brauchen Change-Kapazität in den nächsten Zyklen? Damit steuert das Management Kapazität und Risikoakzeptanz, statt eine wachsende Backlog-Zahl zu kommentieren.

Die Konsequenz für den Betrieb ist klar: CVSS bleibt der technische Startwert. Die Queue steuert über Exposition, Exploit-Nähe und Asset-Kritikalität. Wer diese Achsen in Ticketfeldern, SLAs und CISO-Reports verankert, priorisiert nach erreichbarer Angriffsfläche und nicht nach der Lautstärke des Scores.

Häufige Fragen

Wie verankert man Exposition, Exploit-Nähe und Asset-Kritikalität in bestehenden Ticket-Systemen?

Die drei Achsen werden als Pflichtfelder im Vulnerability-Ticket modelliert und aus CMDB bzw. Asset-Inventory befüllt. SLA-Regeln greifen auf Expositionsklasse, Datenklasse und Exploit-Nähe zu und setzen Fristen danach. Fehlen die Merkmale im Inventory, muss die Pflege vor dem Scan-Lauf nachgezogen werden. Sonst priorisiert das Team notgedrungen nach Score und Ticketalter.

Wann darf ein hoch priorisiertes Finding in den Kompensationspfad statt in den Sofort-Patch?

Wenn Change-Fenster, Vendor-Abhängigkeiten oder Zertifizierungsauflagen den Produktiv-Patch verzögern, dokumentiert das Team Kontrollen wie Netzrestriktion, WAF-Regel, Funktionsdeaktivierung oder härtere Authentifizierung. Verbindlich sind Zieltermin, Freigabe und verbleibende Restexposition. Priorität steuert den Start der Behandlung; Kompensation senkt die Exposition nachweislich und zieht den Patch-Termin nach. Ohne Ablaufdatum wird die Maßnahme zur stillen Dauerlösung.

Wie fließen CISA-KEV und BSI-Vorgaben in die Exploit-Nähe ein?

Exploit-Nähe trennt theoretische Schwere von greifbarer Bedrohung. CISA verlangt über den Known Exploited Vulnerabilities Catalog die vorrangige Schließung aktiv ausgenutzter Schwachstellen. Das BSI fordert im NIS-2-Infopaket die priorisierte Behandlung sicherheitskritischer Findings nach Risiko und Einfluss auf Geschäftsprozesse. Advisories, öffentlicher Exploit-Code, aktive Kampagnen und die Passung zum eigenen Stack ergänzen dieselbe Achse.

Warum genügt Ticketalter als zentrale Größe im CISO-Report nicht?

Ticketalter bleibt ein Prozessindikator für Durchlauf und Backlog-Druck und lässt die real offene Angriffsfläche unbewertet. Brauchbare Reports gliedern nach Expositionsklassen, internet-facing Findings mit hoher Exploit-Nähe und kritischen Assets ohne wirksame Kompensation. Das Management steuert Kapazität und Risikoakzeptanz über drei Leitfragen: erreichbare Schwachstellen auf kritischen Assets, greifende oder überfällige Kompensationen und benötigte Change-Kapazität in den nächsten Zyklen.

Lesetipps der Redaktion

LesetippCTEM: Warum Continuous Threat Exposure Management den Vulnerability Scan ablöstLesetippPatch-Priorisierung: Warum CVSS allein dein SOC bremstLesetippWarum das ISO-Zertifikat dem BSI allein nicht reicht

Mehr aus dem MBF Media Netzwerk

Digital ChiefsGeopolitik trifft die Datacenter-Roadmap: Was CIOs jetzt absichernMyBusinessFutureEU AI Act: Was der Mittelstand kennzeichnen musscloudmagazinXFS4IoT trifft Cloud: Der Geldautomat wird Plattform

Bildquelle: KI-generiert (Juli 2026)