Schwachstellenscan 2026: von CVE und CVSS 4.0 zu EPSS und CISA KEV

Scan, Pentest und Audit - drei verschiedene Fragen

Diese drei Leistungen werden häufig verwechselt, obwohl sie unterschiedliche Fragen beantworten und ihre Kosten sich um Größenordnungen unterscheiden. Ein Schwachstellenscan beantwortet die Frage, was in der Umgebung eine bekannte Schwachstelle ist. Das erledigt eine Maschine: Sie erkennt Softwareversionen und Konfigurationen und gleicht sie mit einer Schwachstellendatenbank ab. Sie ist günstig und schnell, kann also wöchentlich oder täglich laufen, sieht aber nur, was jemand bereits beschrieben hat, und erzeugt naturgemäß Fehlalarme.

Ein Penetrationstest beantwortet die Frage, was sich mit diesen Schwächen anfangen lässt. Er findet Dinge, die ein Scanner nie sieht: Fehler in der Geschäftslogik, Missbrauch von Funktionen, die genau wie vorgesehen arbeiten, und Ketten, in denen mehrere kleine Schwächen gemeinsam eine schwere Wirkung entfalten. Er kostet ein Vielfaches und wird deshalb ein- bis wenige Male im Jahr durchgeführt (siehe Artikel zu Penetrationstests). Ein Audit wiederum beantwortet eine Frage nach Prozessen und Konformität - ob Richtlinien existieren, ob sie angewandt werden und ob sich das belegen lässt (siehe Artikel zum IT-Sicherheitsaudit).

Keine der drei ersetzt die anderen. Ein täglich laufender Scanner sagt nicht, dass sich Rechte in einer Anwendung umgehen lassen; ein Pentest aus dem März sagt nichts über eine im September veröffentlichte Schwachstelle. Stellen, die dem polnischen Cybersicherheitsgesetz ^[17] oder der DORA-Verordnung ^[6] unterliegen, brauchen in der Praxis alle drei, in verschiedenen Zyklen.

Wie der Scanprozess aufgebaut ist

Ein reifer Prozess besteht aus vier zyklisch wiederholten Phasen, und die Scanphase ist darin nicht die schwierigste.

Er beginnt mit der Bestandsaufnahme. Der Scanner muss zunächst feststellen, was überhaupt im Netz ist, und der Abdeckungsgrad wiegt hier schwerer als die Güte der Maschine: Eine Schwachstelle auf einem Gerät, von dem niemand weiss, wird nicht gefunden, so gut der Scanner auch sein mag. Die typische Lücke sind Systeme, die ohne Wissen der IT betrieben werden - virtuelle Maschinen in der Cloud, von einem Dienstleister mitgebrachte Geräte, Testsysteme, die ohne Statuswechsel in den Produktivbetrieb gerutscht sind.

Die zweite Phase ist die Schwachstellenerkennung: Der Scanner erkennt Versionen und Konfigurationen und gleicht sie mit einer Datenbank ab ^[1]. Für Webanwendungen kommen eigene Werkzeuge zum Einsatz, die statt Versionen zu erkennen Anfragen senden, welche die typischen Angriffsklassen aus der OWASP-Zusammenstellung ^[7] nachbilden.

Die dritte Phase, die Validierung, wird am häufigsten übersprungen - und deshalb verlieren Schwachstellenprogramme ihre Glaubwürdigkeit. Scanner melden Lücken, die es im geprüften System gar nicht gibt, etwa wenn eine Linux-Distribution eine Korrektur eingespielt hat, ohne die von aussen sichtbare Versionsnummer zu ändern. Wenn solche Meldungen niemand aussortiert, nehmen die zuständigen Teams die Berichte nicht mehr ernst. Die vierte Phase ist die Priorisierung und Übergabe zur Umsetzung, weiter unten beschrieben.

Eine eigene Entscheidung ist der Scanmodus. Ein authentifizierter Scan, von einem Konto auf dem geprüften System aus, sieht die tatsächlichen Paketversionen, die Konfiguration und die Richtlinien und liefert daher weit weniger Fehlalarme; er verlangt aber die Verwaltung von Zugangsdaten, was selbst ein Risiko schafft. Ein nicht authentifizierter Scan zeigt, was ein Angreifer von aussen sieht - ungenauer, aber er bildet den realen Ausgangspunkt ab. Vernünftige Praxis ist, beides zu nutzen: das erste im Netz, das zweite aus dem Internet.

CVSS 4.0 - was sich geändert hat

