Schwachstellenscans im Jahr 2026: von CVSS 4.0 über EPSS und CISA KEV bis zum Exposure Management

Schwachstellenscan, Penetrationstest und Audit beantworten unterschiedliche Fragen

Ein Schwachstellenscan beantwortet in erster Linie die Frage: Welche bekannten technischen Schwächen lassen sich im vereinbarten Umfang mit bestimmten Tests und Datenquellen erkennen? Er bietet eine breite, wiederholbare Abdeckung und eignet sich für regelmäßige Prüfungen, seine Ergebnisse müssen jedoch validiert werden.

Ein Penetrationstest beantwortet eine andere Frage: Lässt sich eine Schwäche in einem vereinbarten Szenario tatsächlich ausnutzen, lassen sich mehrere Schwächen zu einem Angriffspfad verbinden oder Schutzmechanismen umgehen? Ein Penetrationstest kann Fehler in Geschäftslogik oder Autorisierung aufdecken, die ein typischer Infrastrukturscanner nicht erkennt. Gleichzeitig ist ein Penetrationstest eine zeitpunktbezogene Prüfung und ersetzt nicht die laufende Erkennung neu veröffentlichter Schwachstellen. NIST SP 800-115 beschreibt diese Techniken als sich ergänzende Methoden der Sicherheitsbewertung.^[1]

Ein IT-Sicherheitsaudit bewertet dagegen den Zustand anhand festgelegter Kriterien: Gesetze, Normen, Verträge, Richtlinien oder eine angenommene Methodik. Es kann prüfen, ob ein Schwachstellenmanagementprozess existiert, wie Prioritäten gesetzt werden, ob definierte Fristen eingehalten werden, wie Ausnahmen behandelt werden und ob die Umsetzung von Maßnahmen nachgewiesen werden kann. Ein Schwachstellenscan kann dabei ein Auditnachweis sein, ist aber nicht mit dem Audit selbst gleichzusetzen.

Daher sollten Schwachstellenscan, Penetrationstest und Audit nicht als drei Varianten derselben Dienstleistung dargestellt werden. Ebenso falsch ist die Annahme, jede Organisation, die dem polnischen KSC, DORA oder der DSGVO unterliegt, müsse alle drei Prüfungsarten im gleichen Zyklus einkaufen. Pflichten ergeben sich aus dem konkreten Rechtsregime, dem Risiko und der Architektur. In manchen Fällen verlangt das Recht ausdrücklich Tests oder Scans, in anderen einen Sicherheitszustand, der mit unterschiedlichen Maßnahmen erreicht werden kann.

Zuerst Umfang und Inventarisierung

Ein Schwachstellenmanagementprogramm beginnt vor dem ersten Scan. Zunächst muss klar sein, was überhaupt geprüft wird.

Zum Umfang können Server, Arbeitsstationen, Netzwerkgeräte, aus dem Internet erreichbare Systeme, Cloud-Dienste, mobile Geräte, Container, Images, Anwendungen, OT-Systeme und von Dienstleistern betriebene Geräte gehören. Für die Wirksamkeit des Programms ist häufig wichtiger, welcher Anteil der tatsächlichen Umgebung überhaupt erfasst wird, als wie viele CVEs ein Scanner meldet.

Ein fehlendes Asset ist besonders gefährlich: Der Scanner kann technisch fehlerfrei arbeiten und dennoch ein System übersehen, das außerhalb seines Umfangs liegt. Dazu gehören kurzlebige Cloud-Instanzen, Testsysteme, die schleichend produktiv geworden sind, durch Dienstleister installierte Geräte oder Ressourcen, die außerhalb des regulären Change-Prozesses bereitgestellt wurden.

Ein reifes Programm kombiniert daher Informationen aus Asset-Inventaren, Cloud-Plattformen, Endpoint-Management, CMDB, EDR, Netzwerküberwachung und den Angaben der Serviceverantwortlichen. Ziel ist nicht ein einziges perfektes Register, sondern die Erkennung von Widersprüchen zwischen den Quellen.

Authentifizierte und nicht authentifizierte Scans

