Schwachstellenmanagement

Das Schwachstellenmanagement ist der Ort, an dem Cert-IX die von Ihren Scans erzeugten Befunde zu einer einzigen, priorisierten Arbeitsliste zusammenführt. Jeder Befund ist mit einer bekannten Schwachstelle verknüpft — typischerweise über eine CVE identifiziert —, nach Schweregrad bewertet, mit Signalen zur tatsächlichen Ausnutzung angereichert und von der ersten Erkennung bis zu einer verifizierten Behebung nachverfolgt. Das Ziel ist einfach: Ihrem Team dabei zu helfen, seine Anstrengungen auf die Schwachstellen zu richten, die Sie tatsächlich gefährden, und zwar in der richtigen Reihenfolge.

Diese Seite erklärt, woher Befunde stammen, wie sie priorisiert werden und wie sie ihren Lebenszyklus durchlaufen.

Woher Befunde stammen

Das Schwachstellenmanagement scannt nicht selbst — es aggregiert Ergebnisse von den Scan-Oberflächen, die Cert-IX bereits bereitstellt. Eine einzige Ansicht kann daher mehrere sich ergänzende Quellen widerspiegeln:

Quelle	Was sie beiträgt	Am besten geeignet für
Scan-API-Engines	On-Demand- und API-gesteuerte Scans (zum Beispiel Trivy, Nuclei, Nikto und OWASP ZAP), die CVEs in Images, Abhängigkeiten und web-zugewandten Diensten aufdecken	Externe und CI-gesteuerte Prüfungen
Bitscanner-Agent	Kontinuierliche Schwachstellen- und CVE-Erkennung in internen Netzwerken und auf Hosts	Assets hinter der Firewall
DepCheck (MCP)	Prüfung von Abhängigkeiten auf Schwachstellen für Codebasen und KI-Coding-Agenten, gestützt auf dieselben Advisory-Daten	Software-Lieferkette

Erfassen von Befunden aus internen Netzwerken

Befunde von Hosts hinter Ihrer Firewall erfordern einen Scanner-Agenten. Laden Sie Bitscanner von downloads.cert-ix.com herunter und registrieren Sie ihn mit Ihrer Tenant-ID (zu finden unter Einstellungen → Organisation). Siehe Scanner-Agenten für die Bereitstellungsschritte.

Schweregrad und Priorisierung

Jeder Befund trägt eine Schweregrad-Einstufung, die aus seinem CVSS-Score abgeleitet wird, unter Verwendung der vier Standardbänder:

Schweregrad	CVSS-Bereich	Was er üblicherweise bedeutet
Critical	9.0–10.0	Schwerwiegende Exposition, oft Remote-Codeausführung oder vollständige Kompromittierung. Dringend beheben.
High	7.0–8.9	Erhebliches Risiko. Zeitnah priorisieren.
Medium	4.0–6.9	Moderates Risiko. Behebung einplanen.
Low	0.1–3.9	Geringes Risiko. Beheben, sobald Kapazität verfügbar ist.

Der Schweregrad allein reicht nicht aus, um zu entscheiden, was zuerst behoben werden soll: Ein Medium-Problem, das heute ausgenutzt wird, rangiert oft vor einem High, das es nicht ist. Cert-IX legt Signale zur tatsächlichen Ausnutzung über den reinen CVSS-Score:

• CISA KEV — ob die Schwachstelle im Katalog der bekannten ausgenutzten Schwachstellen (Known Exploited Vulnerabilities) der CISA erscheint, d. h. aktive, bestätigte Ausnutzung.
• EPSS — die vom Exploit Prediction Scoring System berechnete Wahrscheinlichkeit, dass eine Schwachstelle in naher Zukunft ausgenutzt wird.
• Exposition — ob das betroffene Asset internetzugewandt oder aus nicht vertrauenswürdigen Netzwerken erreichbar ist.
• Asset-Kritikalität — wie wichtig das betroffene System für Ihren Betrieb ist.

Beheben Sie zuerst, was ausgenutzt wird

Ein Befund, der im CISA-KEV-Katalog markiert ist oder einen hohen EPSS-Score trägt, verdient Aufmerksamkeit vor einem Problem mit höherem CVSS-Wert, für das es keine Anzeichen einer Ausnutzung gibt. In freier Wildbahn ausgenutzte Schwachstellen sind diejenigen, die Angreifer gerade jetzt verwenden.

Der Schwachstellen-Lebenszyklus

Befunde durchlaufen eine definierte Reihe von Zuständen, sodass jeder einzelne stets einen klaren aktuellen Status und einen klaren nächsten Schritt hat:

1. Identifiziert — ein Scan hat die Schwachstelle erkannt.
2. Bestätigt — sie wurde als echtes Problem und nicht als False Positive validiert.
3. Zugewiesen — eine verantwortliche Person ist für die Behebung zuständig.
4. In Bearbeitung — eine Behebung ist im Gange.
5. Verifizierung ausstehend — die Behebung wurde angewendet und wartet auf einen erneuten Scan.
6. Behoben — ein Folge-Scan bestätigt, dass die Schwachstelle verschwunden ist.