CVSS ist eine Skala von 0 bis 10, die die Schwere einer Schwachstelle losgelöst von einer konkreten Umgebung beschreibt. Version 4.0 ^[2], im Juni 2023 von der Organisation FIRST veröffentlicht, brachte gegenüber Version 3.1 drei praktisch bedeutsame Änderungen.

Die erste ist die Aufteilung der früheren Scope-Metrik in zwei getrennte Wirkungsgruppen - für das verwundbare System und für Systeme, auf die die Schwachstelle darüber hinaus wirkt. Die Konstruktion aus 3.1 wurde verbreitet uneinheitlich angewandt, weil ein Wert zwei verschiedene Dinge beschreiben musste; die Trennung erleichtert die Bewertung und bildet Fälle besser ab, in denen eine Lücke in einem Bauteil den Weg in den Rest der Umgebung öffnet.

Die zweite ist eine eigene Gruppe von Bedrohungsmetriken, in der die Reife des Ausnutzungscodes am wichtigsten ist. Der Wert ist damit nicht mehr rein theoretisch - ist ein funktionierendes Werkzeug öffentlich verfügbar, soll die Bewertung das abbilden. Das ist ein Schritt in dieselbe Richtung wie EPSS und KEV, allerdings auf qualitativer Einschätzung statt auf einem statistischen Modell.

Die dritte ist eine Gruppe ergänzender Metriken, die den Zahlenwert nicht verändern, aber entscheidungsrelevante Informationen tragen: unter anderem die Wirkung auf die Sicherheit von Menschen, die Automatisierbarkeit des Angriffs und den Aufwand für die Behebung. Diese letzte Gruppe ist besonders in industriellen Umgebungen nützlich, wo die Folge einer Störung eine physische Gefahr sein kann und nicht ein Datenverlust.

Der praktische Schluss ist zurückhaltend: Werte aus beiden Versionen sollten nicht unmittelbar verglichen werden, weil sie aus unterschiedlichen Modellen stammen. CVSS bleibt zudem in jeder Version ein Maß für Schwere, nicht für Risiko - über das Risiko entscheidet erst, wo die Schwachstelle sitzt und ob jemand sie auszunutzen versucht.

EPSS und KEV - von der Schwere zur Wahrscheinlichkeit

Das Grundproblem einer Priorisierung allein nach CVSS ist, dass hunderttausende Schwachstellen öffentlich beschrieben sind und nur ein kleiner Teil davon je in Angriffen auftaucht. Wer nach Schwere patcht, verbringt die meiste Zeit mit Lücken, nach denen niemand greifen wird, und hat keine für die wenigen, die aktiv genutzt werden.

Die Antwort darauf ist EPSS ^[3] - ein Modell, das täglich für jede Schwachstelle eine Schätzung veröffentlicht, mit welcher Wahrscheinlichkeit sie in den nächsten 30 Tagen ausgenutzt wird. Der Wert liegt zwischen null und eins und ändert sich, anders als CVSS, im Zeitverlauf mit neuen Beobachtungen. Es ist jedoch eine statistische Prognose und keine Tatsachenfeststellung: Ein hoher Wert bedeutet nicht, dass ein Angriff erfolgt, ein niedriger garantiert nicht, dass keiner erfolgt.

Ergänzend kommt der KEV-Katalog ^[4] hinzu, in dem CISA Schwachstellen führt, deren Ausnutzung in realen Angriffen bestätigt ist - am 24. August 2026 waren es 1675 Positionen. Für US-Bundesstellen löst ein Eintrag eine Behebungsfrist aus; außerhalb dieses Kreises begründet der Katalog keine Pflicht, ist aber die beste öffentlich verfügbare Liste dessen, was Angreifer tatsächlich tun. Er hat eine Einschränkung, die man mitdenken muss: Er erfasst von einer US-Behörde bestätigte Fälle, sodass nur in Europa beobachtete Kampagnen darin fehlen können. Regionale Quellen sind eine sinnvolle Ergänzung ^{[12] [13]}.

Aus der Verbindung der drei Signale ergibt sich eine Regel in wenigen Sätzen. Höchste Priorität, mit einer in Tagen gemessenen Frist, haben Schwachstellen aus dem KEV-Katalog - unabhängig von ihrem CVSS-Wert, denn sie werden jetzt genutzt. Die nächste Stufe umfasst Lücken sehr hoher Schwere oder mit hoher EPSS-Schätzung, besonders auf aus dem Internet erreichbaren Systemen. Der Rest geht in den gewöhnlichen Prüfzyklus. Die Fristen in jeder dieser Gruppen sollten aus einer Entscheidung der Organisation folgen und in einer Richtlinie festgehalten sein statt bei jedem Fund neu ausgehandelt zu werden; die Methodik dafür beschreibt NIST SP 800-40 Rev. 4 ^[15].

