Warum CVSS nicht genug ist

Ein Score von 9,8 sagt Ihnen, wie schlimm eine Schwachstelle im Labor ist. Er sagt Ihnen nicht, ob Ihr Produkt betroffen ist, ob jemand sie ausnutzt – und was Sie am Montagmorgen zuerst tun sollten.

Vierzig kritische Funde sind keine Tagesordnung

Der Ablauf ist in fast jedem Produktteam derselbe. Das Release steht in zwei Wochen, der Scanner läuft über die Stückliste, und am nächsten Morgen liegt eine Liste auf dem Tisch: 312 Funde, davon 40 „kritisch“. Dann stellt jemand aus dem Produktmanagement die einzige Frage, die zählt:

Was davon müssen wir vor dem Release beheben?

An dieser Stelle hilft die Spalte, nach der alle sortiert haben, kein Stück weiter. Vierzig Zeilen, die alle „kritisch“ heißen, sind keine Tagesordnung – sie sind vierzig Mal dieselbe Auskunft. Die Sortierung nach CVSS beantwortet die Frage wie schlimm wäre es, gefragt war aber was tun wir zuerst. Das sind zwei verschiedene Fragen, und die zweite ist die teurere.

Der übliche Ausweg ist eine Schwelle: „alles ab 7,0 wird behoben“. Das ist keine Priorisierung, sondern eine Verlagerung. Sie erzeugt Arbeit an Funden, die das Produkt nie erreichen, und lässt eine 5,9 liegen, für die es seit Wochen fertigen Exploit-Code gibt.

Was CVSS ist – und was es nie sein wollte

Das Missverständnis fängt nicht bei CVSS an, sondern bei seiner Verwendung. Das Common Vulnerability Scoring System der FIRST-Organisation besteht aus drei Metrikgruppen:

Was in den Datenbanken steht, was Scanner ausgeben und was in jedem Report auftaucht, ist die Basisgruppe. Die ist ausdrücklich so konstruiert, dass sie unabhängig von jeder konkreten Installation gilt – Zeit und Kontext sind bewusst herausgerechnet. Der Standard selbst hält fest, dass ein Basiswert die Schwere beschreibt und nicht das Risiko.

Wer nach Basis-Score priorisiert, benutzt also genau die eine Metrik, aus der alles entfernt wurde, was seine Entscheidung tragen könnte. Nicht, weil CVSS schlecht wäre – sondern weil es für diese Frage nie gebaut war.

Fairerweise

Was CVSS gut kann. Es macht Schweregrade zwischen Anbietern vergleichbar, es ist prüfbar zerlegbar – der Vektor sagt, wie der Wert zustande kam –, und es ist die gemeinsame Sprache, in der die halbe Branche spricht. Nichts davon soll ersetzt werden. Es muss nur aufhören, allein zu stehen.

Fünf blinde Flecken

Ein erheblicher Teil der Funde betrifft Code, der im ausgelieferten Produkt gar nicht landet: Testabhängigkeiten, ungenutzte Module, wegoptimierte Pfade, eine Bibliothek, die nur der Build braucht. Der Score dieser Funde ist trotzdem 9,8. Sie kosten trotzdem jeweils eine Bewertung von Hand.

Die Antwort darauf heißt VEX (Vulnerability Exploitability eXchange): eine formale, maschinenlesbare Aussage darüber, ob ein Produkt betroffen ist – mit einer der standardisierten Begründungen, etwa „verwundbarer Code nicht vorhanden“ oder „verwundbarer Code nicht im Ausführungspfad“. Der Unterschied zum Wegklicken ist der Beleg: Ein weggedrückter Fund ist eine Behauptung; eine VEX-Aussage mit Begründung und Nachweis hält einer Prüfung stand.

Jede Prüfung ohne dieses Wissen meldet die Komponente als verwundbar – mit Score, mit rotem Balken, mit Ticket. Auf einem gepflegten System sind das nicht ein paar Fälle: In einer Erprobung an einer realen Paketliste hat Curator Pro 601 (Komponente, CVE)-Paare als nachweislich behoben erkannt, die eine generische Prüfung gemeldet hätte.

Hunderte Falschmeldungen sind der häufigste Grund, warum ein Werkzeug wieder abgeschaltet wird. Und der Fehler ist nicht symmetrisch: Wer die Distributions-Sicht ignoriert, produziert nicht nur Lärm, er verliert auch echte Funde. Sicherheitsangaben werden zum Quellpaket veröffentlicht, installiert sind aber Binärpakete – im Tracker steht openssl, auf dem Gerät liegt libssl3; dort steht glibc, hier liegen libc6 und libc-bin. Wer diese Übersetzung ausließe, fände ausgerechnet für die häufigsten Systembibliotheken nichts und meldete still „sauber“.

• EPSS (Exploit Prediction Scoring System) schätzt täglich die Wahrscheinlichkeit, dass eine Schwachstelle in den nächsten 30 Tagen ausgenutzt wird. Nur ein kleiner Teil aller je veröffentlichten CVEs wird jemals tatsächlich angegriffen.
• Der KEV-Katalog der US-Behörde CISA listet Schwachstellen, für die Ausnutzung beobachtet wurde.

