So reduzieren Sie die Alarmflut im Schwachstellenmanagement

Woher die Alarmflut bei Schwachstellen kommt

Nehmen Sie ein Backlog und sortieren Sie es danach, woher jeder Befund stammt. Die Zahlen unten dienen der Veranschaulichung und sind kein Benchmark, aber die Kategorien sind die, auf die Teams stoßen, wenn sie eine Stichprobe aus ihrem eigenen Backlog ziehen.

Herkunft des Befunds	Von 1.000 Befunden (zur Veranschaulichung)	Schritt, der ihn beseitigt
Komponenten, die Sie nicht ausliefern: Einträge in Lockfile und Manifest, Builder-Layer, Entwicklungs- und Testtools	300	1. Das Inventar korrigieren
Dieselbe CVE, von mehreren Tools oder einmal pro Repository gemeldet	250	2. Jeden Befund einmal zählen
Falsche Treffer: CPE-Namenskollisionen, Backports der Distributionen	80	1. Das Inventar korrigieren
Echte Befunde, die sich in Ihrem Produkt nicht ausnutzen lassen	150	4. Kontext zur Ausnutzbarkeit ergänzen
Echte Befunde ohne verfügbaren Fix	70	5. Eine Richtlinienentscheidung mit Ablaufdatum
Befunde ohne Verantwortlichen	50	5. An einen Verantwortlichen weiterleiten
Bleibt zum Einordnen und Beheben	100	Priorisierung

Eine Unterscheidung macht den Rest dieser Seite einfacher. Manche dieser Befunde sind False Positives: Der Befund ist falsch, weil die Komponente nicht vorhanden oder die Version nicht betroffen ist. Andere gehören zur Alarmflut: Der Befund stimmt, ändert aber nichts an dem, was Sie diese Woche tun. Beide brauchen unterschiedliche Lösungen, und wer sie verwechselt, unterdrückt am Ende echte Befunde oder streitet über falsche.

False Positive: Der Befund ist falsch	Alarmflut: richtig, aber nicht dringend
Die Komponente ist nicht in dem enthalten, was Sie ausliefern	Der verwundbare Code ist in Ihrem Produkt nicht erreichbar oder nicht auslösbar
Der Treffer ist falsch: eine CPE-Kollision oder ein zurückportierter Fix, den die Versionsnummer verbirgt	Es gibt noch keinen Fix, oder das Produkt ist intern und nicht exponiert
Beheben durch Korrektur von Inventar und Abgleich	Beheben durch Kontext, eine dokumentierte Entscheidung und einen Verantwortlichen

Schritt 1. Das Inventar an das anpassen, was Sie ausliefern

Das ist der größte einzelne Hebel, denn jeder spätere Schritt vervielfacht die Fehler des Inventars. Eine Komponente, die gelistet, aber nie ausgeliefert wird, erzeugt einen Befund in jedem Scanner, jedem Repository und jedem Release.

• Aus dem Build aufzeichnen. Erstellen Sie das Inventar aus dem, was der Release-Build tatsächlich verwendet hat, nicht aus Manifesten oder einem Scan des fertigen Artefakts. Eine Build-Time-SBOM enthält, was der Job geladen hat, auch das, was in keinem Lockfile steht.
• Komponenten per PURL identifizieren. Eine Package URL wie pkg:npm/[email protected] benennt Ökosystem, Paket und Version exakt. Der Abgleich mit Advisories, die nach PURL geschlüsselt sind, etwa den Ökosystem-Advisories in OSV, beseitigt die falschen Treffer, die entstehen, wenn eine CPE aus einem Produktnamen erraten wird.
• Für Betriebssystempakete distributionsbewusst abgleichen. Debian und andere Distributionen portieren Sicherheitsfixes auf die ausgelieferte Version zurück, statt zu aktualisieren, sodass die Versionsnummer älter wirken kann als der Upstream-Fix. Gleichen Sie mit dem eigenen Security-Tracker der Distribution ab, nicht mit Upstream-Versionsbereichen.
• Die Vollständigkeit verfolgen. Wissen Sie, wann das Inventar etwas nicht erfassen konnte, statt Vollständigkeit anzunehmen. Eine fehlende Komponente ist schlimmer als eine überflüssige: Sie erzeugt überhaupt keinen Befund.