Dass diese Reihenfolge stimmt, zeigen die Daten zu Erstzugangsvektoren. Im DBIR 2024 ^[8] entfielen 14 Prozent der Vorfälle auf die Ausnutzung einer Schwachstelle, ein Anstieg um 180 Prozent gegenüber dem Vorjahr. Im DBIR 2026 ^[18] waren es 31 Prozent, und erstmals in der Geschichte des Berichts lag dieser Vektor vor dem Missbrauch von Zugangsdaten. Schwachstellenmanagement ist keine Nebenaufgabe mehr.

Die häufigsten Fehler

Der häufigste Fehler ist, einmal im Jahr vor dem Audit zu scannen. Neue Schwachstellen erscheinen täglich, und da ihre Ausnutzung heute der häufigste Erstzugangsvektor ist ^[18], beschreibt ein elf Monate alter Bericht eine andere Umgebung als die tatsächlich laufende. Ein Jahresscan dokumentiert die Erfüllung einer Pflicht, senkt aber kein Risiko.

Der zweite ist fehlende Zuständigkeit. In größeren Umgebungen erzeugt ein Scanner Zehntausende Beobachtungen, und ohne Verbindung jeder einzelnen mit einem Team, einer Frist und einem Status bleibt die Liste eine Liste. Die praktische Lösung ist die Anbindung des Scanners an das Ticketsystem, damit eine Position hoher Priorität zu einer Aufgabe mit Verantwortlichem wird und nicht zu einer Zeile im Bericht.

Der dritte ist das Fehlen eines Ausnahmeverfahrens. Manche Korrekturen lassen sich in vertretbarer Zeit nicht umsetzen - kein Wartungsfenster, Anwendungsabhängigkeiten oder ein Gerät, das der Hersteller nicht mehr unterstützt. Gibt es keinen formalen Weg, eine Ausnahme samt Ersatzmaßnahme und Termin zur erneuten Bewertung zu genehmigen, werden die Korrekturen schlicht nicht eingespielt, und niemand hält das fest.

Der vierte ist die Verengung des Umfangs auf Server. Arbeitsplätze, Netzgeräte, Drucker, Kameras und Randtechnik haben genauso Schwachstellen, und Randgeräte - Firewalls und VPN-Konzentratoren - gehören heute zu den häufiger ausgenutzten Zielen, weil sie aus dem Internet erreichbar und selten aktualisiert sind.

Der fünfte und grundlegendste ist die Gleichsetzung von Schwachstelle und Risiko. Dieselbe Lücke mit demselben Wert bedeutet auf einer Testmaschine ohne Daten etwas anderes als auf einem Dateiserver mit personenbezogenen Daten. Ohne Klassifizierung der Systeme stützt sich die Priorisierung allein auf eine Zahl aus einer Datenbank und lässt damit genau die Information aus, die in der Organisation einzigartig ist.

Die rechtlichen Grundlagen

Schwachstellenscans werden in Vorschriften selten ausdrücklich genannt, doch mehrere verlangen ein Ergebnis, das ohne sie nicht zu erreichen ist. Am konkretesten ist in Polen das Cybersicherheitsgesetz ^[17]. Sein Artikel 8 Absatz 1 Nummer 3 verpflichtet wesentliche und wichtige Einrichtungen, Informationen über Cyberbedrohungen und Schwachstellen des zur Diensterbringung genutzten Informationssystems zu sammeln, und Nummer 5 Buchstaben b und d verlangen regelmäßige Softwareaktualisierungen unter Beachtung der Kritikalität einzelner Korrekturen sowie unverzügliches Handeln nach Feststellung einer Schwachstelle. Gesondert nennt Artikel 8 Absatz 1 Nummer 2 Buchstabe b das Testen des Informationssystems unter den Maßnahmen zu Beschaffung, Entwicklung und Wartung, Buchstabe h Richtlinien und Verfahren zur Bewertung der Wirksamkeit der ergriffenen Maßnahmen. Das ist die härteste Grundlage, die dieser Prozess im polnischen Recht hat; ihre Quelle ist Artikel 21 Absatz 2 der NIS2-Richtlinie ^[5].

Im öffentlichen Sektor ist die KRI-Verordnung ^[11] eine eigenständige Grundlage; ihr § 19 Absatz 2 Nummer 12 nennt unter den Bestandteilen der Sicherheit von IT-Systemen sowohl die Sorge um Softwareaktualisierungen als auch die Verringerung der Risiken aus veröffentlichten Schwachstellen sowie unverzügliches Handeln bei noch nicht offengelegten Schwachstellen. Die Anforderung ist hier ausdrücklich formuliert, wenn auch ohne Angabe einer Häufigkeit.

