Die Rechnung
Drei Faktoren multiplizieren die Zahl unserer Findings: wie viele Assets wir betreiben, wie viele Scanner wir darauf ansetzen, wie oft diese Scanner laufen. Unsere Triage-Kapazität wächst, wenn wir jemanden einstellen.
Trivy scannt jedes Image, das wir bauen. Nessus prüft turnusmäßig jeden Host, den wir betreiben. Statische und dynamische Application Scanner decken zusätzlich unseren Code ab, wobei diese Findings an die Entwicklungsteams gehen und dort bearbeitet werden, wo der Code liegt. Penetrationstester legen ihre Ergebnisse im selben System ab wie alles andere. Nichts davon wird langsamer, während wir aufholen.
Die eigentlichen Kosten stecken im Backlog. Vierzigtausend offene Findings begraben die vier, die ein Angreifer in diesem Quartal tatsächlich nutzt, und kein Dashboard zeigt Ihnen das.
Der kostenlose Kontext wird dünner
NIST hat im April erklärt, dass die eigene Kapazität erschöpft ist. 2025 wurden knapp 42.000 CVEs angereichert, 45 % mehr als in jedem Jahr zuvor, und selbst das reichte nach eigener Aussage nicht aus. Seit dem 15. April 2026 werden drei Kategorien vorrangig angereichert: Einträge im CISA Known Exploited Vulnerabilities Catalog2, Software im Einsatz der US-Bundesbehörden und kritische Software nach Executive Order 140283. Alles andere erscheint als niedrigste Priorität, und NIST vergibt keinen eigenen Severity Score mehr, wenn die meldende Stelle bereits einen geliefert hat.1
Daraus folgen zwei Dinge für alle, die nach CVSS priorisieren. Mehr CVEs erreichen uns ohne NVD-Score und ohne Liste betroffener Produkte, diese Arbeit landet also bei uns. Und die eine Kategorie, die NIST weiterhin innerhalb eines Werktags anreichert, ist KEV. Das sagt etwas darüber aus, welchem Signal NIST vertraut.
Warum Teams hier zu KI greifen
Der Impuls ist nachvollziehbar. Triage sieht nach Urteilsvermögen aus, also wirkt eine Maschine, die Urteilsvermögen imitiert, wie die Lösung.
Ein einzelnes Finding kostet uns rund zehn Minuten Recherche: den Scanner-Eintrag öffnen, prüfen, ob der CVSS-Score plausibel ist und die Schwelle zur Aufmerksamkeit überhaupt überschreitet, nach einem Vendor Patch suchen, klären, ob der Host die betroffene Komponente in einer Konfiguration betreibt, die sie angreifbar macht. Vier Systeme, vier Antworten.
Die Entscheidung danach dauert Sekunden und folgt einer Regel, die auf eine Karteikarte passt. Intelligenz einzukaufen löst die falsche Hälfte dieses Problems.
Determinismus bringt uns Dinge, die ein Modell nicht liefern kann. Wir können einem Auditor die Regel selbst zeigen. Wir können die Findings des Vorjahres durch ein Regelwerk laufen lassen und sehen, was es entschieden hätte, bevor wir es produktiv setzen. Wenn eine Regel danebengreift, finden wir die Zeile und ändern sie.
Es gibt auch ein Sicherheitsargument. CVE-Beschreibungen und Vendor Advisories enthalten Text, den ein Angreifer beeinflussen kann. Diesen Text wollen wir nicht an etwas verfüttern, das Aktionen auf unserer Infrastruktur ausführt.
Was wir zuerst gebaut haben
Trivy deckt unsere Container Images und unseren Infrastructure-as-Code ab. Nessus deckt Hosts und Netzwerk ab. Ein Skript schiebt beide Ergebnismengen nach DefectDojo, und unsere Findings aus Penetrationstests landen an derselben Stelle. DefectDojo übernimmt die Deduplizierung und hält unseren Bearbeitungsstand: Risiko akzeptiert, False Positive, verifiziert.
Ein zweites Skript liest DefectDojo über Filter aus, bewertet die Treffer nach CVSS, prüft Tags wie internet-facing und public-audience und alarmiert bei den am höchsten bewerteten Findings, damit sich noch am selben Tag jemand darum kümmert.
Das hat uns eine einzige Queue gebracht, ein führendes System und einen Alarmpfad, der bei den offensichtlichen Notfällen auslöst. Er erwischt genau das, wofür wir ihn gebaut haben.
Der größte Teil unserer Triage blieb allerdings, wo er war: bei einer Analystin, die DefectDojo von Hand durcharbeitet. Eine Zeit lang gingen wir davon aus, dass wir eine bessere Bewertung brauchen. CVSS bewertet, wie schlimm eine Schwachstelle für eine hypothetische Organisation mit einem hypothetischen Deployment sein könnte. Über die tatsächliche Ausnutzung sagt der Score nichts, und darüber, ob der betroffene Host aus dem Internet erreichbar ist, ebenso wenig. Exploitability-Daten sahen deshalb nach dem fehlenden Baustein aus.
Bessere Eingangsdaten waren nur die halbe Antwort.
Die Hälfte, die wir übersehen haben
Beide Skripte bewegen Findings in dieselbe Richtung. Das eine schiebt sie nach DefectDojo. Das andere schiebt eine Teilmenge in Richtung Mensch. Nichts, was wir gebaut hatten, nahm einem Menschen ein Finding ab.
Die Queue wuchs also weiter, und eine Analystin öffnete weiterhin jeden Eintrag, um zu entscheiden, dass er das Öffnen nicht wert war. Genau diese Arbeit hätte als Erstes verschwinden müssen.
Eine Regel, die Findings entfernt, läuft längst bei uns, und wir haben sie nie als Automatisierung gezählt. DefectDojo schließt ein Finding, sobald der nächste Scan es nicht mehr meldet. Ein abgeschalteter Host nimmt seine Schwachstellen also mit, und niemand sieht sie sich noch an. Genau dieses Muster hätten wir häufiger gebraucht, und wir hatten nie eine zweite Regel dieser Art geschrieben.
Zwei weitere leeren den größten Teil des Rests, und keine davon braucht Intelligenz:
Es gibt keinen Fix. Der Hersteller hat keinen Patch veröffentlicht. Heute kann niemand handeln, also gehört das Finding mit Wiedervorlagedatum auf eine Beobachtungsliste und aus der Review-Queue heraus.
Nichts erreicht es und niemand nutzt es aus. Interner Host, kein Eintrag im CISA-Katalog bekannter ausgenutzter Schwachstellen, niedriger Wert im Exploit Prediction Scoring System. Das Finding geht in den monatlichen Patch-Zyklus und taucht in keinem Review mehr auf.
Eine weitere Änderung zahlt sich von selbst. Wir haben jedes Finding einzeln bearbeitet, obwohl ein einzelner Fix viele Findings auf einmal schließt. Ein einziges Base-Image-Update schließt hunderte Trivy-Findings über dutzende Services hinweg. Ein einziges Versions-Upgrade eines Dienstes schließt dasselbe Nessus-Finding auf jedem Host, der ihn betreibt. Gruppieren Sie nach Remediation-Maßnahme, und die Queue schrumpft, bevor jemand eine Zeile davon liest.
Was wir gerade bauen
Vier Eingangsdaten, die wir alle abrufen können oder bereits besitzen:
- Ausnutzung: Eintrag im CISA KEV, EPSS-Wahrscheinlichkeit. Beide sind kostenlos, beide hängen an der CVE, beide kosten einen Nachmittag Entwicklungszeit.
- Exposition: unsere vorhandenen Tags, die Erreichbarkeit im Netz und Größe des Publikums als getrennte Signale führen.
- Verfügbarkeit eines Fixes: melden Trivy und Nessus beide.
- Kritikalität des Assets: aus unserem Inventar, bewertet mit niedrig, mittel oder hoch.
Sechs Entscheidungen, jede mit einer Frist. Die Struktur lehnt sich an SSVC an, den von CISA veröffentlichten Entscheidungsbaum-Ansatz, mit unseren eigenen Schwellenwerten. Die Zeilen werden von oben nach unten ausgewertet, der erste Treffer gewinnt:
| Exploitation | Exposure | Fix available | Decision | Clock |
|---|---|---|---|---|
| In CISA KEV | Internet-facing, public audience | Yes | Fix now | 24 hours |
| In CISA KEV | Internet-facing | No | Compensating control | 24 hours |
| In CISA KEV | Internet-facing, limited audience | Yes | Fix this week | 7 day |
| EPSS above 0.1 | Internet-facing | Yes | Fix this week | 7 days |
| In CISA KEV | Internal only | Yes | Fix in two weeks | 14 days |
| No KEV entry, low EPSS | Internal only | Yes | Next patch cycle | 30 days |
| Any | Any | No | Watch list | Recheck in 30 days |
Eine kompensierende Maßnahme verändert die Umgebung statt der Software: eine Proxy- oder Firewall-Regel, die den betroffenen Pfad blockiert, ein abgeschaltetes Feature, ein Dienst, der aus dem Internet genommen wird. Das Finding bleibt offen, die Maßnahme wird daran dokumentiert, und die Frist startet neu, sobald ein Patch erscheint.
Hohe Kritikalität schiebt ein Finding eine Zeile nach oben. Mittel und niedrig belassen es dort, wo die Tabelle es einordnet, und nach unten verschiebt es nichts. Eine KEV-gelistete Schwachstelle auf unserem Kundendatenspeicher bekommt damit die 7-Tage-Frist statt 14.
Das ist unser Ausgangspunkt. Die Schwellenwerte, die Fristen und die Kritikalitätsregel stammen von uns, und wir erwarten, dass der Schattenbetrieb uns zeigt, welche davon falsch liegen.
Findings aus Penetrationstests führen wir an der Tabelle vorbei. Der Tester hat die Triage bereits von Hand erledigt, den Angriffspfad durchlaufen und das Finding mit einem vollständigen CVSS-Vektor inklusive Exploitability-Metriken bewertet. Manche dieser Findings tragen eine CVE, andere nicht, KEV und EPSS haben also keinen Anknüpfungspunkt. Sie gehen mit der Bewertung des Testers und dem im Debriefing vereinbarten Termin an den Verantwortlichen für den Bericht.
Die Tabelle läuft im Schattenbetrieb gegen die Findings des letzten Quartals, während wir ihre Entscheidungen mit denen unserer Analysten vergleichen. Drei Fälle aus diesem Durchlauf:
Ein CVSS 9.8 in einer Container-Bibliothek, kein KEV-Eintrag, EPSS unter 0,01, auf einem internen Build Agent. Unser aktueller Filter schickt eine Slack-Nachricht ans Team. Die Tabelle gibt das Finding in den monatlichen Zyklus, und niemand liest es.
Ein CVSS 6.5 auf einem aus dem Internet erreichbaren Host mit öffentlichem Publikum, KEV-gelistet, Patch verfügbar. Unser aktueller Filter lässt das Finding unter die Alarmschwelle fallen. Die Tabelle macht daraus einen 24-Stunden-Fall.
Ein CVSS 8.1 auf einem aus dem Internet erreichbaren Host, KEV-gelistet, ohne Vendor Patch. Heute kehrt dieses Finding in jedem Zyklus in die Review-Queue zurück, und jemand liest es erneut, ohne handeln zu können. Die Tabelle gibt ihm 24 Stunden für eine kompensierende Maßnahme. Wir blockieren den betroffenen Pfad also am Proxy und dokumentieren das am Finding, bis ein Patch existiert.
Unser alter Filter behandelt alle drei falsch, in drei verschiedene Richtungen.
Was es kostet und wie wir es messen
Das Budget fließt an unspektakuläre Stellen. Die Tag-Abdeckung verfällt in dem Moment, in dem jemand einen Service ohne Tags ausrollt. Tag-Abdeckung wird damit zu einer Kennzahl, die wir messen, statt sie vorauszusetzen. Die Scan-Abdeckung braucht einen Verantwortlichen, denn DefectDojo schließt Findings, die in Scans nicht mehr auftauchen, und ein Host, der durch einen defekten Agent oder ein übersehenes Netzsegment aus dem Nessus-Scope fällt, sieht exakt aus wie ein gepatchter Host. Risikoakzeptanzen in DefectDojo brauchen ein Ablaufdatum, denn eine unbefristete Akzeptanz ist eine Entscheidung, die niemand mehr prüft, sobald die Person, die sie getroffen hat, das Unternehmen verlässt.
Vier Zahlen zeigen uns, ob das funktioniert:
- Anteil der Findings, die die Pipeline ohne Menschen entscheidet
- Manuelle Bearbeitungsschritte pro Finding
- Mediane Zeit von der Erfassung bis zur Entscheidung
- Automatisch zurückgestellte Findings, die später im KEV auftauchen
Die letzte Zahl hält uns ehrlich. Eine Pipeline, die nie einen Fehlgriff sichtbar macht, ist eine Pipeline, die niemand prüft.
Drei Dinge leistet das nicht:
- Regeln veralten. Also besitzt sie jemand und prüft sie quartalsweise, so wie jemand ein Firewall-Regelwerk besitzt.
- Unsere vier Eingangsdaten sagen nichts darüber, ob ein Host die betroffene Komponente in einer angreifbaren Konfiguration betreibt. Trivy meldet, dass das Paket im Image liegt. Ob der Dienst es lädt, ob das verwundbare Feature aktiviert ist, ob in diesem Deployment überhaupt etwas herankommt: Da muss weiterhin jemand hinsehen.
- Und die Queue für Menschen erreicht nie null. Wir wollen sie auf die wenigen Prozent mehrdeutiger Findings herunterbringen, bearbeitet von jemandem, der Zeit hat, darüber nachzudenken, statt einen Vormittag lang CVSS von Hand nachzubewerten.
Wenn Ihre Queue aussieht wie unsere damals
Unser Stack ist ein verbreiteter: Scanner, DefectDojo, ein paar Skripte und ein Review-Prozess, der still und leise zum Vollzeitjob geworden ist. Wenn Ihrer dem ähnelt, lässt sich die Diagnose vermutlich übertragen, und der teure Teil steckt in der Tag-Abdeckung, der Scan-Abdeckung und der Entscheidung, welche Findings Sie eine Regel schließen lassen, ohne dass ein Mensch sie liest.
Sprechen Sie uns an, wenn Sie Ihr Vulnerability Management verbessern wollen.