Ein nicht authentifizierter Scan betrachtet ein System aus der Perspektive eines entfernten Clients. Er kann offene Dienste, Banner, Versionen, typische Antworten, Fehlkonfigurationen und über das Netzwerk erreichbare Schwachstellen erkennen. Er eignet sich besonders zur Bewertung der Angriffsfläche aus dem Internet, kann aber Patchstand oder lokale Konfiguration nicht immer zuverlässig bestimmen.

Ein authentifizierter Scan verwendet ein technisches Konto oder einen anderen Zugriffsmechanismus auf dem Zielsystem. Dadurch kann der Scanner tatsächliche Paketversionen, Update-Status und Einstellungen auslesen, die über das Netzwerk nicht sichtbar sind. Das verbessert in der Regel die Datenqualität und reduziert einen Teil fehlerhafter Zuordnungen, führt aber zu neuen Anforderungen: sichere Speicherung von Zugangsdaten, minimale Berechtigungen, Protokollierung der Nutzung des Scannerkontos und klare Begrenzung seines Zugriffs.

Es gibt keine allgemeine Regel, nach der nicht authentifizierte Scans nur für das Internet und authentifizierte Scans nur für interne Netze geeignet sind. Die Wahl hängt vom Prüfziel ab. Bei einem öffentlich erreichbaren System ist es sinnvoll, sowohl die Sicht eines nicht vertrauenswürdigen externen Clients als auch den tatsächlichen lokalen Patchstand zu kennen.

Ein Schwachstellenscan sollte nicht als destruktiver Test verstanden werden. Aktive Prüfungen können dennoch alte Geräte, Echtzeitsysteme, OT-Komponenten, Drucker, medizinische Geräte oder instabile Dienste beeinflussen. Vor dem Start sind deshalb Rules of Engagement, Testfenster, Abbruchkriterien und Ansprechpartner des Systemverantwortlichen festzulegen. NIST SP 800-115 behandelt Autorisierung und Rules of Engagement ausdrücklich als Teil der Vorbereitung technischer Tests.^[1]

Validierung: Ein Scannergebnis ist noch kein belastbarer Befund

Einer der teuersten Fehler im Schwachstellenmanagement besteht darin, unbearbeitete Scannergebnisse direkt an Systemverantwortliche weiterzugeben.

Ein Scanner kann eine Schwachstelle allein aufgrund einer über das Netzwerk sichtbaren Version falsch zuordnen. Er kann ein vom Hersteller zurückportiertes Sicherheitsupdate nicht erkennen. Er kann eine Bibliothek finden, die zwar auf dem Datenträger liegt, aber nicht im verwundbaren Kontext genutzt wird. Umgekehrt kann er eine Schwachstelle übersehen, wenn ein Dienst gefiltert wird oder sich die Version nicht bestimmen lässt.

Validierung bedeutet nicht zwingend, jede Position manuell zu prüfen. Es muss jedoch ein Verfahren geben, um unklare Fälle zu klären und Herstellerhinweise, lokalen Paketstand, Konfiguration, Exposition und Erkenntnisse aus authentifizierten Scans einzubeziehen.

Ein Bericht sollte mindestens zwischen bestätigten Schwachstellen, wahrscheinlichen Beobachtungen mit weiterem Prüfbedarf, nicht zutreffenden Einträgen und nicht abschließend bewertbaren Ergebnissen unterscheiden. Damit ist für den Systemverantwortlichen nachvollziehbar, worauf ein Befund beruht und welcher nächste Schritt erforderlich ist.

CVSS 4.0: Schweregrad, nicht fertiger Risikowert

FIRST veröffentlichte CVSS 4.0 offiziell am 1. November 2023. Die Präsentation im Juni 2023 war eine Vorabvorstellung und nicht das Datum der offiziellen Veröffentlichung.^[2]

CVSS 4.0 behält die Skala von 0 bis 10 bei, verändert aber das Modell. Die Scope-Metrik aus Version 3.1 wurde entfernt; Auswirkungen auf das verwundbare System und auf ein nachgelagertes System werden getrennt beschrieben. Mit Attack Requirements wurde eine neue Basismetrik eingeführt, und User Interaction wurde differenzierter gestaltet. FIRST unterscheidet nun die Metrikgruppen Base, Threat, Environmental und Supplemental.^[2]

