Schwachstellen priorisieren: So entscheiden Sie, was Sie zuerst beheben

Warum der Schweregrad allein nicht funktioniert

Standardmäßig wird nach CVSS sortiert und von kritisch abwärts gearbeitet. Das wirkt objektiv und scheitert aus drei Gründen:

• CVSS misst den Schweregrad, nicht das Risiko. Es beschreibt, wie schlimm eine Schwachstelle wäre, wenn sie ausgenutzt würde. Es sagt nicht, ob jemand sie ausnutzt oder ob sie in Ihrem Produkt eine Rolle spielt.
• Zu viel auf der Liste ist dringend. Viele veröffentlichte CVEs werden als hoch oder kritisch bewertet, daher stehen in einer nach CVSS sortierten Warteschlange Hunderte Befunde ganz oben, ohne dass sich zwischen ihnen wählen lässt.
• Die Liste ist nur so gut wie das Inventar. Ein Scanner, der ein Lockfile liest, meldet Entwicklungsabhängigkeiten, die nie ausgeliefert werden, und übersieht Pakete, die der Build außerhalb des Paketmanagers geladen hat. Beides verzerrt die Rangfolge, bevor sie überhaupt entsteht.

Die Priorisierung ergänzt die fehlenden Fragen: Wird sie ausgenutzt, wie wahrscheinlich ist das, und was passiert bei Ihnen, wenn es so ist?

Die Signale

Signal	Welche Frage es beantwortet	Quelle
CVSS	Wie schwer wiegt sie, wenn sie ausgenutzt wird? Wert von 0 bis 10.	FIRST (der Standard); NVD und Anbieter veröffentlichen Werte
EPSS	Wie wahrscheinlich ist eine Ausnutzung in den nächsten 30 Tagen? Eine Wahrscheinlichkeit von 0 bis 1.	FIRST, täglich aktualisiert, kostenlos
CISA KEV	Wird sie bereits in freier Wildbahn ausgenutzt?	Known-Exploited-Vulnerabilities-Katalog von CISA
SSVC	Was sollten Sie angesichts von Ausnutzung, Auswirkung und Ihrem Auftrag tun: Track, Attend oder Act?	Entscheidungsbäume von CERT/CC und CISA
Ihr Kontext	Wird die verwundbare Version ausgeliefert? Ist sie exponiert? Wie wichtig ist das Produkt? Gibt es einen Fix?	Ihr Inventar, Ihre Architektur und Ihre Asset-Daten

Die öffentlichen Signale beschreiben die Schwachstelle. Nur Ihr Kontext beschreibt Ihr Risiko, und diesen Teil beziehen die meisten Teams aus der unzuverlässigsten Quelle.

Eine praktische Methode zur Priorisierung

Die meisten Programme landen bei einer Variante dieser Stufen. Legen Sie die Fristen nach dem fest, was Ihre Policy und Ihre Kunden verlangen.

1. Sofort beheben: bekannt ausgenutzt, in Software, die Sie ausliefern. Alles auf der KEV-Liste oder mit anderen Belegen für eine Ausnutzung, das in einem veröffentlichten Build vorhanden ist. Zum Vergleich: CISAs BOD 26-04 gibt US-Bundesbehörden für einen KEV-Eintrag auf einem öffentlich exponierten System mitunter nur 3 Tage.
2. Als Nächstes beheben: wahrscheinlich ausgenutzt und schwerwiegend. Ein hoher EPSS-Wert in Verbindung mit hohem oder kritischem CVSS, in einer ausgelieferten und exponierten Komponente. Wählen Sie einen EPSS-Schwellenwert, der eine Warteschlange ergibt, die Ihr Team tatsächlich abarbeiten kann.
3. Routinemäßig beheben: alles andere, was ausgeliefert wird. Bündeln Sie es in regelmäßigen Abhängigkeits-Upgrades, statt jeden Befund als Vorfall zu behandeln.
4. Dokumentieren: nicht betroffen. Das verwundbare Paket ist vorhanden, aber der verwundbare Code wird nicht genutzt, oder die Komponente wird nicht ausgeliefert. Halten Sie die Begründung als VEX-Statement fest, damit derselbe Befund nicht erneut zur Prüfung auftaucht und Kunden, die fragen, das Warum sehen können.

Ordnen Sie dann laufend neu. Eine Schwachstelle aus Stufe drei kann über Nacht auf Stufe eins rücken, wenn sie in KEV aufgenommen wird oder ihr EPSS-Wert steigt.

Die Schwachstellen, die Sie nie einordnen können

Jede Priorisierungsmethode ordnet die Befunde, die ihr vorliegen. Ein verwundbares Paket, das der Scanner nie gesehen hat, erzeugt keinen Befund und erhält daher nie einen CVSS-Wert, einen EPSS-Wert oder einen KEV-Treffer. Es wird nicht niedrig eingestuft. Es wird gar nicht eingestuft und trotzdem ausgeliefert.

