Der Befund brauchteine Einordnung.
Eine CVE Nummer sagt nicht, ob Ihr Unternehmen handeln muss. Der Prozess verbindet Meldungen aus Scannern, Herstellern, CERTs, Tests, SBOM und VEX mit dem eigenen Bestand. Sein Ergebnis ist eine begründete Betroffenheit mit Owner, Frist und Behandlung. Erst danach beginnt der technische Eingriff.
Relevanz vor
Aktivität.
Die Zahl der Meldungen ist kein Steuerungsinstrument. Entscheidend ist, ob ein eigenes Objekt oder Produkt betroffen ist, welche Ausnutzung realistisch ist, welche Wirkung eintreten kann und wer die Behandlung verantwortet.
Erfassen
Scanner, Hersteller, CERTs, Tests, SBOM, VEX und interne Meldungen mit Quelle und Zeitpunkt aufnehmen.
nachvollziehbarer Befund
Zuordnen
Produkt, Version, Instanz, Asset Owner und betroffene Leistung gegen das Inventar prüfen.
eigene Betroffenheit
Bewerten
Exposition, Ausnutzbarkeit, Kritikalität, vorhandene Schutzwirkung und Bedrohungslage einordnen.
begründete Priorität
Entscheiden
Patch, Konfigurationsänderung, Kompensation, Lieferanteneinbindung oder Risikoentscheidung festlegen.
Owner und Frist
Beauftragen
Entscheidung über Risiko und Änderungen an Betrieb, Entwicklung oder Lieferanten übergeben.
steuerbare Umsetzung
Verfolgen
Status, Frist, Ausnahme und Wirksamkeitsnachweis bis zum Abschluss nachhalten.
nachvollziehbarer Stand
Schwere ist nur
ein Merkmal.
CVSS, EPSS, KEV, SBOM und VEX beantworten unterschiedliche Fragen. Der Prozess verbindet sie, ohne aus einem einzelnen Wert eine automatische Handlungsanweisung abzuleiten.
| Information | Sie hilft zu klären | Sie entscheidet nicht allein |
|---|---|---|
| CVE und Herstellerhinweis | Welche Schwachstelle und Produktversion betroffen sein können. | Ob eine eigene Instanz betrieben wird und wie dringend sie behandelt werden muss. |
| CVSS | Technische Schwere nach einem standardisierten Vektor. | Geschäftswirkung, Exposition, bereits vorhandene Kontrollen und Priorität im eigenen Kontext. |
| EPSS und KEV | Wahrscheinlichkeit oder bestätigte aktive Ausnutzung als Zusatzsignal. | Ob ein eigener Angriffspfad besteht und welche konkrete Behandlung angemessen ist. |
| SBOM und VEX | Komponenten eines Releases und gemeldeter Betroffenheitsstatus. | Ob die betreffende Version betrieben wird und ob der technische Zustand korrigiert ist. |
| Inventar und Exposure | Owner, Kritikalität, Erreichbarkeit, Nutzung und technische Beziehungen. | Patchfenster, Changefreigabe oder die unabhängige Wirksamkeitsprüfung. |
Ein Befund bewegt
mehrere Teams.
Die klare Grenze verhindert zwei typische Fehler: Security wird nicht zur Patch Factory und der IT Betrieb muss keine Risikobewertung aus einer Scannerliste erraten.
Entscheidet
Betroffenheit, Priorität, Behandlung, Owner, Frist und nachvollziehbare Ausnahme.
Akzeptiert
Rest und Ausnahmerisiken, wenn die Behandlung nicht zeitgerecht oder vollständig möglich ist.
Kontrolliert
Freigabe, Auswirkung, Test, Terminierung und Rückfalloption des Eingriffs.
Vollzieht
Beschaffung, Test, Installation und betriebliche Rückmeldung zum geänderten Zustand.
Korrigiert
Eigene Software, Komponenten, sichere Releases und produktbezogene Nachweise.
Prüft
Unabhängig, ob die beabsichtigte Wirkung für den definierten Umfang erreicht wurde.
Offene Befunde
bleiben sichtbar.
Ein realistisches Ziel ist nicht eine leere Liste. Gute Steuerung zeigt, welche Betroffenheiten bestätigt sind, welche Behandlung aussteht und welche begründeten Ausnahmen bis wann gelten.
Steuerungsgrössen
Relevante Messgrössen sind bestätigte Betroffenheiten ohne Owner, überfällige Behandlungen, Ausnahmen ohne Ablaufdatum, nicht erreichbare Assets, nicht mehr unterstützte Produkte und fehlende Wirksamkeitsnachweise.
ISO, NIST und CIS
ISO/IEC 27001:2022 verweist auf Threat Intelligence und das Management technischer Schwachstellen. NIST CSF 2.0 und CIS Control 7 geben Ergebnis und Safeguard Rahmen. Keine Quelle schreibt eine einzelne Scannerplattform vor.
Regulierung
NIS2 und deutsches BSIG betreffen erfasste Einrichtungen. DORA gilt für erfasste Finanzunternehmen. Der CRA ist produkt und rollenbezogen. Die konkrete Pflicht wird im Prozess Compliance geklärt.
Die Prozessgrenze wurde gegen ISO/IEC 27001:2022, NIST SP 800-40 Rev. 4 und CIS Controls v8.1 eingeordnet. Für Produkte mit digitalen Elementen kann der CRA weitere produktbezogene Pflichten auslösen.
Der Befund wird
verantwortet.
Eine qualifizierte Schwachstelle verbindet technische Fakten mit einer klaren Behandlung. Damit entsteht weder ein Ticket für Dummies noch eine abstrakte Priorität, sondern ein nachverfolgbarer Entscheid mit Übergabe an die richtige Stelle.
| Entscheidungsfeld | Nachweis im Befund | Folgeauftrag |
|---|---|---|
| Betroffenheit | Produkt, Version, Instanz, Asset Owner und relevante Geschäftsleistung sind abgeglichen. | Unklare oder fehlende Bestandsdaten gehen an Inventar und den zuständigen Owner zurück. |
| Priorität | Exposition, Ausnutzbarkeit, Bedrohungslage, Kritikalität und vorhandene Kontrollen sind begründet. | Die Reihenfolge der Behandlung und die notwendige Frist werden mit Risiko und Betrieb abgestimmt. |
| Behandlung | Patch, Konfiguration, Kompensation, Lieferantenauftrag oder Risikoakzeptanz sind ausdrücklich gewählt. | Änderungen und Patching planen den technischen Eingriff, Entwicklung oder Lieferant bearbeiten ihren Anteil. |
| Abschluss | Status, Ausnahme, Fristverlängerung und erwarteter Wirksamkeitsnachweis sind sichtbar. | Wirksamkeit prüft den vereinbarten Umfang, offene Restlücken bleiben bei Risiko und Steuerung sichtbar. |
Der Befund wird
entscheidbar.
Die Bewertung trennt technische Fakten, eigene Betroffenheit und Behandlungsentscheidung. Referenzen strukturieren die Aufgabe, Folgeprozesse und Werkzeuge unterstützen die jeweiligen Übergaben.
| Referenz | Beitrag zum Prozess | Grenze |
|---|---|---|
| ISO/IEC 27001:2022 | A.8.8 verlangt die Behandlung technischer Schwachstellen auf Basis relevanter Informationen. | Schreibt weder feste Fristen noch eine bestimmte Scannerplattform vor. |
| NIST SP 800-40 Rev. 4 | Beschreibt Enterprise Patch Management als risikobasierten, organisationsweiten Prozess. | Die Patchinstallation bleibt ein nachgelagerter Betriebsprozess. |
| CRA | Kann für Produkte mit digitalen Elementen produktbezogene Schwachstellen- und Supportpflichten auslösen. | Gilt nur innerhalb des produkt- und akteursbezogenen Anwendungsbereichs. |
| Inhalt | Beitrag | Weiter |
|---|---|---|
| 05 Inventar | Liefert Versionen, Owner und den technischen Kontext für die Betroffenheitsprüfung. | Prozess öffnen → |
| 02 Risiko | Überführt akzeptierte Abweichungen in eine verantwortete Entscheidung mit Review. | Prozess öffnen → |
| Patchsteuerung DCH | Plant, prüft und dokumentiert die technische Änderung bis zum Wirksamkeitsnachweis. | Prozess öffnen → |
Security Tool Navigator · Werkzeuge zum Prozess
Werkzeuge nach Gebiet einordnen.
Die Werkzeugklassen dieses Prozesses sind im Security Tool Navigator nach Sicherheitsgebieten geordnet. Die Gebietsseiten zeigen Abgrenzung, Auswahlfragen für CIO und CISO und alle Werkzeugklassen im Zusammenhang.