Die Gruppe Threat enthält unter anderem Exploit Maturity und beschreibt damit den Reifegrad verfügbarer Ausnutzungsmethoden. Die Gruppe Environmental ermöglicht es dem Anwender, die Bedeutung von Vertraulichkeit, Integrität und Verfügbarkeit in seiner eigenen Umgebung einzubeziehen und ausgewählte Basismetriken anzupassen. Die Gruppe Supplemental enthält zusätzliche Informationen wie Safety, Automatable, Recovery, Vulnerability Response Effort und Provider Urgency. Diese Zusatzmetriken verändern den berechneten CVSS-Wert nicht.^[2]

Der wichtigste Hinweis von FIRST ist eindeutig: Der CVSS Base Score misst den Schweregrad, nicht das Risiko. Der Basiswert sagt nicht, ob das betroffene System in unserer Organisation überhaupt vorhanden ist, aus dem Internet erreichbar ist, kritische Daten verarbeitet, kompensierende Maßnahmen besitzt oder aktiv angegriffen wird.^[2]

Eine Richtlinie wie "alles mit CVSS >= 7 innerhalb von 30 Tagen patchen" sollte deshalb nicht als universelles Risikomodell verstanden werden. Ein solcher Schwellenwert kann Bestandteil einer internen Regelung sein, ist aber keine allgemeine Grenze zwischen akzeptablem und nicht akzeptablem Risiko.

EPSS: Prognose der Ausnutzung, keine zweite Schweregradskala

Das Exploit Prediction Scoring System (EPSS) ist ein datengetriebenes Modell der FIRST-Community. Es schätzt die Wahrscheinlichkeit, dass für eine veröffentlichte CVE innerhalb der nächsten 30 Tage Ausnutzungsaktivität beobachtet wird. Der Wert liegt zwischen 0 und 1 und wird täglich aktualisiert.^[3] Grundlagen einer früheren Modellgeneration wurden außerdem in der begutachteten Arbeit von Jacobs und Mitautoren beschrieben.^[4]

EPSS sagt nicht, wie schwer die Folgen einer erfolgreichen Ausnutzung sind. Es kennt auch nicht die konkrete Umgebung der Organisation. Ein Wert von 0,10 steht für eine geschätzte Wahrscheinlichkeit von ungefähr 10 Prozent, dass innerhalb des 30-Tage-Fensters Ausnutzungsaktivität beobachtet wird. Er bedeutet nicht "10 Prozent Organisationsrisiko".^[3]

FIRST legt keinen offiziellen Schwellenwert fest, ab dem jede Schwachstelle als kritisch zu behandeln ist. Organisationen können eigene Schwellenwerte definieren, diese sollten jedoch zur Kapazität des Teams, zur Art der Assets und zur Risikotoleranz passen. Zusätzlich veröffentlicht FIRST Perzentile, die die relative Position einer Schwachstelle in der Gesamtpopulation zeigen.^[3]

CISA KEV: Beleg für aktive Ausnutzung

Der Known Exploited Vulnerabilities Catalog der CISA enthält Schwachstellen, die die Kriterien für bestätigte Ausnutzung in realen Angriffen erfüllen. CISA bezeichnet KEV selbst als maßgebliche Eingangsgröße für die Priorisierung im Schwachstellenmanagement.^[5]

Für zivile US-Bundesbehörden ergeben sich konkrete Behebungsfristen aus der Binding Operational Directive 22-01 und den in den einzelnen KEV-Einträgen angegebenen Fälligkeiten. Diese Fristen gelten nicht automatisch für polnische Unternehmen oder öffentliche Stellen. In Polen ist KEV vor allem ein starkes Threat-Intelligence-Signal: Die Frage "wird diese Schwachstelle tatsächlich ausgenutzt?" ist für einen KEV-Eintrag bereits positiv beantwortet.

