Schwachstellenmanagement: Ein Prozess, der in der Praxis hält

Schwachstellenmanagement ist eine Schleife: wissen, was du hast, erfahren, was daran kaputt ist, entscheiden, was zählt, rechtzeitig beheben, den Fix belegen. Die meisten Unternehmen haben den mittleren Teil, einen Scanner, der Findings liefert. Was fehlt, ist meist der Anfang (ein vollständiges Inventar) und das Ende (Fristen, die eingehalten und gemessen werden). So baust du die ganze Schleife, für die eigene IT und, wenn du Produkte herstellst, für die Produkte, die du auslieferst, wo der Cyber Resilience Act den Prozess jetzt zur Pflicht macht.

Schritt 1: Wissen, was du hast

Du kannst keine Schwachstellen in Systemen managen, von denen du nichts weißt. Das Inventar hat zwei Ebenen:

• Assets. Server, Cloud-Accounts, Arbeitsplätze, Netzwerkgeräte, OT-Steuerungen und für Hersteller jede Produktversion, die noch im Support ist. Jedes mit einem Verantwortlichen.
• Komponenten. Die Software in jedem Asset. Für Produkte ist das die SBOM, die Software-Stückliste, in CycloneDX oder SPDX. Der CRA verlangt eine für jedes Produkt (Anhang I Teil II Nr. 1), mindestens über die Abhängigkeiten der obersten Ebene; die BSI TR-03183 Teil 2 beschreibt einen brauchbaren Detailgrad. Ohne SBOM bedeutet das nächste Log4j eine Woche Suche auf Build-Servern.

Schritt 2: Aus jeder Quelle sammeln

Schwachstellen kommen über mehrere Kanäle, und der Prozess muss alle annehmen:

Quelle	Typisches Volumen	Hinweis
Netzwerk- und Host-Scanner	Hoch	Viele Duplikate und False Positives, braucht Tuning
Abhängigkeits- und Container-Scans gegen die SBOM	Hoch	In der CI automatisieren, gegen NVD und Hersteller-Feeds abgleichen
Penetrationstests	Niedrig, hoher Wert	Verifiziert, ausnutzbar, mit Schritten zum Nachstellen
Hersteller-Advisories und CERT-Feeds	Mittel	Braucht das Inventar, um Betroffenheit zu erkennen
Externe Meldungen (Forscher, Kunden)	Niedrig	Braucht einen veröffentlichten Kontakt und eine Disclosure-Richtlinie
Vorfälle	Selten	Jeder Vorfall endet in mindestens einem Schwachstelleneintrag

Der externe Kanal ist wichtiger als sein Volumen: Eine security.txt, eine Meldeadresse und eine Coordinated-Vulnerability-Disclosure-Richtlinie nach ISO/IEC 29147 machen aus dem Fund eines Forschers eine E-Mail statt eines Blogposts. Der CRA verlangt genau diese Richtlinie von Herstellern (Anhang I Teil II Nr. 5).

Schritt 3: Triage, nicht nur CVSS

CVSS sagt dir, wie schwer die Schwachstelle für sich genommen ist. Es sagt dir nicht, ob jemand sie ausnutzt oder ob deine Instanz erreichbar ist. Die Triage verbindet vier Eingaben:

1. CVSS-Basiswert für die technische Schwere.
2. Belege für Ausnutzung: Steht die CVE im KEV-Katalog der CISA, hat sie eine hohe EPSS-Wahrscheinlichkeit, gibt es einen öffentlichen Exploit?
3. Exposition: aus dem Internet erreichbar, aus dem Büronetz oder in einem isolierten Segment?
4. Kritikalität des Assets: Was läuft darauf, welche Daten liegen dort, was steuert es?

Eine praktische Regel: Alles, was im Feld ausgenutzt wird und aus dem Internet erreichbar ist, kommt unabhängig vom CVSS-Wert nach oben. Ein CVSS 9.8 auf einem isolierten Prüfstand rutscht nach unten. Schreib die Regel auf, damit zwei Leute zur selben Priorität kommen.

Schritt 4: SLAs nach Schwere

Eine Frist macht aus einer Liste einen Prozess. Die Zahlen unten sind ein verbreitetes Schema, keine gesetzliche Vorgabe; richtig sind die, die du messen und halten kannst.

