Ein Team verbringt den Sprint damit, eine Schwachstelle mit CVSS 9.8 zu beheben, die in einer Bibliothek versteckt ist, die im Produktivbetrieb nie aufgerufen wird. Gleichzeitig bleibt eine CVSS-6.5-Schwachstelle auf einem erreichbaren, mit dem Internet verbundenen Endpunkt einen weiteren Monat lang ungelöst, da sie es nie an die Spitze der Prioritätenliste geschafft hat. Dies ist kein hypothetisches Szenario, sondern das Standardergebnis einer Schwachstellenpriorisierung, die ausschließlich auf dem Schweregrad basiert – und ein häufigeres Versagen, als die meisten Sicherheitsprogramme zugeben wollen.
Was die Priorisierung von Schwachstellen eigentlich bewirken soll
Die Priorisierung von Schwachstellen ist der Prozess, bei dem entschieden wird, welche Schwachstellen zuerst behoben werden – aus einer Liste, die fast immer zu lang ist, um sie vollständig abzuarbeiten. Richtig angewendet, beantwortet sie eine präzisere und komplexere Frage als „Wie gravierend ist diese Schwachstelle theoretisch?“: Sie beantwortet die Frage „Wie stark reduziert die Behebung dieser Schwachstelle, jetzt, das Risiko für dieses spezifische System tatsächlich?“. Das sind nicht dieselben Fragen, und die Vermischung dieser Fragen ist der häufigste Fehler bei der Priorisierung von Schwachstellen.
Warum der Schweregrad-Score allein versagt
CVSS war nie als eigenständiges, vollständiges Priorisierungssystem konzipiert; es handelt sich um eine Schweregradbewertung, eine Beschreibung, wie gravierend eine Schwachstelle theoretisch in einem allgemeinen Kontext sein könnte. Es sagt nichts aus über:
- Erreichbarkeit. Ob der anfällige Codeabschnitt tatsächlich irgendwo in der Anwendung aufgerufen wird oder ob er in einer Abhängigkeit ungenutzt bleibt, die von nichts aufgerufen wird.
- Ausnutzbarkeit. Ob ein funktionierender Exploit in freier Wildbahn existiert oder ob die Schwachstelle außerhalb einer Laborumgebung nur theoretischer Natur ist.
- Exposition. Unabhängig davon, ob die betroffene Komponente mit dem Internet verbunden ist oder sich drei Schichten hinter einem internen Dienst ohne externen Zugriff befindet.
- Geschäftlicher Kontext. Ob es sich bei dem betroffenen System um ein System handelt, das Kundendaten oder Zahlungsabläufe verarbeitet, oder um ein internes Werkzeug von geringem Wert, auf das niemand angewiesen ist.
Ein Ansatz zur Priorisierung von Sicherheitslücken, der ausschließlich auf CVSS basiert, stuft eine Schwachstelle mit einem CVSS-Wert von 9.8 in unerreichbarem Code als dringlicher ein als eine Schwachstelle mit einem CVSS-Wert von 6.5 in erreichbarem, mit dem Internet verbundenem Pfad, die bereits ausgenutzt werden kann. Diese Rangfolge ist verkehrt und die direkte Folge davon, dass der Schweregrad bewertet wird, während alle anderen Faktoren, die das tatsächliche Risiko bestimmen, ignoriert werden.
Die versteckten Kosten einer falschen Priorisierung von Sicherheitslücken
Die Kosten beschränken sich nicht nur auf verschwendete Entwicklungsstunden, obwohl diese natürlich auch real sind: Teams verbringen regelmäßig Rechenzeit mit der Behebung kritischer Schwachstellen, die kein praktisches Risiko darstellen, während tatsächlich ausnutzbare Probleme ungelöst bleiben. Die subtileren Kosten sind das Vertrauen. Wenn Entwickler wiederholt von ihrer eigentlichen Arbeit abgezogen werden, um Schwachstellen zu beheben, die sich als unerreichbar erweisen oder bereits anderweitig behoben wurden, beginnen sie, auch die nächste Warnung zu ignorieren. Der eigentliche Sinn der Priorisierung von Schwachstellen – die Behebung der richtigen Probleme zuerst – wird dadurch stillschweigend untergraben, obwohl die Liste formal weiterhin abgearbeitet wird.
Was eine gute Priorisierung von Schwachstellen tatsächlich erfordert
Eine effektive Priorisierung von Schwachstellen kombiniert mehrere Signale mit dem Schweregrad, anstatt diesen vollständig zu ersetzen:
- Erreichbarkeitsanalyse. Prüfen Sie, ob die anfällige Funktion tatsächlich aus dem Anwendungscode aufgerufen wird und nicht nur in einem Abhängigkeitsbaum vorhanden ist.
- Verfügbarkeit ausnutzen. Prüfen Sie, ob ein öffentlicher Exploit oder eine aktive Kampagne auf die spezifische Schwachstelle abzielt, nicht nur auf die CVE-Familie.
- Deduplizierung über alle Scanner hinweg. Dasselbe zugrunde liegende Problem, das von drei verschiedenen Tools gemeldet wird, sollte nicht als drei separate Punkte gewertet werden, die um Aufmerksamkeit konkurrieren.
- Geschäftlicher und medienwirksamer Kontext. Die Ergebnisse sollten danach gewichtet werden, was das betroffene Asset tatsächlich berührt, und nicht nur nach dem generischen CVE-Score.
- Ein sichtbarer Trichter, keine flache Liste. Die Möglichkeit, zu sehen, wie viele Ergebnisse jeden Filter überstehen, von jedem einzelnen Problem bis hin zu dem, was tatsächlich ausnutzbar ist, macht die Priorisierung nachvollziehbar und nicht zu einer Blackbox.
Dieser letzte Punkt ist wichtiger, als es zunächst scheint. Eine einfache, nach Schweregrad sortierte Liste vermittelt dem Team kein Gefühl für den Umfang: Sind 40 % des Backlogs real oder nur 2 %? Eine Trichteransicht – alle Ergebnisse, dann die behebbaren, dann die erreichbaren, dann die mit bekannter Sicherheitslücke und schließlich die, die in dieser Umgebung tatsächlich ausnutzbar sind – verwandelt eine unüberschaubare Liste in eine kurze, übersichtliche und nachvollziehbare.
Worauf Sie bei Tools zur Priorisierung von Schwachstellen achten sollten
Nicht jede Plattform, die mit dem Versprechen der Schwachstellenpriorisierung wirbt, erfüllt tatsächlich die oben beschriebenen Anforderungen. Bei der Bewertung von Tools zur Schwachstellenpriorisierung lassen sich einige wenige Fragen schnell beantworten, um die Marketingversprechen zu durchschauen:
- Zeigt es die Erreichbarkeit an oder meldet es lediglich das Vorhandensein eines anfälligen Pakets?
- Werden doppelte Ergebnisse aus verschiedenen Scannern, einschließlich bereits verwendeter Drittanbieter-Tools, entfernt, oder fügt jede Quelle eine separate, unkorrelierte Liste hinzu?
- Kann ein Sicherheitsverantwortlicher den Ablauf des Auswahlprozesses einsehen, sehen, wie viele Ergebnisse herausgefiltert wurden und warum, oder erhält er nur die endgültige „priorisierte“ Liste ohne Einblick in die zugrunde liegende Logik?
- Berücksichtigt die Studie die Verfügbarkeit von Exploits aus realen Bedrohungsanalysen oder nur den statischen CVSS-Wert, der bei der Veröffentlichung angegeben wurde?
- Gilt die Priorisierung gleichermaßen für Ergebnisse von systemeigenen Scannern und von eingebundenen Drittanbieter-Tools oder nur für die Ergebnisse des jeweiligen Anbieters?
Die letzte Frage ist wichtiger, als es zunächst scheint. Viele Tools zur Priorisierung von Schwachstellen priorisieren nur die von ihnen selbst gefundenen Schwachstellen und vernachlässigen dabei alle anderen erfassten Daten. SAST, SCAoder Scanner von Drittanbietern, die sich in einem separaten, unsortierten Stapel befinden.
Wie Xygeni die Priorisierung von Schwachstellen angeht
Xygenis ASPM Es nutzt einen vierstufigen Prozess: Ergebnisse von nativen Scannern und Drittanbieter-Tools werden erfasst, eine einheitliche Übersicht über das resultierende Inventar erstellt und anschließend mithilfe von Deduplizierung, Erreichbarkeit und KI-gestütztem Kontext korreliert und priorisiert, bevor die Ergebnisse die Entwickler erreichen. In der Praxis reduziert dieser Prozess die vollständige Ergebnisliste auf behebbare, im Anwendungscode erreichbare, mit bekannten Sicherheitslücken versehene und schließlich in der jeweiligen Umgebung tatsächlich ausnutzbare Schwachstellen. So bleibt die Liste, mit der das Team tatsächlich arbeitet, klein genug, um vollständig abgearbeitet zu werden und nicht nur endlos priorisiert zu werden.
Da diese Priorisierungsebene für Schwachstellen sowohl für Ergebnisse von Scannern Dritter als auch für Xygenis eigene native ScannerEin Team muss nicht alles herausreißen ein vorhandenes Werkzeug Um eine einheitliche, korrelierte Sicht zu erhalten. Die Priorisierungslogik baut auf den bereits vorhandenen Daten auf und schließt die Lücke, die die meisten Tools zur Priorisierung von Schwachstellen hinterlassen, indem sie lediglich ihre eigenen Ergebnisse bewerten.
FAQ
Warum reicht CVSS allein nicht für die Priorisierung von Sicherheitslücken aus?
CVSS misst die theoretische Schwere, nicht das tatsächliche Risiko in einer konkreten Umgebung. Es berücksichtigt weder, ob der anfällige Code erreichbar ist, noch ob eine Sicherheitslücke bereits ausgenutzt wird oder wie exponiert das betroffene System ist. All diese Faktoren beeinflussen maßgeblich, ob eine gefundene Schwachstelle vorrangig behoben werden sollte.
Worin besteht der Unterschied zwischen Schweregrad und Ausnutzbarkeit bei der Priorisierung von Sicherheitslücken?
Der Schweregrad beschreibt, wie schädlich eine Schwachstelle theoretisch sein könnte. Die Ausnutzbarkeit beschreibt, ob dieser Schaden tatsächlich aktuell herbeigeführt werden kann, vorausgesetzt, es gibt einen funktionierenden Exploit und einen erreichbaren Codepfad. Eine Schwachstelle mit hohem Schweregrad und geringer Ausnutzbarkeit ist oft weniger dringlich als eine mit mittlerem Schweregrad und hoher Ausnutzbarkeit.
Müssen Tools zur Priorisierung von Schwachstellen auch die Ergebnisse von Scannern von Drittanbietern berücksichtigen?
Ja, andernfalls erhält das Team mehrere separate, unkorrelierte Prioritätenlisten, eine pro Tool, anstatt einer einheitlichen Sichtweise darauf, was im gesamten Stack tatsächlich am wichtigsten ist.
Wie stark kann eine Erreichbarkeitsanalyse die Liste der Ergebnisse realistischerweise reduzieren?
Das variiert je nach Codebasis, aber üblicherweise befinden sich die meisten gemeldeten Schwachstellen in Codepfaden, die nie tatsächlich aufgerufen werden. Das bedeutet, dass allein die Erreichbarkeit oft einen großen Teil der Befunde von einer ernsthaften Betrachtung ausschließt, bevor die Ausnutzbarkeit überhaupt beurteilt wird.
Ist eine kleinere, priorisierte Liste ein Zeichen dafür, dass Risiken ignoriert werden?
Nein, das Gegenteil ist der Fall. Eine kürzere Liste, die durch eine echte Priorisierung von Schwachstellen entsteht, bedeutet, dass irrelevante Informationen herausgefiltert wurden, nicht aber das eigentliche Risiko. Die Alternative, eine lange, ungefilterte Liste, die niemand vollständig durcharbeiten kann, führt zu schlechteren Ergebnissen, da das tatsächliche Risiko in der Fülle der Informationen untergeht.