Durchgerechnetes Beispiel. Das Lockfile eines Node.js-Dienstes enthält [email protected], eine Glob-Matching-Bibliothek, von der Test- und Build-Tools abhängen. Ein Lockfile-Scan meldet CVE-2024-4067, einen Denial of Service über reguläre Ausdrücke, behoben in 4.0.8. Der Release-Job installiert nur Produktionsabhängigkeiten, mit npm ci --omit=dev, sodass micromatch nie in den ausgelieferten Build gelangt. Eine Aufzeichnung dieses Builds enthält es nicht, und der Befund erreicht das Backlog nie. Die CVE ist echt; für dieses Produkt ist der Befund ein False Positive.

Schritt 2. Jeden Befund einmal zählen

Dieselbe CVE kommt vom SCA-Tool, vom Container-Scanner und von der SBOM-Plattform, und noch einmal für jedes Repository, das die Bibliothek nutzt. Deduplizieren Sie über einen Schlüssel: Package URL, Version und CVE. So ist pkg:npm/[email protected] mit CVE-2024-45296 ein Befund, egal wie viele Tools ihn melden.

• Zählen Sie einen Befund pro ausgeliefertem Artefakt, nicht einen pro Scanner.
• Fassen Sie über Builds und Repositories hinweg zusammen, sodass die CVE einer gemeinsam genutzten Bibliothek eine Entscheidung ist, die überall gilt, und nicht vierzig Tickets.
• Konsolidieren Sie überlappende Scanner. Eine einfache Regel: Befunde zu Abhängigkeiten kommen aus einer SCA- oder SBOM-Quelle, Befunde zu Images aus einem Container-Scanner, Befunde in Ihrem eigenen Code aus einem SAST-Tool. Wenn zwei Tools dasselbe Signal melden, behalten Sie das, das näher an dem ist, was ausgeliefert wird (SAST vs. SCA).

Schritt 3. Weniger ausliefern

Jede Abhängigkeit, die Sie nicht ausliefern, ist eine Quelle von Befunden, um die Sie sich nie kümmern müssen.

• Ungenutzte Abhängigkeiten entfernen. Die meisten Projekte schleppen ein paar Pakete mit, die nichts mehr importiert.
• Das Paket aktualisieren, das die verwundbaren nachzieht. Express 4.19.2 pinnt [email protected] und [email protected], die CVE-2024-45590 und CVE-2024-45296 enthalten. Ohne Overrides können Sie sie nicht einzeln aktualisieren. Express 4.20.0, im September 2024 veröffentlicht, hängt von den behobenen Versionen ab, sodass ein Upgrade beide beseitigt (transitive Abhängigkeiten).
• Minimale Base-Images verwenden. Slim- und Distroless-Images enthalten weniger Betriebssystempakete, also treffen weniger Advisories zu. Container-Scanning behandelt die Image-spezifischen Hebel.
• Bewusst pinnen und aktualisieren. Lockfiles und Digests halten das Inventar zwischen Builds stabil.
• Builds blockieren, die eine bekannt verwundbare Version enthalten. Ein Policy Gate, das den Build stoppt, hält eine verwundbare Bibliothek fern, bevor sie zu einem Befund wird, den jemand triagieren muss.

example-service
└─ [email protected]          → upgrade to 4.20.0
   ├─ [email protected]    CVE-2024-45590
   └─ [email protected]  CVE-2024-45296

Schritt 4. Kontext zur Ausnutzbarkeit ergänzen

Was nach den Schritten 1 bis 3 übrig bleibt, ist echt. Der Kontext entscheidet, was davon dringend ist.

• VEX. Halten Sie „nicht betroffen“ einmal mit Begründung als VEX-Aussage fest, und verwenden Sie sie über Releases und Kunden hinweg wieder. Wenn Kunden ihre eigenen Scans Ihres Produkts weiterleiten, beantworten dieselben Aufzeichnungen ihre Fragen: siehe ein PSIRT skalieren und, für Antwortvorlagen, wie Sie Kunden nach einem Lieferkettenangriff antworten.
• Erreichbarkeit zeigt, sofern Ihre Tools sie bieten, ob Ihr Code die verwundbare Funktion aufrufen kann. Sie hilft, mit Grenzen (Erreichbarkeitsanalyse).
• Signale zur Ausnutzung. CISA KEV sagt, dass eine Schwachstelle in freier Wildbahn ausgenutzt wird; EPSS schätzt, wie wahrscheinlich eine Ausnutzung in den nächsten 30 Tagen ist.
• Exposition. Ein aus dem Internet erreichbares Produkt hat Vorrang vor einem internen Tool in einem privaten Netz.

Schritt 5. Befunde nach Richtlinie an einen Verantwortlichen weiterleiten

