Eine Nummer ist noch kein Risiko.

Was eine CVE eigentlich ist

CVE steht für Common Vulnerabilities and Exposures. Eine CVE-Nummer wie CVE-2026-12345 ist eine Kennung, sonst nichts: Sie sagt, dass eine Schwachstelle gemeldet und katalogisiert wurde. Sie sagt nichts darüber, ob das Produkt bei Ihnen läuft, ob es erreichbar ist, ob es ausgenutzt wird und was passiert, wenn es ausgenutzt wird.

Genau hier scheitern die meisten Schwachstellenprozesse. Sie erzeugen Listen statt Entscheidungen. Eine Liste mit 4.000 offenen Findings ist kein Nachweis für ein funktionierendes Schwachstellenmanagement — sie ist der Nachweis, dass keines existiert.

Die vier Größen, die zusammen erst eine Aussage ergeben

1. 1
   CVSS — wie schlimm wäre esDer Wert von 0 bis 10 beschreibt die technische Schwere unter Laborbedingungen. Er ist unabhängig von Ihrer Umgebung und bleibt über Jahre gleich. Als alleiniges Priorisierungskriterium taugt er nicht: Es gibt weit mehr Schwachstellen mit CVSS 9 als Kapazität, sie alle sofort zu schließen.
2. 2
   EPSS — wie wahrscheinlich ist esDas Exploit Prediction Scoring System schätzt die Wahrscheinlichkeit, dass eine Schwachstelle in den nächsten 30 Tagen tatsächlich ausgenutzt wird. Der Wert ändert sich täglich. Die große Mehrheit aller CVE wird nie ausgenutzt — EPSS macht die kleine Minderheit sichtbar.
3. 3
   KEV — wird es bereits ausgenutztDer Katalog bekannter ausgenutzter Schwachstellen listet auf, was nachweislich in freier Wildbahn angegriffen wird. Wenn eine Schwachstelle dort steht und bei Ihnen läuft, ist die Diskussion über Priorisierung beendet.
4. 4
   Ihre Umgebung — betrifft es Sie überhauptDie Größe, die kein externer Dienst kennt: Läuft das Produkt bei Ihnen, in welcher Version, von außen erreichbar oder im internen Netz, mit welchen Daten dahinter. Ohne ein Verzeichnis Ihrer Systeme ist jede Schwachstellenbewertung geraten.

Was die Regelwerke verlangen

Schwachstellenmanagement steht in jedem der großen Regelwerke — mit unterschiedlicher Schärfe und unterschiedlichem Nachweis.

• ISO/IEC 27001:2022, Anhang A 8.8 — Informationen über technische Schwachstellen der genutzten Systeme müssen beschafft, die Gefährdung bewertet und geeignete Maßnahmen ergriffen werden. Der Nachweis ist der dokumentierte Entscheidungsweg, nicht die Scanliste.
• NIS2 / § 30 BSIG, Maßnahme 5 — Sicherheit bei Erwerb, Entwicklung und Wartung, ausdrücklich einschließlich Management und Offenlegung von Schwachstellen. Gefordert ist ein Verfahren, kein Werkzeug.
• DORA, IKT-Risikomanagement — Erkennung anomaler Aktivitäten und Schwachstellen, dazu ein Testprogramm, das Schwachstellenbewertungen und Scans einschließt.
• § 75b SGB V, Anlagen 1 bis 5 — Aktualität von Betriebssystemen und Anwendungen sowie das Einspielen von Sicherheitsaktualisierungen, abgestuft nach Praxisgröße.

Ein Verfahren, das im Audit trägt

Vier Schritte, die zusammen den Nachweis ergeben, den ein Prüfer sehen will.

1. 1
   Wissen, was Sie betreibenEin gepflegtes Verzeichnis von Systemen, Versionen und Verantwortlichen. Ohne das ist alles Weitere Beschäftigungstherapie. Der Auditor fragt zuerst danach.
2. 2
   Quellen abonnieren statt suchenMeldungen zu genau den Produkten, die Sie einsetzen — nicht der komplette Strom aller Veröffentlichungen. Wer alles liest, liest nichts.
3. 3
   Bewerten mit Frist, nicht mit GefühlLegen Sie vorab fest, welche Kombination aus Schwere, Ausnutzbarkeit und Erreichbarkeit welche Frist auslöst. Diese Festlegung ist selbst ein Nachweis — und sie schützt Sie, wenn die Frist einmal reißt.
4. 4
   Ausnahmen begründen und befristenWas nicht geschlossen wird, braucht eine Begründung, eine kompensierende Maßnahme und ein Wiedervorlagedatum. Eine unbefristete Ausnahme ist im Audit eine Abweichung.

Schwachstellenmeldungen

Wir verfolgen die Meldungen ohnehin und ordnen sie ein: was davon relevant ist, wen es betrifft und was zu tun ist. Sagen Sie uns Bescheid, wenn Sie diese Einordnung erhalten möchten. Der Katalog selbst ist über cvedetails.com öffentlich einsehbar.