KEV ist keine vollständige Liste aller weltweit ausgenutzten Schwachstellen. Die Aufnahme hängt von den Kriterien der CISA und verfügbaren Belegen ab. Das Fehlen einer CVE im KEV-Katalog bedeutet daher nicht, dass sie sicher ist oder nirgendwo ausgenutzt wird. Ein reifes Programm ergänzt KEV durch Herstelleradvisories, CSIRT/CERT-Meldungen, ENISA, Daten aus dem eigenen SOC und weitere belastbare Threat-Intelligence-Quellen.^[5][7][19]

CVSS, EPSS, KEV und Asset-Kontext gemeinsam nutzen

Eine gute Priorisierung reduziert diese Signale nicht auf eine einzige willkürliche Zahl. Besser ist es, zu erhalten, was jede Kennzahl tatsächlich beschreibt.

• CVSS beantwortet die Frage nach dem technischen Schweregrad.
• EPSS beantwortet die Frage nach der prognostizierten Wahrscheinlichkeit beobachteter Ausnutzung in den nächsten 30 Tagen.
• KEV beantwortet die Frage, ob eine Ausnutzung in realen Angriffen bestätigt wurde.
• Der Organisationskontext beantwortet die Frage, ob das verwundbare Asset wichtig, erreichbar und exponiert ist und welche Folgen eine Kompromittierung hätte.

Hinzu kommen operative Informationen: Verfügbarkeit eines Patches, Aufwand der Einführung, mögliche kompensierende Maßnahmen, geschäftliche Abhängigkeiten und rechtliche Vorgaben.

Eine Schwachstelle mit mittlerem CVSS kann zum Beispiel sofortige Aufmerksamkeit erfordern, wenn sie in KEV enthalten ist, ein öffentlich erreichbares Edge-Gerät betrifft und einen Einstieg in das Netz ermöglicht. Eine Schwachstelle mit hohem CVSS in einer deaktivierten Komponente eines isolierten Labors kann dagegen anders behandelt werden. Solche Entscheidungen sollten dokumentiert und reproduzierbar sein.

Behebungsfristen sollten aus der internen Richtlinie und der Risikoanalyse hervorgehen. NIST SP 800-40 Rev. 4 beschreibt Patch Management als Prozess des Identifizierens, Priorisierens, Beschaffens, Installierens und Verifizierens von Patches, legt aber keine universellen Fristen wie "KEV in 14 Tagen" oder "CVSS 9.0 in 30 Tagen" für jede Organisation fest.^[12]

Was Daten aus den Jahren 2025-2026 zeigen

Der Verizon DBIR 2026 nennt die Ausnutzung von Schwachstellen als initialen Zugangsvektor bei 31 Prozent der untersuchten Datenschutzverletzungen und berichtet, dass sie erstmals in der Geschichte des Reports den Missbrauch von Zugangsdaten als Eintrittspunkt überholt hat.^[6] Das bedeutet nicht, dass 31 Prozent aller Cyberangriffe weltweit mit einer Schwachstelle beginnen. Der DBIR beschreibt seinen eigenen Datensatz und seine eigene Methodik.

Der ENISA Threat Landscape 2025 analysiert 4.875 Vorfälle im Zeitraum vom 1. Juli 2024 bis 30. Juni 2025. Dort machte die Ausnutzung von Schwachstellen 21,3 Prozent der identifizierten initialen Eindringvektoren aus und lag damit hinter Phishing.^[7] Es handelt sich um eine andere Grundgesamtheit als beim DBIR, weshalb die Prozentwerte nicht direkt miteinander verglichen werden sollten.

Beide Quellen stützen jedoch denselben operativen Schluss: Technische Schwachstellen bleiben ein wichtiger Weg für initialen Zugriff. Besondere Aufmerksamkeit verdienen Edge-Systeme und andere aus dem Internet erreichbare Assets, bei denen das Zeitfenster zwischen Veröffentlichung und Ausnutzungsversuchen kurz sein kann.

Häufige Fehler im Schwachstellenmanagement