• Schwellenwerte als Richtlinie festlegen. Legen Sie Schwellenwerte für Schweregrad und Ausnutzbarkeit pro Produkt oder Repository in einer Richtlinie fest, nicht als Dashboard-Filter, den eine Person gesetzt hat.
• Verantwortliche zuweisen, nach Repository oder Team, sodass jeder Befund jemanden hat, der entscheidet.
• „Kein Fix verfügbar“ ausdrücklich entscheiden: mit Ablaufdatum akzeptieren, abmildern oder die Komponente ersetzen. Ein Befund ohne Fix sollte nicht ohne Entscheidung offen liegen.

Entwickler ignorieren Befunde aus vier Gründen: kein Verantwortlicher, kein Kontext, keine Frist oder der falsche Kanal. Teams, mit denen wir sprechen, berichten, dass die Entwicklung Scanner abgeschaltet hat, weil die Ausgabe vor lauter Alarmflut nicht mehr lesbar war. Beheben Sie jeden Grund: ein Verantwortlicher pro Repository, der Kontext aus Schritt 4 angehängt, eine Frist aus der Richtlinie und die Zustellung dort, wo das Team ohnehin arbeitet.

Alarmflut reduzieren oder Risiko verstecken

Ein kleineres Backlog ist nur dann besser, wenn es aus den richtigen Gründen geschrumpft ist.

• Unterdrückung ohne Grund und Ablaufdatum erzeugt versteckte Schulden. Sie kommen bei einem Audit oder einem Vorfall zurück, und niemand weiß mehr, warum.
• Untergrenzen beim Schweregrad verstecken falsche Befunde, statt sie zu beseitigen. „Nichts unter CVSS 7“ lässt einen False Positive mit CVSS 6 verschwinden und einen mit CVSS 9 stehen.
• Jede Entscheidung, nicht zu beheben, braucht eine Dokumentation. Kunden fragen danach, und Regulierungen wie der EU Cyber Resilience Act ebenso, der von Herstellern erwartet, Schwachstellen über den gesamten Supportzeitraum eines Produkts zu behandeln.

So messen Sie es

• Befunde pro ausgeliefertem Release, nicht pro Scan.
• Der Anteil der Befunde, auf die reagiert wurde: behoben, abgemildert oder entschieden.
• Mit VEX-Eintrag als nicht betroffen geschlossen, im Vergleich zu ohne Eintrag unterdrückt.
• Zeit vom Build bis zum Verantwortlichen: wie lange ein neuer Befund wartet, bis jemand ihn übernimmt.
• Die Duplikatrate über alle Tools.

Eine Stichprobe von 50 Befunden, die Sie an einem Nachmittag ziehen können. Wählen Sie 50 offene Befunde zufällig aus. Halten Sie für jeden fest, ob die Komponente im Release ausgeliefert wird, ob ein anderes Tool oder Repository denselben Befund meldet, ob der Treffer korrekt ist, ob er in Ihrem Produkt ausnutzbar ist, ob es einen Fix gibt und wer verantwortlich ist. Die Zahlen sagen Ihnen, mit welchem Schritt Sie beginnen sollten. Wiederholen Sie dieselbe Stichprobe ein Quartal später. Branchen-Benchmarks für diese Zahlen nennen wir nicht, weil keine Primärquelle einen stützt.

Wo CRACI ins Spiel kommt

CRACI arbeitet an den Schritten 1 und 2, am Build-Gate in Schritt 3 und an Teilen der Schritte 4 und 5, für Software, die in GitHub Actions gebaut wird.

• Das Inventar. CRACI ersetzt Ihre GitHub-hosted Runner und zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, mit einer PURL pro Komponente und einem Vollständigkeitsstatus pro SBOM. Jede Komponente in einer CRACI-SBOM war im Build. Diese Genauigkeit betrifft die Komponenten der SBOM; eine zugeordnete CVE kann Ihr Produkt trotzdem nicht betreffen. Dafür gibt es VEX, und CRACI unterstützt VEX.
• Ein Befund, viele Builds. Befunde werden über Builds und Repositories hinweg zusammengefasst, und überwachte SBOMs werden fortlaufend neu bewertet, sobald neue Schwachstellen veröffentlicht werden.
• Gates. Policy Gates können einen Build bei Befunden in Echtzeit stoppen, auch einen Build, der eine bestimmte CVE enthält.
• Triage und Zuweisung. Security-Teams triagieren Befunde in CRACI und leiten jeden Befund an das Team weiter, das für den Fix zuständig ist.
• Benachrichtigungen. CRACI benachrichtigt die zuständigen Personen über eine Schwachstelle und ihren Schweregrad.