Ein Befund kann auch als Risiko akzeptiert markiert werden, wenn eine Behebung nicht machbar ist und stattdessen das Restrisiko dokumentiert und verantwortet wird.

Arbeiten mit einem Befund

Das Öffnen eines Befunds bringt alles zusammen, was zum Triagieren und Handeln nötig ist:

• CVE-ID — die Kennung aus dem Common-Vulnerabilities-and-Exposures-Verzeichnis.
• Schweregrad / CVSS — der Score und sein Band.
• Ausnutzung — CISA-KEV- und EPSS-Indikatoren.
• Betroffene Assets — die Systeme, auf denen die Schwachstelle erkannt wurde.
• Beschreibung — worin die Schwäche besteht und welche potenziellen Auswirkungen sie hat.
• Behebung — empfohlene Anleitung zu ihrer Beseitigung.
• Status & Verlauf — der aktuelle Lebenszyklus-Zustand und eine Zeitleiste der Änderungen.

Beispielbefund

Die folgenden Felder veranschaulichen, wie sich ein Befund nach der Erfassung liest. Die Werte stammen von einer realen, öffentlich dokumentierten Schwachstelle, die rein als Beispiel gezeigt wird:

Feld	Wert
CVE-ID	CVE-2021-44228 ("Log4Shell")
Schweregrad	Critical (CVSS 10.0)
Ausnutzung	Im CISA-KEV-Katalog gelistet; hoher EPSS
Betroffenes Asset	Dienst, der Apache Log4j 2.x bündelt
Beschreibung	Nicht authentifizierte Remote-Codeausführung über JNDI-Lookups in protokollierten Zeichenketten
Behebung	Log4j auf ein behobenes Release aktualisieren (2.17.1 oder neuer)
Status	Bestätigt → In Bearbeitung

Filtern und Fokussieren

Große Umgebungen erzeugen viele Befunde, daher lässt sich die Liste auf den Ausschnitt eingrenzen, der Sie interessiert — zum Beispiel nach Schweregrad, Lebenszyklus-Status, betroffenem Asset oder betroffener Asset-Gruppe, Ausnutzungsstatus (KEV / EPSS) oder Erkennungsdatum. Ein gefiltertes Set kann exportiert werden, um es zu teilen oder um Tickets in Ihren eigenen Tools anzulegen.

Behebung

Für jeden Befund stellt Cert-IX der Schwachstelle eine Behebungsanleitung zur Seite. Die richtige Reaktion hängt vom Problem ab:

Option	Wann sie zu verwenden ist
Patchen	Den Sicherheitsfix des Herstellers anwenden
Aktualisieren	Auf eine neuere, nicht betroffene Version umsteigen
Konfigurieren	Einstellungen ändern, um die Exposition zu beseitigen
Mitigieren	Eine ausgleichende Kontrolle anwenden, wenn noch keine Behebung verfügbar ist
Akzeptieren	Das Restrisiko dokumentieren und formell akzeptieren

Führen Sie nach der Behebung einen Verifizierungsscan gegen das betroffene Asset durch. Wenn der Folge-Scan die Schwachstelle nicht mehr meldet, wechselt der Befund zu Behoben — womit sich der Kreis zwischen Erkennung und Behebung schließt.

Behebungsziele festlegen

Viele Teams weisen jedem Schweregrad ein Ziel-Behebungsfenster zu, damit nichts Ernsthaftes liegen bleibt. Gängige Ausgangspunkte sind:

Schweregrad	Typisches Ziel
Critical	1–2 Tage
High	~1 Woche
Medium	~30 Tage
Low	~90 Tage

hinweis

Diese Fenster sind veranschaulichende Beispiele, die Teams üblicherweise übernehmen — keine festen Plattform-Garantien. Wählen Sie Ziele, die zu Ihrer eigenen Risikotoleranz und Ihren regulatorischen Verpflichtungen passen.

Best Practices

• Kontinuierlich scannen. Halten Sie Scanner-Agenten bereitgestellt und führen Sie Scans regelmäßig durch, damit neue Schwachstellen schnell zum Vorschein kommen.
• Nach Ausnutzung priorisieren, nicht nur nach Schweregrad. Räumen Sie KEV-gelistete und Befunde mit hohem EPSS vor höher bewerteten Problemen ohne Anzeichen einer Ausnutzung ab.
• Immer verifizieren. Scannen Sie nach der Behebung erneut, bevor Sie einen Befund auf Behoben setzen.
• Akzeptiertes Risiko verantworten. Wenn Sie ein Risiko akzeptieren, halten Sie fest, wer es verantwortet und warum, und überprüfen Sie es regelmäßig erneut.

Mehr erfahren

• Analytics-Übersicht — wie sich das Schwachstellenmanagement neben den anderen Analytics-Ansichten einfügt.
• Scanner-Agenten — Bitscanner für die Schwachstellenerkennung in internen Netzwerken bereitstellen.
• Scan-API-Übersicht — On-Demand-Scans ausführen und Befunde programmatisch abrufen.
• DepCheck (MCP) — Prüfung von Abhängigkeiten auf Schwachstellen für Codebasen und KI-Coding-Agenten.