1. Ein Scan nur kurz vor einem Audit. Ein Jahresbericht kann belegen, dass an einem bestimmten Tag geprüft wurde, sagt aber nichts über später veröffentlichte Schwachstellen oder spätere Konfigurationsänderungen aus. Die Frequenz sollte sich aus Risiko, Veränderungsdynamik und anwendbaren Anforderungen ergeben. Bei manchen Systemen ist ein kurzer Zyklus sinnvoll, bei anderen sind vorsichtigere Prüfungen in kontrollierten Wartungsfenstern erforderlich.
2. Fehlende Verantwortlichkeit. Eine CVE-Liste ist kein Maßnahmenplan. Jede Position, die eine Aktion erfordert, sollte einen Verantwortlichen, eine Priorität, einen Termin, einen Status und einen Nachweis des Abschlusses haben.
3. Ein fehlender Ausnahmeprozess. Nicht jeder Patch kann sofort installiert werden. Möglicherweise gibt es noch keine Herstellerkorrektur, kein Wartungsfenster oder eine Anwendung ist inkompatibel. Eine Ausnahme benötigt Begründung, Risikoverantwortlichen, kompensierende Maßnahmen, Termin zur Neubewertung und einen langfristigen Lösungsplan.
4. Die Beschränkung auf Server. Schwachstellen betreffen ebenso Arbeitsstationen, Netzwerkgeräte, Drucker, Kameras, Hypervisoren, Cloud-Systeme, Container und OT-Geräte.
5. Die Gleichsetzung der Anzahl von Findings mit dem Sicherheitsniveau. Steigt die Zahl der Findings nach einer Verbesserung der Scanabdeckung, kann dies bedeuten, dass das Programm besser geworden ist, nicht schlechter. Sinnvolle Kennzahlen umfassen deshalb auch Asset-Abdeckung, Validierungszeit, Behebungszeit priorisierter Findings, überfällige Ausnahmen und wiederkehrende Ursachen.
6. Automatisierte Behebung ohne Kontrolle der Auswirkungen. Ein Patch kann eine Schwachstelle schließen und gleichzeitig einen kritischen Dienst stoppen. Reifes Schwachstellenmanagement ist mit Change Management, Tests, Backup und Rollback-Planung verbunden.

OT und schwer aktualisierbare Systeme

In OT-Umgebungen erfordert aktives Scannen besondere Vorsicht. Ein alter Controller, ein Echtzeitgerät oder ein ungewöhnliches Protokoll kann auf Testverkehr anders reagieren als ein typischer IT-Server. Vor dem Scan sollten zulässige Techniken mit dem Prozessverantwortlichen und dem Hersteller abgestimmt werden. In manchen Segmenten spielen passive Netzwerkbeobachtung und Inventarisierung eine größere Rolle.

Wenn ein Patch nicht sofort eingespielt werden kann, bedeutet das nicht, dass keine Maßnahme möglich ist. Die Exposition kann durch Segmentierung, Verkehrsfilterung, Einschränkung des Fernzugriffs, zusätzliche Überwachung, Application Control oder vorübergehendes Deaktivieren von Funktionen reduziert werden. Solche kompensierenden Maßnahmen müssen mit einem konkreten Risiko und einem langfristigen Behebungsplan verknüpft sein.

Scans von Webanwendungen

Infrastrukturscans und dynamische Tests von Webanwendungen sind verwandte, aber unterschiedliche Bereiche. DAST-Werkzeuge senden Anfragen an eine Anwendung und analysieren deren Antworten. Sie können bestimmte Fehlerklassen erkennen, ersetzen aber weder die Prüfung von Geschäftslogik und Autorisierung noch eine Quellcodeanalyse.

OWASP Top 10 2025 ist ein Awareness-Dokument zu wichtigen Risikokategorien in Webanwendungen, keine Scanmethodik. OWASP ASVS 5.0.0 ist dagegen ein Katalog überprüfbarer Anforderungen und kann eine wesentlich präzisere Grundlage für Anwendungstests bilden.^[17]

Die Aussage "der DAST-Scanner hat nichts gefunden" ist daher kein Nachweis dafür, dass die gesamte Anwendung OWASP Top 10 oder ASVS erfüllt.