CRACI bietet keine Erreichbarkeitsanalyse, kein SAST und keine MTTR-Dashboards. Den vollen Funktionsumfang zeigt die Schwachstellenverfolgung, oder sehen Sie, was Ihre Builds tatsächlich enthalten.

Wann CRACI nicht die Antwort ist

• Der Großteil Ihrer Alarmflut sind SAST-Befunde in Ihrem eigenen Code. Das ist eine Frage des SAST-Tunings.
• Ihr Backlog besteht überwiegend aus echten, ausnutzbaren Befunden in ausgeliefertem Code. Das ist ein Problem der Behebungskapazität, kein Problem der Alarmflut.
• Sie brauchen Laufzeitkontext aus produktiven Workloads. Das beantwortet ein CNAPP- oder Runtime-Security-Tool.

Für den größeren Plan lesen Sie was Sie automatisieren sollten, wenn die CVE-Zahlen weiter steigen, und sehen Sie die Live-Zahlen unter CVE-Veröffentlichungstrends.

Alarmflut bei Schwachstellen reduzieren: häufige Fragen

Wie reduziere ich die Zahl der Schwachstellenwarnungen?

Dämmen Sie sie an der Quelle ein, in dieser Reihenfolge: Bringen Sie das Inventar mit dem in Einklang, was Sie ausliefern, deduplizieren Sie Befunde nach Package URL, Version und CVE, liefern Sie weniger Abhängigkeiten aus, ergänzen Sie Kontext zur Ausnutzbarkeit wie VEX, KEV und EPSS, und leiten Sie den Rest nach einer schriftlichen Richtlinie an einen Verantwortlichen weiter. Priorisieren Sie dann.

Warum meldet unser Scanner Tausende Schwachstellen, und welche davon zählen?

Meist, weil er Komponenten meldet, die Sie nicht ausliefern, dieselbe CVE einmal pro Tool und Repository meldet und manche Treffer falsch errät. Es zählen die Befunde in Komponenten, die Ihr Release tatsächlich enthält, die in Ihrem Produkt ausnutzbar sind und bekanntermaßen oder wahrscheinlich ausgenutzt werden.

Wie dedupliziere ich Befunde aus mehreren Security-Tools?

Schlüsseln Sie jeden Befund nach Package URL, Version und CVE, und zählen Sie einen Befund pro ausgeliefertem Artefakt. Fassen Sie über Repositories hinweg zusammen, sodass eine gemeinsam genutzte Bibliothek eine Entscheidung ist. Weisen Sie dann jede Art von Signal einem Tool zu, damit nicht zwei Scanner dasselbe melden.

Sollten wir Schwachstellen ohne Fix unterdrücken?

Nicht stillschweigend. Treffen Sie eine ausdrückliche Entscheidung: Akzeptieren Sie das Risiko mit schriftlicher Begründung und Ablaufdatum, mildern Sie es ab, oder ersetzen Sie die Komponente. Prüfen Sie es erneut, sobald ein Fix erscheint. Eine Unterdrückung ohne Grund und Ablaufdatum erzeugt versteckte Schulden.

Gehört eine Schwachstelle, die seit einem Jahr niemand behoben hat, noch zur Alarmflut?

Nicht unbedingt. Das Alter sagt nichts über das Risiko. Wenn sie ausgeliefert wird und ausnutzbar ist, braucht sie eine Entscheidung und einen Verantwortlichen. Wenn sie Ihr Produkt nicht betrifft, halten Sie das als VEX-Aussage fest, damit sie nicht immer wieder auftaucht. So oder so sollte sie nicht ohne Entscheidung offen liegen.

Wie sorge ich dafür, dass Entwickler Security-Befunde nicht ignorieren?

Geben Sie jedem Befund einen Verantwortlichen, den Kontext zum Handeln und eine Frist aus einer schriftlichen Richtlinie, und stellen Sie ihn dort zu, wo das Team ohnehin arbeitet. Dämmen Sie zuerst die Alarmflut ein: Entwickler hören auf, einen Kanal zu lesen, in dem die meisten Befunde keine Rolle spielen.

Wie viele offene Schwachstellen sind ein guter Wert?

Es gibt keinen verlässlichen Benchmark, und die reine Anzahl ist das falsche Maß. Verfolgen Sie die Befunde pro ausgeliefertem Release, den Anteil, auf den reagiert wurde, den Anteil, der mit dokumentiertem Grund geschlossen wurde, und wie lange bekannt ausgenutzte Schwachstellen in ausgelieferter Software offen bleiben.