Dein Blog zum Thema digitales Business

Ein Schwachstellen-Scanner findet hunderte CVEs in einer durchschnittlichen Codebasis. Die meisten Teams kippen diese Liste in ein Ticket-System und arbeiten sie von oben nach unten ab. Das ist der falsche Weg. Vulnerability Management beginnt nicht mit dem Scan, sondern mit der Frage, welche der gefundenen Schwachstellen in eurem konkreten System überhaupt ausnutzbar sind.

Warum die CVSS-Zahl allein nicht reicht

Jeder CVE-Eintrag kommt mit einem CVSS-Score zwischen 0 und 10. Die Zahl beschreibt, wie gefährlich eine Schwachstelle theoretisch ist, wenn alle Bedingungen für einen Angriff erfüllt sind. Genau das ist das Problem. Ein CVSS-Score von 9,8 sagt nichts darüber, ob die betroffene Funktion in eurem Code aufgerufen wird, ob das Paket nur zur Build-Zeit existiert oder ob die verwundbare Komponente hinter einer Authentifizierung liegt. Wer rein nach CVSS sortiert, behandelt eine kritische Lücke in einer ungenutzten Transitiv-Abhängigkeit gleich wichtig wie eine in der zentralen Auth-Bibliothek.

Die Folge ist bekannt: Eine endlose Liste, abnehmende Motivation, und am Ende wird gar nichts geschlossen, weil die Menge erschlägt. Priorisierung heißt, die Liste auf das zu reduzieren, was in eurem Kontext zählt.

Drei Filter, die aus 300 CVEs 15 machen

Der erste Filter ist Erreichbarkeit. Wird der verwundbare Code-Pfad überhaupt ausgeführt? Reachability-Analyse in modernen SCA-Werkzeugen prüft, ob eine anfällige Funktion aus eurem Code heraus aufrufbar ist. Eine Schwachstelle in einer Methode, die ihr nie nutzt, ist real, aber nicht dringend.

Der zweite Filter ist aktive Ausnutzung. Der KEV-Katalog der US-Behörde CISA listet Schwachstellen, die nachweislich in freier Wildbahn angegriffen werden. Steht ein CVE auf dieser Liste, ist die theoretische Diskussion vorbei. Ergänzend liefert das EPSS-Modell eine Wahrscheinlichkeit, dass eine Schwachstelle in den nächsten 30 Tagen ausgenutzt wird. Beides verschiebt den Fokus von potenzieller auf tatsächliche Gefahr.

Der dritte Filter ist Exposition. Eine Lücke in einem Service, der offen im Internet hängt, ist anders zu bewerten als dieselbe Lücke in einem internen Batch-Job ohne Netzanbindung. Wer die Erreichbarkeit von außen mitdenkt, sortiert die Liste noch einmal deutlich.

Priorisierung als wiederkehrender Prozess

Ein einmaliger Scan ist eine Momentaufnahme. Neue CVEs werden täglich veröffentlicht, und eine gestern harmlose Abhängigkeit kann heute auf dem KEV-Katalog stehen. Vulnerability Management ist deshalb kein Projekt mit Enddatum, sondern ein Takt. Sinnvoll ist eine feste Frequenz: Scan im Pipeline-Lauf, automatische Anreicherung mit KEV- und EPSS-Daten, und eine kurze wöchentliche Sichtung der wirklich relevanten Treffer.

Wichtig ist, Service Level Agreements an die Priorität zu koppeln statt an den rohen CVSS-Score. Eine ausnutzbare, erreichbare Schwachstelle in einem exponierten Dienst bekommt eine Frist von wenigen Tagen. Eine theoretische Lücke in einer ungenutzten Abhängigkeit kann ins normale Backlog. So entsteht eine nachvollziehbare Linie zwischen Befund und Handlung, die auch ein Prüfer akzeptiert.

Dokumentation entscheidet über die Audit-Fähigkeit

Wer eine Schwachstelle bewusst nicht schließt, weil sie nicht erreichbar ist, muss diese Entscheidung festhalten. Sonst steht beim nächsten Audit die Frage im Raum, warum ein CVE mit Score 9,1 seit Monaten offen ist. Ein knapper Vermerk mit Begründung und Datum reicht. Diese Risk-Acceptance-Spur ist genauso Teil von Vulnerability Management wie das Schließen selbst. Sie verwandelt eine Bauchentscheidung in eine prüfbare Kontrolle.

Wenn ihr wissen wollt, wie ausnutzbar die Schwachstellen in eurer Pipeline wirklich sind und wo die echten Prioritäten liegen, lohnt ein externer Blick. Der GitSecOps QuickCheck prüft eure CI/CD-Pipeline und Abhängigkeiten in drei Werktagen und liefert eine priorisierte Befundliste statt einer rohen CVE-Wand. Festpreis 1.990 Euro netto. Kontakt: mm@crank.zone.