Schwachstellenmanagement

Wie läuft der Schwachstellenmanagement-Prozess ab?

Schwachstellenmanagement läuft als Kreislauf in fünf Schritten. Am Anfang steht das Finden. Scanner prüfen Server und Netze, der Abgleich der SBOM (Software Bill of Materials) zeigt bekannte Lücken in den Bibliotheken der eigenen Software, und Herstellerhinweise kommen zunehmend maschinenlesbar im Format CSAF (Common Security Advisory Framework) an, das seit 2025 als ISO/IEC 20153 genormt ist. Danach bewertet das Team, ob die Lücke im eigenen Umfeld überhaupt erreichbar ist, priorisiert sie und behebt sie. Der fünfte Schritt ist der Nachweis, dass die Korrektur auf allen betroffenen Systemen angekommen ist. Von Hand schafft das kaum ein Team. Das BSI beziffert die neuen CVE-Einträge (Common Vulnerabilities and Exposures) für 2024 nach Angaben des CVE-Programms auf mehr als 40.000, 39 Prozent mehr als im Vorjahr.

Was ist der Unterschied zwischen Schwachstellenmanagement und Patch-Management?

Patch-Management ist der Teil des Schwachstellenmanagements, der Updates einspielt. Das Schwachstellenmanagement entscheidet vorher, welche Lücke zuerst drankommt, und regelt auch die Fälle, für die es keinen Patch gibt. Das BSI verlangt im IT-Grundschutz-Baustein OPS.1.1.3, Patches zeitnah nach Veröffentlichung zu bewerten und zu priorisieren. Wer einen Patch nicht einspielt, dokumentiert Entscheidung und Gründe. In der OT kommt das oft vor, weil Updates erst im Wartungsfenster auf die Anlage dürfen und manche Bedienstation gar keine mehr bekommt. Hersteller haben zusätzlich die Lücken im eigenen Produkt zu behandeln. Der Cyber Resilience Act verlangt dafür in Anhang I Teil II unter anderem eine Strategie für die koordinierte Offenlegung, eine Kontaktadresse für Meldungen und Sicherheitsupdates, die in der Regel kostenlos sind.

Für die Priorisierung reicht der CVSS-Wert allein nicht. Er beschreibt auf einer Skala von 0 bis 10 den Schweregrad einer Lücke. FIRST (Forum of Incident Response and Security Teams), die Organisation hinter dem Standard, rät deshalb, die Basiswerte um Bedrohungs- und Umgebungsmetriken aus dem eigenen Betrieb zu ergänzen. Seit Version 4.0 von 2023 kennt CVSS dafür auch eine optionale Safety-Metrik, die sich an den Schadenskategorien der IEC 61508 orientiert. Ob eine Lücke tatsächlich angegriffen wird, zeigen zwei andere Quellen. EPSS (Exploit Prediction Scoring System) schätzt täglich für jede CVE die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen. Der Katalog Known Exploited Vulnerabilities (KEV) der US-Behörde CISA listet bestätigt ausgenutzte Lücken, am 15. Oktober 2026 waren es 1.746.

Seit dem 11. September 2026 läuft für Hersteller eine Uhr mit. Nach Artikel 14 des Cyber Resilience Act meldet ein Hersteller jede aktiv ausgenutzte Schwachstelle in seinem Produkt binnen 24 Stunden als Frühwarnung an das zuständige CSIRT (Computer Security Incident Response Team) und die EU-Agentur ENISA. Nach 72 Stunden folgt die Meldung, spätestens 14 Tage nach Bereitstellung der Korrektur der Abschlussbericht. Die Frist läuft ab Kenntnis, auch über das Wochenende. Die Vorarbeit dafür lässt sich in der CI/CD-Pipeline erledigen. Jeder Build erzeugt eine SBOM, und eine Plattform wie Dependency-Track von der OWASP Foundation gleicht die archivierten SBOMs gegen Quellen wie die National Vulnerability Database, GitHub Advisories und OSV (Open Source Vulnerabilities) ab und zeigt den EPSS-Wert dazu. Wird eine Lücke bekannt, zeigt die Plattform, welche Releases die betroffene Komponente enthalten.