Rechtliche Grundlagen in Polen und der EU

KSC. Seit der am 3. April 2026 in Kraft getretenen Novelle verpflichtet Art. 8 des polnischen Gesetzes über das nationale Cybersicherheitssystem wesentliche und wichtige Einrichtungen unter anderem zu systematischem Risikomanagement, zum Sammeln von Informationen über Cyberbedrohungen und Schwachstellen, zu regelmäßigen Softwareupdates unter Berücksichtigung der Kritikalität und zu unverzüglichen Maßnahmen nach Feststellung einer Schwachstelle.^[8] Das Gesetz schreibt nicht den Kauf eines bestimmten Scanners vor.

Für bestimmte Anbieter, auf die Art. 8b KSC verweist, gilt die Durchführungsverordnung (EU) 2024/2690 unmittelbar. Abschnitt 6.10 verlangt das Einholen von Informationen über technische Schwachstellen, die Bewertung der Exposition und geeignete Maßnahmen zur Behandlung; gegebenenfalls sind Schwachstellenscans in geplanten Abständen durchzuführen und deren Ergebnisse zu dokumentieren. Derselbe Rechtsakt verlangt eine Richtlinie für Sicherheitstests und verbindet Schwachstellenmanagement mit Patch Management, Change Management, Risikomanagement und Incident Management.^[10]

NIS2. Art. 21 der Richtlinie nennt unter den Maßnahmen des Cybersicherheitsrisikomanagements unter anderem die Sicherheit bei Beschaffung, Entwicklung und Wartung von Netz- und Informationssystemen einschließlich Behandlung und Offenlegung von Schwachstellen sowie Verfahren zur Bewertung der Wirksamkeit von Sicherheitsmaßnahmen.^[9] Für polnische Organisationen sind die konkreten Pflichten jedoch primär anhand des KSC und unmittelbar anwendbarer EU-Rechtsakte zu bestimmen.

KRI. Die polnische Verordnung über den nationalen Interoperabilitätsrahmen vom 21. Mai 2024 ist am 29. August 2026 weiterhin in Kraft. Sie verlangt von öffentlichen Stellen unter anderem aktuelle Inventare von Hardware und Software, Softwareaktualisierung, die Reduzierung von Risiken aus veröffentlichten technischen Schwachstellen und unverzügliches Handeln bei erkannten nicht veröffentlichten Schwachstellen.^[14] Eine einheitliche Scanfrequenz schreibt sie nicht vor. ELI weist den 23. Februar 2027 als Außerkrafttretensdatum aus. Im August 2026 ist der neue KRI-Entwurf RD313 weiterhin ein Entwurf und darf nicht wie geltendes Recht behandelt werden.^[14]

DORA. Die Verordnung (EU) 2022/2554 verpflichtet Finanzunternehmen zur laufenden Identifikation von IKT-Risikoquellen und zur Bewertung relevanter Cyberbedrohungen und IKT-Schwachstellen.^[11] Die Delegierte Verordnung (EU) 2024/1774 geht weiter und verlangt dokumentierte Verfahren für Schwachstellenmanagement sowie automatisierte Schwachstellenscans und Bewertungen von IKT-Assets; Häufigkeit und Umfang müssen der Klassifikation und dem Risikoprofil des jeweiligen Assets entsprechen.^[13] Es gibt somit keinen einheitlichen Zeitplan für sämtliche Systeme.

DSGVO. Art. 32 Abs. 1 Buchst. d verlangt, dem Risiko angemessen, ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit technischer und organisatorischer Maßnahmen.^[15] Die DSGVO verlangt nicht ausdrücklich "einen Schwachstellenscan alle X Tage". Ein Schwachstellenscan kann jedoch ein Nachweis dafür sein, dass die Wirksamkeit von Sicherheitsmaßnahmen tatsächlich überprüft wird.