Das passiert häufiger, als es klingt, denn die meisten Scanner leiten aus Dateien ab, was in Ihrer Software steckt: aus dem Lockfile, den Manifesten oder dem Build-Ergebnis. Alles, was der Build lädt und kein Lockfile auflistet, ist eine versteckte Abhängigkeit, und dateibasierte Tools übersehen sie:

• Install-Hooks. Code, den preinstall- und postinstall-Skripte von npm herunterladen, der Weg, den der Shai-Hulud-Wurm genutzt hat.
• Build-Skripte. Zum Beispiel Rust-Build-Skripte, die zur Build-Zeit Code herunterladen.
• Basis-Images. Das Basis-Image eines Container-Builds und seine Betriebssystem-Schichten.
• Caches. Pakete, die aus einem CI-Cache wiederhergestellt statt aus dem Lockfile installiert werden.

Das Ergebnis nachträglich zu scannen schließt die Lücke nicht. Bei einer fertigen Binärdatei, besonders bei kompiliertem Code wie Rust, muss der Scanner raten, was eingeflossen ist. Und weil Builds standardmäßig nicht reproduzierbar sind, ist ein späterer Rebuild desselben Commits keine Garantie für dieselben Abhängigkeiten.

Eine SBOM zur Build-Zeit setzt am anderen Ende an. CRACI führt Ihre GitHub-Actions-Jobs aus und sieht den Datenverkehr, der in jeden Build hineinkommt. So zeichnet es jedes Paket auf, das der Job tatsächlich geladen hat, einschließlich versteckter Abhängigkeiten. Jede SBOM trägt einen Vollständigkeitsstatus, der angibt, wann etwas nicht sichtbar war. In der Praxis hat CRACI verwundbare Pakete gefunden, die Snyk und Aikido nicht gemeldet haben, weil die Komponenten in ihren Scans fehlten. Genau das sind die Befunde, die eine Priorisierungsmethode gar nicht erst einordnen kann.

Kontext: der Teil, den Scanner nicht für Sie bewerten können

Wird die verwundbare Version wirklich ausgeliefert?

Diese Frage beseitigt das meiste Rauschen. Ein Test-Framework in einem Lockfile, ein Paket, das in einem Branch gepinnt ist, der nie veröffentlicht wird, eine Container-Stufe, die verworfen wird: Nichts davon erreicht Kunden. Eine während des Builds aufgezeichnete SBOM beantwortet die Frage anhand dessen, was der Release-Build tatsächlich verwendet hat, statt anhand dessen, was das Repository deklariert.

Welche Releases enthalten sie, und seit wann?

Ein Befund in einem Produkt, das Sie an Kunden ausliefern, bei dem jedes Release seit dem letzten Frühjahr betroffen ist, geht demselben Befund in einem internen Tool vor. Der Expositionszeitraum sagt Ihnen außerdem, was Sie offenlegen müssen.

Lässt sich der verwundbare Code erreichen?

Die Erreichbarkeitsanalyse verfolgt, ob Ihr Code die verwundbare Funktion in einer Abhängigkeit aufrufen kann. Mehrere SCA-Tools bieten sie an, und sie drückt nicht erreichbare Befunde wirksam auf der Liste nach unten. Behandeln Sie sie als einen Input unter mehreren: Sie sieht nur Codepfade, denen die Analyse folgen kann, und eine erreichbare Funktion ist nicht dasselbe wie eine ausnutzbare.

Ist sie exponiert, und gibt es einen Fix?

Ein aus dem Internet erreichbarer Dienst steht über einem Batch-Job in einem privaten Netzwerk. Eine Schwachstelle mit einer behobenen Version lässt sich günstiger schließen als eine, die eine Abhilfemaßnahme braucht. Beides ändert die Reihenfolge, nicht die Frage, ob sie behandelt wird.

Risikobasiertes Schwachstellenmanagement

Risikobasiertes Schwachstellenmanagement ist der Name für dieselbe Idee auf Programmebene: nach Belegen für Ausnutzung, Wahrscheinlichkeit, Schweregrad und Geschäftskontext ordnen, messen, wie schnell die riskantesten Befunde geschlossen werden, und akzeptieren, dass Befunde mit geringem Risiko offen bleiben können. Damit ändern sich auch die Kennzahlen. Statt der Gesamtzahl offener Schwachstellen verfolgen Sie, wie viele bekannt ausgenutzte Schwachstellen in ausgelieferter Software offen sind und wie lange sie offen bleiben.

Tools zur Priorisierung von Schwachstellen

Den Großteil der Rangfolge erstellen heute drei Arten von Tools:

• Plattformen für Infrastruktur-Schwachstellenmanagement wie Tenable, Qualys und Rapid7 bewerten Hosts, Endpunkte und Cloud-Assets mit eigenen Risikoratings, die auf Exploit-Informationen beruhen.
• SCA- und Anwendungssicherheitstools wie Snyk, Endor Labs und Semgrep ordnen Befunde zu Abhängigkeiten, mehrere davon mit Erreichbarkeitsanalyse.
• Open-Source-Tools wie Grype, das mit seinen Befunden EPSS- und KEV-Daten ausgibt, und Dependency-Track, das SBOMs laufend analysiert.