Im Finanzsektor verlangt die DORA-Verordnung ^[6], anwendbar seit dem 17. Januar 2025, die fortlaufende Identifizierung von Quellen des IKT-Risikos, Schwachstellen eingeschlossen. Die DSGVO ^[9] geht allgemeiner vor: Artikel 32 Absatz 1 Buchstabe d verlangt ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit technischer und organisatorischer Maßnahmen, und die Tätigkeitsberichte der polnischen Aufsichtsbehörde ^[10] zeigen, dass bei der Bewertung von Verletzungen berücksichtigt wird, ob der Verantwortliche die Wirksamkeit seiner Schutzmaßnahmen überhaupt geprüft hat. Außerhalb des Unionsrechts stellt die Kartenbranche eigene, präzise Anforderungen: PCI DSS in der Version 4.0 sieht vierteljährliche externe Scans durch einen zugelassenen Dienstleister vor.

Wohin das führt

Die erste Richtung ist die risikobasierte Priorisierung, die Schweregrad, Ausnutzungsprognose, bestätigte Verwendungsfälle und den Kontext des Systems - Klassifizierung, Erreichbarkeit aus dem Internet, Art der verarbeiteten Daten - zu einem einzigen Ranking verbindet. Das ist keine neue Technologie, sondern die konsequente Nutzung bereits verfügbarer Signale; die Schwierigkeit liegt darin, dass der Kontext des Systems aus der Organisation selbst kommen muss.

Die zweite ist die Softwarestückliste, bekannt als SBOM. Nach Vorfällen mit Bibliotheken, die in tausenden Produkten stecken, wurde klar, dass die Frage "nutzen wir diese Komponente" schnell zu beantworten sein muss. In der Union verstärkt die Verordnung über die Cyberresilienz von Produkten mit digitalen Elementen diese Richtung, indem sie Herstellern Pflichten auferlegt und einen Teil der Arbeit vom Anwender zum Lieferanten verschiebt.

Die dritte ist der Übergang vom periodischen Scannen zur fortlaufenden Bewertung der Exposition, in der der Schwachstellenscan ein Signal unter vielen ist, neben der Kartierung der Angriffsfläche und der Simulation von Angreifertechniken. Das ist eher eine Änderung der Arbeitsorganisation als eine neue Werkzeugkategorie, und ihr Wert hängt davon ab, ob die Organisation auf diese Signale reagieren kann - sonst erhöht sie nur die Zahl der Tickets.

Fragen an das eigene Programm

Die Reife eines Schwachstellenprogramms lässt sich mit einigen Fragen prüfen, deren Antworten ohne Vorbereitung bekannt sein sollten.

Die erste betrifft den Umfang: Gibt es ein belastbares Systemverzeichnis, und welcher Anteil der Umgebung ist tatsächlich erfasst, aufgeschlüsselt nach Netzsegmenten, Cloud-Umgebungen, Industrienetzen und der demilitarisierten Zone. Die zweite betrifft die Häufigkeit und sollte den authentifizierten Scan im Netz vom externen Scan unterscheiden, der bei aus dem Internet erreichbaren Systemen täglich sinnvoll ist.

Die dritte betrifft die Priorisierung: Fließen neben dem Schweregrad auch Ausnutzungsprognose und Katalog bestätigter Fälle ein, und geht die Klassifizierung des Systems in das Ranking ein. Die vierte betrifft Fristen: Ist für jede Kategorie eine Behebungsfrist bestimmt, und hat jede Position einen Verantwortlichen. Die fünfte betrifft die Durchsetzung: Gelangen die Beobachtungen in das Ticketsystem, denn ohne das lassen sie sich nicht nachhalten. Die sechste betrifft Ausnahmen: Gibt es einen formalen Weg für Fälle, in denen eine Korrektur nicht umsetzbar ist, samt Ersatzmaßnahme und Datum der erneuten Bewertung.

Die letzten drei Fragen betreffen die am häufigsten übersehenen Bereiche. Werden Containerabbilder vor der Inbetriebnahme geprüft und nicht erst laufende Systeme? Gibt es für gelieferte und eingesetzte Software eine Stückliste der Komponenten? Und schließlich: Wird das Programm gemessen - an der mittleren Behebungszeit der höchstpriorisierten Funde, an der Zahl überfälliger Positionen und am Trend beider Größen. Ohne diesen letzten Punkt lässt sich nicht sagen, ob das Programm besser wird oder nur weiterläuft.