PCI DSS. In Kartenumgebungen ist PCI DSS v4.0.1 das aktuelle Regelwerk. Requirement 11 sieht regelmäßige Schwachstellenscans vor; bestimmte externe Scans müssen durch einen PCI SSC Approved Scanning Vendor durchgeführt werden. PCI SSC erläutert, dass vierteljährliche Scans mindestens einmal alle drei Monate durchzuführen sind.^[16] Dies ist eine Branchenanforderung und keine allgemeine gesetzliche Pflicht jeder Organisation.

Cyber Resilience Act und SBOM

Die Verordnung (EU) 2024/2847, der Cyber Resilience Act (CRA), verschiebt Verantwortlichkeiten auch auf Hersteller von Produkten mit digitalen Elementen. Die Hauptpflichten gelten ab dem 11. Dezember 2027; die Meldepflichten des Art. 14 gelten bereits ab dem 11. September 2026.^[18]

Der CRA verlangt Prozesse zur Schwachstellenbehandlung; die technische Dokumentation muss unter anderem eine Software Bill of Materials (SBOM) umfassen. Anhang I verpflichtet Hersteller, Schwachstellen und Komponenten zu identifizieren und zu dokumentieren sowie eine SBOM in einem gängigen maschinenlesbaren Format zu erstellen, die mindestens die Abhängigkeiten der obersten Ebene abbildet.^[18]

Für den Nutzer ist eine SBOM kein Scanner und beweist nicht automatisch, dass ein Produkt verwundbar ist. Sie ermöglicht jedoch wesentlich schneller festzustellen, ob eine bestimmte Komponente in einem Produkt vorhanden ist. Das verkürzt die Analyse, wenn in einer weit verbreiteten Bibliothek eine Schwachstelle veröffentlicht wird.

Vom Schwachstellenscan zum Exposure Management

Ein reifes Programm beginnt zunehmend nicht mit der CVE-Liste, sondern mit der Frage: Welche Angriffspfade führen zu wichtigen Assets und welche Schwächen erhöhen tatsächlich die Wahrscheinlichkeit einer Kompromittierung?

Der Schwachstellenscan bleibt ein wichtiger Sensor, sollte aber mit Daten zur Angriffsfläche, Identitäten, Cloud-Konfiguration, Anwendungssicherheit, Angreiferaktivität und realen Serviceabhängigkeiten verknüpft werden. Das bedeutet nicht, dass jede Organisation ein Produkt mit der Bezeichnung "Exposure Management" kaufen muss. Entscheidend ist, Daten in einen besseren Entscheidungsprozess zu überführen.

In der Praxis kann Schwachstellenscanning mit IT-Sicherheitsaudits, Hardening, Penetrationstests und einem 24/7-SOC verbunden werden. Jede dieser Funktionen beantwortet jedoch eine andere Frage. Bei 4crypto werden technische Findings als Eingangsdaten des Risikomanagements verstanden und nicht als eigenständiges "Sicherheitszertifikat".

Wie sich das Programm messen lässt

Die Anzahl gefundener Schwachstellen ist operativ nützlich, aber eine schwache Reifegradkennzahl. Aussagekräftiger sind beispielsweise:

• Abdeckung: Welcher Anteil bekannter Assets und kritischer Services wird mit einer geeigneten Prüfmethode erfasst?
• Aktualität: Wie schnell wird ein neues Asset in das Programm aufgenommen?
• Validierung: Wie lange dauert es, ein priorisiertes Finding zu bestätigen oder zu verwerfen?
• Behebung: Wie lange dauert es von der Bestätigung bis zur wirksamen Beseitigung oder Risikoreduktion?
• Rückstand: Wie viele Findings sind überfällig und warum?
• Ausnahmen: Wie viele akzeptierte Ausnahmen besitzen keine aktuelle Neubewertung?
• Wiederholung: Wie viele Probleme treten aus derselben Ursache erneut auf?
• Verifikation: Welcher Anteil der Behebungen wurde erneut geprüft?

Kennzahlen müssen so definiert sein, dass Anfang und Ende der Messung eindeutig sind. Eine "Mean Time to Remediate", die ab Veröffentlichung einer CVE gemessen wird, ist nicht dieselbe Kennzahl wie eine Messung ab Erkennung der Schwachstelle in der eigenen Umgebung.