Tools für Schwachstellenmanagement im Vergleich geht sie einzeln durch.

Wie CRACI die Priorisierung unterstützt

CRACI setzt dort an, wo die Rangfolge am häufigsten schiefgeht: beim Inventar. Es führt Ihre GitHub-Actions-Jobs aus und zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich transitiver Abhängigkeiten, aus Caches wiederhergestellter Pakete und versteckter Abhängigkeiten, die kein Lockfile auflistet.

• Befunde zum Ausgelieferten. Überwachte SBOMs werden laufend neu bewertet, und Organisationsansichten führen Befunde über Builds und Repositories hinweg zusammen. Jedes Paket zeigt seine Advisories mit Schweregrad und die Pakete, die es nachziehen.
• Expositionszeitraum. Die Build-Historie zeigt, welche früheren Builds eine verwundbare Abhängigkeit enthielten, direkt oder transitiv, sodass Sie wissen, welche Releases betroffen waren und wie lange.
• Triage und Weiterleitung. Sicherheitsteams sichten Befunde und leiten jeden an das Team weiter, das für die Behebung zuständig ist. CRACI unterstützt VEX, um festzuhalten, dass eine Schwachstelle Ihr Produkt nicht betrifft.
• Gates. Policy-Gates können einen Build anhand von Befunden blockieren, auch einen Build, der eine bestimmte CVE enthält.

CRACI bietet keine Erreichbarkeitsanalyse. Wenn das Ihr wichtigstes Signal ist, wählen Sie eines der SCA-Tools, die sie anbieten. Den vollen Funktionsumfang beschreibt die Seite Schwachstellenverfolgung.

Schwachstellen priorisieren: häufig gestellte Fragen

Was ist die Priorisierung von Schwachstellen?

Die Priorisierung von Schwachstellen legt fest, welche bekannten Schwachstellen zuerst behoben werden, welche warten können und welche Sie gar nicht betreffen. Sie ordnet Befunde danach, wie wahrscheinlich ihre Ausnutzung ist und wie viel Schaden das in Ihrer Umgebung anrichten würde, nicht allein nach dem Schweregrad.

Wie priorisiert man Schwachstellen?

Beginnen Sie mit einem genauen Inventar, damit Sie Schwachstellen in Software einordnen, die tatsächlich ausgeliefert wird. Setzen Sie alles auf der Known-Exploited-Vulnerabilities-Liste von CISA an die Spitze und ordnen Sie den Rest nach Ausnutzungswahrscheinlichkeit (EPSS) und Schweregrad (CVSS), angepasst an Ihren Kontext: Exposition, Wichtigkeit des Produkts und ob es einen Fix gibt. Halten Sie Schwachstellen, die Sie nicht betreffen, als VEX-Statements fest.

Reicht CVSS aus, um Schwachstellen zu priorisieren?

Nein. CVSS misst, wie schwerwiegend eine Schwachstelle ist, nicht, wie wahrscheinlich ihre Ausnutzung ist oder wie wichtig sie für Sie ist. Eine Rangfolge allein nach CVSS stuft einen großen Teil des Backlogs als hoch oder kritisch ein, und die meisten dieser Schwachstellen werden nie ausgenutzt.

Was ist risikobasiertes Schwachstellenmanagement?

Risikobasiertes Schwachstellenmanagement ordnet und behebt Schwachstellen nach dem Risiko für Ihre Organisation und kombiniert dafür Belege für Ausnutzung, Wahrscheinlichkeit, Schweregrad und Geschäftskontext, statt sie nach CVSS-Wert oder Alter abzuarbeiten.

Was ist der Unterschied zwischen EPSS und KEV?

EPSS ist eine Prognose: die geschätzte Wahrscheinlichkeit, dass eine CVE in den nächsten 30 Tagen ausgenutzt wird. KEV ist eine Aufzeichnung: der Katalog von CISA mit Schwachstellen, für deren Ausnutzung in freier Wildbahn es Belege gibt. Ein KEV-Eintrag ist eine Tatsache, ein EPSS-Wert eine Wahrscheinlichkeit. Nutzen Sie zuerst KEV und dann EPSS, um alles andere zu ordnen.

Ersetzt die Erreichbarkeitsanalyse die Priorisierung?

Nein, sie ist ein weiterer Input. Die Erreichbarkeitsanalyse prüft, ob Ihr Code die verwundbare Funktion in einer Abhängigkeit aufrufen kann. Sie entfernt Befunde, die sich nicht auslösen lassen, sagt aber nichts darüber, wie wahrscheinlich eine Ausnutzung ist, und deckt nur Code ab, dem die Analyse folgen kann.