Der Unterschied zwischen beiden ist keine Feinheit, sondern das Fundament jeder belastbaren Reihenfolge: EPSS ist eine Prognose, KEV eine Beobachtung. Ein KEV-Eintrag muss deshalb schwerer wiegen als der höchstmögliche EPSS-Wert – sonst schlägt eine Vorhersage einen Beleg. Umgekehrt gilt genauso: Eine 6,1 mit KEV-Eintrag gehört vor eine 9,8, die seit drei Jahren niemand angefasst hat.

Genau dafür gäbe es die umgebungsbezogenen Metriken – nur werden sie in der Praxis nie gepflegt, weil sie pro Fund erfasst werden müssten, obwohl die Antwort pro Produkt immer dieselbe ist. Der Ausweg ist, die Frage dorthin zu stellen, wo sie hingehört: Wie kritisch ein Ausfall für den Auftrag des Betreibers und für Menschen ist, ist eine Eigenschaft des Produkts. Einmal gepflegt, geht sie in jede Entscheidung ein – statt tausendfach geraten zu werden.

Die dritte Frist hängt in beiden Fällen an einem anderen Anker als an der Kenntnisnahme – und dieser Anker existiert zu Beginn noch gar nicht. Eine Tabelle mit CVSS-Werten kann diesen Unterschied nicht abbilden. Sie sagt Ihnen nicht einmal, welcher Ihrer Funde überhaupt auf einem ausgelieferten Release sitzt und damit meldefähig ist.

Der blindeste Fleck: „keine Funde“ heißt nicht „geprüft“

Ein leerer Bericht ist die angenehmste Auskunft eines Werkzeugs – und die gefährlichste. Denn er hat zwei völlig verschiedene Bedeutungen:

1. Alle Komponenten wurden abgefragt, keine ist betroffen.
2. Für die Hälfte der Komponenten hatte das Werkzeug nie einen Schlüssel, mit dem es überhaupt hätte fragen können.

Kein CVSS-Wert der Welt macht diesen Unterschied sichtbar, weil es im zweiten Fall schlicht keinen Wert gibt. Deshalb misst Curator Pro den Abdeckungsgrad als eigene Zahl: den Anteil der Komponenten, die von den eingeschalteten Quellen überhaupt abgefragt werden können – aufgeschlüsselt in abfragbar, Quelle abgeschaltet und kein Schlüssel vorhanden, samt dem Zugewinn, den das Einschalten einer weiteren Quelle brächte.

Eine Sicherheitsaussage, die ihre eigene Lücke nicht kennt, ist keine Sicherheitsaussage.

Was an die Stelle tritt – nicht statt CVSS, sondern um CVSS herum

Die Antwort ist kein besserer Score, sondern die Trennung der Fragen:

SSVC (Stakeholder-Specific Vulnerability Categorization, entwickelt vom CERT/CC) ist dabei der Bruch mit dem Score-Denken: Statt einer Zahl liefert es eine Handlung. Vier Fragen – Wird sie ausgenutzt? Ist der Angriff automatisierbar? Wie groß ist die technische Wirkung? Wie kritisch ist das Produkt für Auftrag und Menschen? – und vier mögliche Ergebnisse: Track (beobachten), Track* (erhöhte Aufmerksamkeit), Attend (zeitnah bearbeiten), Act (sofort handeln).

Das lässt sich in ein Sprint-Planning tragen. „9,8“ nicht.

Wie Curator Pro das umsetzt

Curator Pro ist eine Plattform für Software Composition Analysis und CRA-Konformität. Für den Punkt dieses Beitrags sind acht Bausteine relevant – alle sichtbar an derselben Oberfläche, an der auch die Funde stehen.

Der Handlungsrang (0–100)

steht neben dem CVSS-Wert, nicht an seiner Stelle. Er verrechnet, was ohnehin am Fund hängt: Schweregrad, EPSS, KEV-Eintrag, die ENISA-Kennzeichnung „aktiv ausgenutzt“, die Erreichbarkeit des verwundbaren Codes, eine vorhandene SSVC-Entscheidung und den VEX-Status. Ein Klick zeigt die vollständige Herleitung – jeder Beitrag mit Punktwert und Grund, darunter die Summe. Eine Blackbox-Zahl wäre in einem Compliance-Produkt wertlos: Der erste Widerspruch („warum steht das über jenem?“) kippt sonst das Vertrauen, und danach sortiert wieder jeder von Hand. Die Gewichte sind eine Einstellung, kein Betriebsgeheimnis.

Der SSVC-Entscheidungsbaum

ist geführt, und das Ergebnis steht live da, sobald alle vier Achsen gesetzt sind – nicht erst nach dem Speichern. Wer sieht, wie eine Antwort das Ergebnis verschiebt, versteht den Baum. Vorbelegt wird nur, was belegt ist: Steht die Schwachstelle im KEV-Katalog, setzt Curator Pro die erste Achse auf aktiv ausgenutzt und nennt den Beleg. Den Wert keine Belege setzt es nie von selbst – dass etwas nicht ausgenutzt wird, lässt sich nicht messen. Gespeichert wird die Entscheidung mit ihrem Vektor (SSVCv2/E:A/A:Y/T:T/M:H/D:Act/), denn genau danach fragt ein Auditor.