Priorität nach Triage	Beheben oder entschärfen innerhalb von
Aktiv ausgenutzt und aus dem Internet erreichbar	48 Stunden
Kritisch	7 Tagen
Hoch	30 Tagen
Mittel	90 Tagen
Niedrig	Nächstes geplantes Release

“Entschärfen” zählt: Eine Firewall-Regel, eine abgeschaltete Funktion oder eine Konfigurationsänderung, die die Erreichbarkeit beseitigt, kann die Uhr anhalten, während der echte Fix durch die Tests geht. Der Eintrag bleibt offen, bis der Fix drin ist.

Schritt 5: Beheben, prüfen, kommunizieren

Den Fix setzt der Verantwortliche des Assets um, nicht das Security-Team. Das Security-Team prüft: erneut scannen, erneut testen oder bei Pentest-Findings ein Retest durch die Tester. Für Produkte wird der Fix zum Sicherheitsupdate, und der CRA verlangt, dass Updates sicher, unverzüglich und kostenlos verteilt werden, zusammen mit einem Advisory, das den Nutzern sagt, was behoben wurde (Anhang I Teil II Nr. 4, 7 und 8). In der eigenen IT ist die Kommunikation intern: Welche Systeme waren betroffen, was wurde getan, zeigten die Logs eine Ausnutzung.

Schritt 6: Messen

Drei Zahlen zeigen, ob der Prozess funktioniert: der Anteil der Findings, die innerhalb des SLA behoben wurden, die mittlere Behebungszeit je Schwere und die Zahl der Findings, die nach dem Schließen wiederkommen. Berichte sie monatlich an die Geschäftsleitung. Dieselben Zahlen sind die Nachweise, nach denen NIS2- und ISO-27001-Auditoren fragen.

Was der CRA für Hersteller hinzufügt

Für jedes Produkt mit digitalen Elementen, das in der EU verkauft wird, macht der Cyber Resilience Act (Verordnung (EU) 2024/2847) diesen Prozess zur Pflicht. Die Anforderungen an die Schwachstellenbehandlung in Anhang I Teil II lauten kurz gefasst: Schwachstellen und Komponenten identifizieren und dokumentieren, einschließlich SBOM; Schwachstellen unverzüglich beheben; die Sicherheit des Produkts regelmäßig testen; Informationen über behobene Schwachstellen veröffentlichen, sobald das Update verfügbar ist; eine Coordinated-Vulnerability-Disclosure-Richtlinie haben; einen Kontakt für Meldungen bereitstellen; Updates sicher verteilen; und Sicherheitspatches kostenlos mit Advisories bereitstellen.

Zwei weitere Regeln stehen in den Artikeln. Der Supportzeitraum, in dem Schwachstellen behandelt werden müssen, muss der erwarteten Nutzungsdauer des Produkts entsprechen und beträgt mindestens fünf Jahre, sofern das Produkt nicht erkennbar kürzer genutzt wird (Artikel 13 Absatz 8). Und eine aktiv ausgenutzte Schwachstelle muss über die zentrale Meldeplattform der ENISA gemeldet werden: Frühwarnung innerhalb von 24 Stunden nach Kenntnis, Meldung innerhalb von 72 Stunden, Abschlussbericht nach Verfügbarkeit des Fixes (Artikel 14). Die Meldepflichten gelten ab dem 11. September 2026. ISO/IEC 30111 beschreibt den internen Behandlungsprozess und ist eine gute Vorlage für die Dokumentation, die eine notifizierte Stelle oder die Marktüberwachung sehen will.

Woran es meist scheitert

• Kein Verantwortlicher. Findings, die “der IT” zugewiesen sind, sind niemandem zugewiesen.
• Schwere gleich CVSS. Teams ertrinken in Highs, die niemand ausnutzen kann, und übersehen das Medium, das gerade ausgenutzt wird.
• Die SBOM wird einmal erzeugt. Erzeuge sie mit jedem Build neu, sonst beschreibt sie ein Produkt, das es nicht mehr gibt.
• Ausnahmen ohne Ablauf. Eine Risikoakzeptanz braucht ein Datum und einen Namen.
• Kein Retest. “Gepatcht” und “behoben” sind verschiedene Zustände.

Wir helfen Herstellern, die Schwachstellenbehandlung für den CRA aufzubauen, von der SBOM-Pipeline über die Disclosure-Richtlinie bis zum 24-Stunden-Meldeverfahren, und wir testen das Ergebnis. Mehr unter Cyber Resilience Act, oder buch eine kostenlose CRA-Beratung.