Der Dateibestands-Nachweis

beantwortet ohne jede Codeanalyse, ob der verwundbare Code überhaupt ausgeliefert wird. Nennt ein Advisory die betroffene Quelldatei und liegt diese Datei nicht im bekannten Dateibestand der Komponente, entsteht ein belegter Vorschlag „nicht betroffen / verwundbarer Code nicht vorhanden“ – mit der Dateiliste als Nachweis. Und wenn die Prüfung nicht entscheiden kann, sagt sie warum, in vier unterscheidbaren Gründen. Ein Kasten, der einfach schweigt, ließe „nicht geprüft“ wie „geprüft und sauber“ aussehen.

Distributions-Advisories

lesen die Buchführung des Paketverwalters direkt aus dem hochgeladenen Archiv (/var/lib/dpkg/status, /lib/apk/db/installed, /etc/os-release), übersetzen Binär- in Quellpakete und beurteilen die zurückportierte Revision. Ohne bekanntes Release wird die Komponente als nicht beurteilbar ausgewiesen – nicht stillschweigend freigesprochen.

Der Sanierungsplan

rechnet vor, was sonst niemand rechnet: je Komponente die kleinste Zielversion, die alle ihre Funde schließt. Mit dem Änderungsrisiko (Patch / Minor / Major), den Zwischenstufen, den erledigten Risikopunkten pro Aufwandseinheit – und, als wichtigster Zahl der Zeile, wie viele Funde danach offen bleiben. Ein Plan, der „Update auf 2.4.1“ sagt und das verschweigt, wäre schlimmer als kein Plan: Das Team hielte die Komponente danach für erledigt.

Die befristete Risikoakzeptanz

bildet den häufigsten realen Zustand eines Fundes ab – weder „nicht betroffen“ noch „behoben“, sondern „betroffen, wird in 4.2 behoben, bis dahin tragen wir das.“ Mit Pflichtfeldern (Begründung und Ausgleichsmaßnahme), Ablaufdatum und Vier-Augen-Genehmigung. Eine Akzeptanz ohne Begründung wäre eine Unterdrückung; eine ohne Ausgleichsmaßnahme beantwortet nicht die Frage, die jede Prüfung als Nächstes stellt.

Die Meldeuhr

führt beide CRA-Tatbestände mit ihren jeweils eigenen Ankern. Der Zeitpunkt der Kenntnisnahme wird ausdrücklich erfasst, nicht aus dem Anlegen des Vorgangs abgeleitet – er liegt fast immer davor, und die Differenz ist genau das, was eine Aufsicht interessiert. Eröffnet wird von Hand: Der Klick startet eine Rechtsfrist, und ein Werkzeug, das die 24-Stunden-Uhr selbsttätig startet, erzeugt entweder Fehlalarme mit Behördenkontakt oder eine Uhr, die niemand bemerkt hat.

Sicherheits-Kennzahlen

schließen den Kreis: Wie lange liegt ein Fund unbewertet? Halten wir unsere eigene Frist? Arbeiten wir den Rückstand ab oder verwalten wir ihn nur? Wo eine Kennzahl nicht ermittelt werden konnte, steht ein Strich und darunter der Grund – nicht eine beruhigende Null.

Drei Grundsätze, die das Ganze tragen

01 Beleg schlägt Vorhersage.

Eine Beobachtung wiegt schwerer als jede Prognose. Deshalb geht EPSS in die Rangfolge ein, aber nicht in den SSVC-Baum – es auf „Exploit-Code öffentlich“ abzubilden verwechselte Vorhersage mit Beobachtung.

02 Unbekannt gibt nie Punkte.

Ein Signal, das nie erhoben wurde, wirkt weder erhöhend noch senkend. Ein fehlender Wert darf nicht als 0 gelten – sonst wird aus „nie geprüft“ stillschweigend „unbedenklich“.

03 Ein Vorschlag ist keine Entscheidung.

Erreichbarkeitsanalysen, Wissensbasis-Übernahmen und automatische VEX-Vorschläge schlagen vor; übernommen wird per Klick von einem Menschen, und diese Übernahme ist die dokumentierte Kurationsentscheidung. Regulatorische Evidenz, die eine Maschine allein erzeugt hat, trägt vor einer Prüfung nicht.

Fazit

CVSS ist eine gute Antwort auf eine Frage, die Sie nicht gestellt haben.

Die Frage lautet nicht „wie schlimm ist diese Lücke?“, sondern: Betrifft sie unser Produkt – wird sie ausgenutzt – was tun wir zuerst – und bis wann müssen wir es getan haben? Vier Fragen, vier verschiedene Instrumente. Ein einzelner Score kann keine davon beantworten, und er wurde nie dafür entworfen.

Der Unterschied zwischen einem Werkzeug, das Funde anzeigt, und einem, das Funde entscheidbar macht, ist am Ende genau dieser: ob neben der Zahl steht, woher sie kommt, was sie nicht weiß – und was Sie damit tun sollen.