Ein Vulnerability-Scanning-Bericht fasst strukturiert zusammen, was ein Vulnerability Scanner in einer Umgebung gefunden hat. Er zeigt, welche Komponenten verwundbar sind, wie kritisch das ist und welche Schritte als Nächstes folgen.
Man kann ihn sich wie das „Laborergebnis" eines Sicherheits-Scans vorstellen. Der Scanner erledigt die technische Arbeit im Hintergrund; der Bericht ist das, was Teams tatsächlich lesen und in Maßnahmen übersetzen.
Die meisten Berichte folgen einem ähnlichen Muster:
Zusammenfassung: überblickt das Risiko und die wichtigsten Kennzahlen;
Details: listet die Schwachstellen auf einzelnen Ressourcen auf;
Handlungsempfehlungen: beschreiben klare Schritte, um das Risiko zu beheben oder zu reduzieren.
Wenn ein Team zwar vulnerability scanning betreibt, die Ergebnisse aber nie in einen Bericht überführt, geht der eigentliche Nutzen des Prozesses verloren.
Die zentralen Abschnitte in einem Vulnerability-Scanning-Bericht
Die meisten Tools gliedern den Bericht in wiederkehrende Abschnitte. Wer die Aufgabe jedes Abschnitts kennt, findet sich deutlich schneller zurecht und verliert nicht den Überblick.
Management-Zusammenfassung
Die Management-Zusammenfassung erzählt die Kurzfassung des Scans. Sie enthält in der Regel die Gesamtzahl der Schwachstellen, wie viele davon kritisch oder hoch eingestuft sind, und eine kurze Beschreibung der größten Risiken.
Dieser Abschnitt richtet sich an die Leitungsebene und an nichttechnische Stakeholder. Er sollte in klarer Sprache zwei Fragen beantworten: Besteht gerade akuter Handlungsbedarf? Und entwickelt sich die Lage besser oder schlechter?
Ein Beispiel für eine Management-Zusammenfassung:
„Der Scan dieses Monats umfasste 1.247 Cloud-Ressourcen in Produktions- und Staging-Umgebungen in AWS und Azure. Dabei wurden 89 neue Schwachstellen identifiziert: 3 kritische, 12 hohe, 31 mittlere und 43 niedrige. Alle 3 kritischen Funde liegen auf internetseitigen Webservern und stehen im Katalog der Known Exploited Vulnerabilities der CISA – laut SLA müssen sie innerhalb von 7 Tagen gepatcht werden. Das Entwicklungsteam hat die Fixes bereits in Staging ausgerollt und überführt sie am Freitag in die Produktion. Die Gesamtzahl der Schwachstellen sank gegenüber dem Vormonat um 15 %, und 94 % der kritischen und hohen Funde wurden innerhalb der SLA geschlossen. Größtes Risiko in diesem Monat: eine RCE-Schwachstelle (CVE-2024-1234) im Kundenportal, über die nicht authentifizierte Angreifer auf Session-Tokens zugreifen könnten."
Umfang und Methodik
Der Umfang beschreibt, was gescannt wurde. Die Methodik beschreibt, wie der Scanner dabei vorgegangen ist.
Ein guter Abschnitt zu Umfang und Methodik deckt Folgendes ab:
Ressourcen im Scope: IP-Bereiche, Domains, Cloud-Konten, Cluster und Anwendungen;
Scan-Typen: intern oder extern, authentifiziert oder nicht authentifiziert;
Einschränkungen: was nicht gescannt wurde oder wo der Zugriff begrenzt war.
Anhand dieses Abschnitts lässt sich prüfen, ob der Scan den Erwartungen entspricht. Fehlt etwa ein zentrales Produktionskonto im Umfang, ist der Bericht unvollständig.
Ressourceninventar
Das Ressourceninventar listet jedes System auf, das der Scanner erfasst hat. In einer cloud-native Umgebung umfasst das häufig virtual machines, Container, serverless Functions, Datenbanken und Load Balancer.
Nützliche Berichte listen nicht nur Hostnamen auf. Sie ergänzen zusätzlich Labels wie:
die Umgebung (prod, staging, dev);
den Anwendungs- oder Servicenamen;
das verantwortliche Team oder die Geschäftseinheit.
Diese Zuordnung ermöglicht es später, Aufgaben an die richtigen Personen zu leiten, statt zu raten, wer für „ip-10-0-3-47" zuständig ist.
Schwachstellen-Funde
Im Abschnitt zu den Funden zeigt der Scanner seine Ergebnisse. Jeder Eintrag steht in der Regel für einen Schwachstellentyp auf einer oder mehreren Ressourcen.
Zu jedem Fund erscheinen üblicherweise:
Name und ID: etwa eine CVE-Nummer oder ein Hersteller-Advisory;
Schweregrad und Score: kritisch, hoch, mittel oder niedrig samt CVSS-Score;
Beschreibung: worum es sich bei der Schwachstelle handelt und warum sie relevant ist;
betroffene Ressourcen: welche Systeme, container images oder Anwendungen betroffen sind;
Referenzen: Links oder IDs für weitere Details.
Hier verbringen die technischen Teams den Großteil ihrer Zeit.
Risikobewertung und Priorisierung
Die Risikobewertung erklärt, wie der Bericht entscheidet, was am wichtigsten ist. Einfache Berichte stützen sich nur auf Schweregrade. Bessere Berichte beziehen die konkrete Umgebung mit ein.
Kontext des Angriffspfads: Die wirksamsten Berichte priorisieren Funde, die vollständige Angriffspfade bilden. Dazu verknüpfen sie Angriffsfläche (internetseitig), Schwachstellen (ausnutzbare Fehler), Identitäten (übermäßige Berechtigungen) und Datensensibilität (Zugriff auf Kundendaten oder Anmeldedaten). Eine mittelschwere Schwachstelle auf einem internetseitigen Server mit Admin-Rechten für die Produktionsdatenbank birgt ein höheres reales Risiko als eine kritische Schwachstelle auf einem isolierten Entwicklungssystem.
Zu sehen sind häufig:
eigene Abschnitte wie „Top-Risiken" oder „Sofort beheben";
Tags zum Geschäftseinfluss, etwa „kundenseitig" oder „Zahlungssystem";
Markierungen für Schwachstellen mit bekannten Exploits, insbesondere solche im Katalog der Known Exploited Vulnerabilities (KEV) der CISA oder mit hohen EPSS-Werten (Exploit Prediction Scoring System) über 0,2.
Dieser Teil zeigt, welche Probleme dringend sind und welche gefahrlos warten können.
Handlungsempfehlungen zur Behebung
Die Handlungsempfehlungen bilden den Abschnitt „So lässt es sich beheben". Zu jeder wichtigen Schwachstelle sollte der Bericht klare, schrittweise Hinweise geben.
Solche Hinweise können so aussehen:
„Paket X auf Version Y oder höher aktualisieren";
„Konfiguration Z von offen auf eingeschränkt ändern";
„Dieses Anmeldedaten-Set rotieren und seine Berechtigungen enger fassen".
Bleibt ein Bericht bei „das ist gefährlich" stehen und erreicht nie „das ist zu tun", fällt es Entwicklungsteams schwer, ins Handeln zu kommen.
Kennzahlen und Trends
Viele Berichte enthalten schließlich einen Abschnitt mit Kennzahlen, der Veränderungen im Zeitverlauf sichtbar macht.
Übliche Kennzahlen sind (und sollten, wo relevant, gegen definierte SLAs gemessen werden):
die Zahl offener Schwachstellen nach Schweregrad;
die durchschnittliche Zeit bis zur Behebung kritischer oder hoher Probleme;
der Vergleich zwischen Teams, Regionen oder Umgebungen.
Diese Trendlinien helfen der Leitungsebene und den Teams, Fortschritte zu belegen.
Eine einzige priorisierte Risikoliste: Der Risikoabbau lässt sich am besten über eine einheitliche, deduplizierte Liste verfolgen, damit die Leitungsebene die Veränderung des Sicherheitsstatus sieht und nicht das Alarmrauschen. Statt getrennter Trendlinien für Schwachstellen, Fehlkonfigurationen und Secrets zeigt ein einziger Risiko-Score alle Probleme, gewichtet nach Ausnutzbarkeit, Angriffsfläche und Geschäftseinfluss.
Kennzahlen und SLAs
Klare KPIs und SLAs legen fest, wie Erfolg für ein Team aussieht:
Behebungs-SLAs nach Schweregrad:
kritisch: 7 Tage (internetseitig), 14 Tage (intern);
hoch: 30 Tage;
mittel: 90 Tage;
niedrig: 180 Tage oder das nächste Wartungsfenster.
Zentrale KPIs:
Mean time to remediate (MTTR) nach Schweregrad;
Anteil der innerhalb der SLA geschlossenen Schwachstellen (Ziel: über 95 % bei kritisch und hoch);
Rate des Risikoabbaus (pro Woche geschlossene Schwachstellen);
Abdeckungskennzahlen (Anteil gescannter Ressourcen, Anteil authentifizierter Scans);
Alter der Ausnahmen (offene Risikoakzeptanzen, die älter als 90 Tage sind);
Wiederöffnungsrate (Anteil der Schwachstellen, die nach dem Schließen erneut auftreten).
Frühindikatoren:
Zeit vom Abschluss des Scans bis zur Ticket-Erstellung;
Zeit von der Ticket-Erstellung bis zur Zuweisung an Verantwortliche;
Anteil der Funde mit verfügbarer automatischer Behebung.
Diese Werte lassen sich monatlich verfolgen und quartalsweise mit der Leitungsebene besprechen. Steigt die MTTR oder fällt die SLA-Einhaltung unter 90 %, sollte geprüft werden, ob mehr Automatisierung, eine bessere Priorisierung oder zusätzliche Ressourcen nötig sind.
Vorlage und Checkliste für den Vulnerability-Scanning-Bericht
Die folgende einseitige Checkliste hilft dabei, eigene Berichte zu strukturieren:
Management-Zusammenfassung
Gesamtzahl der Schwachstellen nach Schweregrad (kritisch, hoch, mittel, niedrig);
die 3 bis 5 größten Risiken, die sofortiges Handeln erfordern;
Trend gegenüber dem vorherigen Scan (verbessert, stabil, verschlechtert);
Status der SLA-Einhaltung (Anteil kritischer Funde, die innerhalb von 7 Tagen behoben wurden, Anteil hoher Funde innerhalb von 30 Tagen).
Umfang und Methodik
gescannte Ressourcen (IP-Bereiche, Cloud-Konten, Regionen, Cluster);
Scan-Typen (authentifiziert oder nicht authentifiziert, intern oder extern);
eingesetzte Tools und Versionen;
Einschränkungen und Ausschlüsse.
Ressourceninventar
Gesamtzahl der entdeckten Ressourcen;
Ressourcen nach Umgebung (Produktion, Staging, Entwicklung);
Ressourcen nach verantwortlichem Team oder Geschäftseinheit;
neue Ressourcen seit dem letzten Scan.
Schwachstellen-Funde
CVE-ID und Name;
CVSS-Score und Schweregrad;
EPSS-Wahrscheinlichkeit und CISA-KEV-Status;
betroffene Ressourcen (Hostname, IP, Image, Function);
Kontext der Angriffsfläche (internetseitig, intern, isoliert);
Referenzen und Hersteller-Advisories.
Risikopriorisierung
attack path analysis (Angriffsfläche + Schwachstelle + Berechtigungen + Datenzugriff);
Klassifizierung des Geschäftseinflusses (kundenseitig, umsatzkritisch, compliance-relevant);
Signale zur Ausnutzbarkeit (KEV, EPSS über 0,2, verfügbarer Proof of Concept);
Erreichbarkeit sensibler Datastores.
Handlungsempfehlungen zur Behebung
konkrete Behebungsschritte (Patch-Version, Konfigurationsänderung, Anpassung der Berechtigungen);
zugewiesene Verantwortliche (Team, Person, Ticket-ID);
Fälligkeitsdatum auf Basis der SLA je Schweregrad;
Workarounds oder kompensierende Maßnahmen, falls sich das Patchen verzögert.
Kennzahlen und Trends
Mean time to remediate (MTTR) nach Schweregrad;
Anteil der innerhalb der SLA geschlossenen Schwachstellen;
Rate des Risikoabbaus (pro Woche geschlossene Schwachstellen);
Abdeckungsgrad (Anteil authentifiziert gescannter Ressourcen);
Alter der Ausnahmen (offene Risikoakzeptanzen, die älter als 90 Tage sind).
Compliance-Zuordnung
SOC-2-Type-II-Nachweise (Kontrollmaßnahmen für vulnerability management);
ISO 27001 Anhang A.12.6.1 (technisches Schwachstellenmanagement);
NIST 800-53 RA-5 (vulnerability scanning), SI-2 (Behebung von Fehlern);
PCI DSS 11.2 (vierteljährliche Scans, Scans nach wesentlichen Änderungen).
Ausnahmen und Risikoakzeptanz
akzeptierte Risiken mit geschäftlicher Begründung;
vorhandene kompensierende Maßnahmen;
Ablaufdaten der Ausnahmen;
Zeitplan für die erneute Bewertung.
Einen Vulnerability-Scanning-Bericht lesen, ohne den Überblick zu verlieren
Beim ersten Öffnen wirkt ein vollständiger Bericht schnell wie eine Wand aus Informationen. Die folgende Reihenfolge hilft, ihn zügig zu erfassen.
1. Die Management-Zusammenfassung überfliegen
Am Anfang steht die Management-Zusammenfassung, die das Gesamtbild liefert. Im Fokus stehen die Zahlen zu kritischen und hohen Schweregraden sowie alle hervorgehobenen „Top-Risiken".
Dabei helfen zwei Fragen:
Gibt es kritische Probleme auf internetseitigen Systemen?
Werden dringende Punkte mit konkreten Fristen genannt?
Klingt die Zusammenfassung alarmierend, ist ein tieferer Blick nötig.
2. Prüfen, ob der Umfang der Realität entspricht
Als Nächstes folgt der Blick auf Umfang und Methodik. Hier gilt es zu bestätigen, dass die richtigen Netzwerke, Cloud-Konten, Regionen und Umgebungen einbezogen wurden.
Fehlen etwa produktive Kubernetes-Cluster im Umfang, vermittelt der Bericht eine trügerische Sicherheit. Besser, das fällt jetzt auf und ein breiterer Scan folgt.
3. Die wichtigsten Ressourcen erkennen
Das Ressourceninventar hilft, die wichtigsten Systeme zu erkennen. Das sind meist:
produktive Workloads;
internetseitige Services;
Identity-Provider und Admin-Konsolen;
Datenbanken oder Speicher mit sensiblen Daten.
Bei der späteren Prüfung der Schwachstellen stehen diese Ressourcen zuerst im Fokus.
4. Auf die wichtigsten Funde nach Risiko konzentrieren
Im Abschnitt zu den Funden empfiehlt es sich, nicht jede Zeile einzeln zu lesen. Ein guter Einstieg sind Ansichten wie „Top-10-Funde" oder „Kritische Probleme".
Zu jedem wichtigen Fund lohnt der Blick auf:
die Auswirkung, falls jemand ihn ausnutzt;
ob die betroffene Ressource dem Internet ausgesetzt ist;
ob bekannte Exploits kursieren, bestätigt über CISA-KEV-Einträge oder EPSS-Werte über 0,2, die auf aktive Ausnutzung oder eine hohe Wahrscheinlichkeit hinweisen.
Ziel ist, „sollte bald behoben werden" von „muss sofort behoben werden" zu trennen.
5. Probleme den Verantwortlichen zuordnen
Ein Bericht nützt wenig, wenn niemand weiß, wer handeln soll. Sind die größten Risiken klar, folgt die Frage, welche Teams die betroffenen Ressourcen verantworten.
Manchmal hilft der Bericht dabei mit Tags oder Feldern für Verantwortliche. In anderen Fällen braucht es Namenskonventionen oder eine separate CMDB.
Zuordnung von Verantwortlichen über code-to-cloud: Moderne Berichte nutzen Tags von code repository, CI/CD pipeline, Projekt und Service, um Tickets automatisch den richtigen Teams zuzuweisen. Lässt sich etwa ein verwundbares container image auf das code repository „payments-api" des Payments-Teams zurückführen, kann der Bericht den Fund automatisch in den Backlog dieses Teams leiten – samt der konkreten Dockerfile und des Base Image, das aktualisiert werden muss.
Hier zeigt sich der Nutzen des code-to-cloud-Kontexts besonders deutlich. Lässt sich erkennen, dass ein verwundbares container image aus einem bestimmten code repository stammt, geht das Ticket direkt an das zuständige Entwicklungsteam.
6. Den Bericht in einen echten Backlog überführen
Zum Schluss wird aus dem Bericht eine priorisierte Liste von Behebungsaufgaben. Viele Teams gruppieren die Punkte so:
kritische Probleme auf internetseitigen oder hochsensiblen Systemen;
hohe Probleme auf produktiven Systemen;
mittlere Probleme auf exponierten oder wichtigen Systemen;
verbleibende Probleme auf Ressourcen mit geringerem Risiko.
Diese Aufgaben gehören in die Tools, die die Teams ohnehin nutzen: Jira-Tickets mit Schweregrad-Labels und Fälligkeitsdaten, ServiceNow-Incidents mit Zuweisungsgruppen und SLAs oder GitHub Issues, die mit bestimmten code repositories verknüpft sind. Jedes Ticket enthält die CVE-ID, die betroffene Ressource, das verantwortliche Team, die Behebungshinweise und das Fälligkeitsdatum. Wo möglich, sollte dieser Schritt automatisiert werden, damit Funde direkt vom Scanner in den Backlog fließen, ohne dass jemand manuell CSV-Dateien exportiert.
Von „vielen Funden" zu „echtem Risiko"
Nicht jede Schwachstelle im Bericht ist gleich gefährlich. Zwei Funde mit demselben CVSS-Score können je nach Umgebung ganz unterschiedliche reale Auswirkungen haben.
Technisches Risiko und Geschäftsrisiko
Das technische Risiko beschreibt, wie schwerwiegend eine Schwachstelle theoretisch ist. Das Geschäftsrisiko beschreibt, was sie in einer konkreten Umgebung anrichten kann.
Bei einem Fund helfen diese Fragen:
Ist das betroffene System von außerhalb des Netzwerks erreichbar?
Verfügt es über weitreichende Rechte oder Admin-Rechte in der Cloud?
Kann es wichtige Datastores oder kritische Services erreichen?
Ein mittelschwerer Fehler im öffentlichen Login-Service kann wichtiger sein als ein kritischer Fehler auf einem isolierten Testsystem.
Signale zur Ausnutzbarkeit: EPSS und CISA KEV
Nicht alle Schwachstellen werden mit gleicher Wahrscheinlichkeit ausgenutzt. Zwei zentrale Signale helfen, sich auf reale Bedrohungen zu konzentrieren:
CISA Known Exploited Vulnerabilities (KEV): Die US-amerikanische Cybersecurity and Infrastructure Security Agency pflegt einen Katalog von CVEs mit bestätigter aktiver Ausnutzung. Steht eine Schwachstelle im KEV-Katalog, nutzen Threat Actors sie bereits in Angriffen. Bundesbehörden müssen KEV-gelistete Schwachstellen bei internetseitigen Systemen innerhalb von 15 Tagen und bei internen Systemen innerhalb von 30 Tagen patchen – ein guter Richtwert für jede Organisation.
Exploit Prediction Scoring System (EPSS): EPSS vergibt einen Wahrscheinlichkeitswert (0,0 bis 1,0) dafür, wie wahrscheinlich eine Schwachstelle in den nächsten 30 Tagen ausgenutzt wird. Werte über 0,2 (20 % Wahrscheinlichkeit) verdienen sofortige Aufmerksamkeit. EPSS verbindet threat intelligence, verfügbare Exploits und historische Ausnutzungsmuster und sagt das Risiko damit genauer voraus als der CVSS-Schweregrad allein.
Diese Signale lassen sich mit dem Ressourcenkontext kombinieren:
KEV + internetseitig + Admin-Rechte = sofort beheben;
EPSS über 0,5 + Produktion + Zugriff auf sensible Daten = innerhalb von 7 Tagen beheben;
CVSS 9,0 + EPSS unter 0,01 + isolierte Entwicklungsumgebung = innerhalb von 30 Tagen beheben.
Dieser Ansatz reduziert das Alarmrauschen bei der Behebung um 60 bis 80 % gegenüber dem Vorgehen, alle „kritischen" Funde unabhängig von ihrer Ausnutzbarkeit zu beheben.
Wie moderne Berichte Kontext ergänzen
Neuere Tools ergänzen diesen Kontext direkt im Bericht des Vulnerability Scanners. Sie betrachten:
Netzwerk-Angriffsfläche: security groups, Firewalls und Ingress-Regeln;
Identitäten und Berechtigungen: Rollen, service accounts und Vertrauensbeziehungen;
Datenpfade: erreichbare Datenbanken, Buckets oder Message Queues;
Kombinationen: wenn eine Schwachstelle, eine Fehlkonfiguration und ein Secret zusammen einen vollständigen Angriffspfad bilden.
Hebt ein Bericht solche „toxischen Kombinationen" hervor, fällt die Entscheidung deutlich leichter, was zuerst zu beheben ist.
Besonderheiten von Berichten aus cloud-native Umgebungen
Cloud- und Container-Umgebungen sind dynamischer als klassische On-Premises-Netzwerke. Das verändert, was ein guter Bericht zeigen muss.
Agentless Discovery
In der Cloud lässt sich nicht voraussetzen, dass auf jedem Workload ein Agent installiert ist. Agentless scanning nutzt APIs der Cloud-Anbieter und Disk-Snapshots, um Ressourcen zu inventarisieren und zu bewerten, ohne auf jeder Maschine Software-Agents zu installieren. So entsteht eine breite Abdeckung über kurzlebige und unveränderliche Workloads hinweg.
In Berichten zeigt sich das als breitere Abdeckung:
Agentless über Clouds hinweg: API-basierte discovery für AWS, Azure, GCP und Kubernetes beseitigt blinde Flecken ohne Reibungsverluste beim Deployment. Dieser Ansatz inventarisiert virtual machines, Container, serverless Functions, verwaltete Datenbanken und Speicher – ganz ohne Agents, die Wartung erfordern oder Betriebsaufwand erzeugen.
virtual machines und Hosts;
Container und container images in registries;
serverless Functions und verwaltete Services.
Ist die Abdeckung über alle Cloud-Konten, Regionen und Services hinweg bestätigt, lässt sich dem Bericht deutlich mehr vertrauen – wobei blinde Flecken wie kurzlebige Container (unter 5 Minuten), deaktiviertes API-Logging oder Workloads in getrennten VPCs weiterhin im Blick bleiben sollten.
Abdeckung über den gesamten Lebenszyklus
cloud-native Anwendungen bringen Risiken im Code, in container images und in Runtime-Umgebungen mit. Ein starker Bericht macht Probleme über diesen Lebenszyklus hinweg sichtbar und nutzt software bill of materials (SBOM) und Vulnerability Exploitability eXchange (VEX), um zu qualifizieren, welche Komponenten tatsächlich geladen und ausnutzbar sind:
verwundbare Bibliotheken im Quellcode und in den dependencies;
alte oder ungepatchte Base Images in den registries;
Schwachstellen auf Hosts und in Containern in laufenden Umgebungen;
Fehlkonfigurationen in IaC-Templates und in Cloud-Control-Planes.
Hier beginnen vulnerability scanning, Konfigurationsscans und die Analyse von Berechtigungen ineinanderzugreifen.
Vereinheitlichte Sicht über Clouds hinweg
Wer mehr als eine Cloud nutzt, will keine drei völlig unterschiedlichen Berichtsformate. Vereinheitlichte Berichte verwenden gemeinsame Bezeichnungen und Schweregradmodelle, sodass sich Risiken vergleichen lassen.
Zum Beispiel:
„virtual machine" statt cloud-spezifischer Produktnamen;
eine einheitliche Skala von kritisch über hoch und mittel bis niedrig;
gemeinsame Tags wie „Produktion" oder „kundenseitig".
Das erleichtert es erheblich, Muster zu erkennen und globale Standards zu setzen.
Erwartungen der Leitungsebene an einen vulnerability management-Bericht
Teams und Entwickelnde interessieren sich für konkrete CVEs und Konfigurationen. CISO, CTO oder Vorstand interessieren sich für andere Fragen.
In der Regel wollen sie wissen:
Reduzieren wir unser Risiko im Zeitverlauf?
Gibt es offensichtliche Lücken oder blinde Flecken?
Reagieren wir schnell genug auf ernste Probleme?
Wo sind zusätzliche Investitionen nötig?
Ein guter vulnerability management-Bericht bedient beide Gruppen. Er gibt der Leitungsebene ein klares Bild von Sicherheitsstatus und Trends und liefert den Fachleuten zugleich die Details, die sie zur Behebung brauchen.
Vulnerability-Berichte auf Compliance-Frameworks abbilden
Auditoren und Compliance-Teams brauchen Vulnerability-Berichte, um die Wirksamkeit von Kontrollmaßnahmen zu belegen. So lassen sich Berichte gängigen Frameworks zuordnen:
SOC 2 Type II
CC6.1 (logischer Zugriff): belegt das vulnerability management für Identitäts- und Zugriffssysteme;
CC7.1 (Systemüberwachung): zeigt kontinuierliches Scannen und Alerting;
benötigte Nachweise: Scan-Frequenz, Behebungs-SLAs, Nachverfolgung von Ausnahmen.
ISO 27001 Anhang A.12.6.1
Kontrollmaßnahme für das technische Schwachstellenmanagement;
benötigte Nachweise: Prozess zur Identifikation von Schwachstellen, Priorisierungskriterien, Nachverfolgung der Behebung, Management-Review des Schwachstellenstatus.
NIST 800-53
RA-5 (vulnerability scanning): Scan-Frequenz, Abdeckung, authentifizierte Scans;
SI-2 (Behebung von Fehlern): Behebungsfristen, patch management, Prozess der Risikoakzeptanz;
CM-8 (Systeminventar): Ressourcen-discovery und Genauigkeit des Inventars.
PCI DSS 4.0
Anforderung 11.3.1: vierteljährliche externe Vulnerability-Scans durch einen Approved Scanning Vendor (ASV);
Anforderung 11.3.2: Scans nach wesentlichen Änderungen an der Umgebung;
Anforderung 6.3.3: Prüfung der Schwachstellen und Zuweisung von Risikoeinstufungen.
Eine Compliance-Zuordnungstabelle im Bericht zeigt, welche Kontrollmaßnahmen jeder Scan erfüllt und wann der nächste Scan fällig ist.
Wie Wiz Scan-Daten in kontextbezogene Berichte verwandelt
Wiz UVM ist darauf ausgelegt, genau dieses Problem zu lösen: zu viele Funde, zu wenig Kontext. Die Lösung liefert umfassende Abdeckung und kontextbezogene Priorisierung über einen agentless Ansatz für virtual machines, Container, serverless und On-Premises-Ressourcen – ergänzt um den Wiz Sensor zur Validierung in der Runtime. Statt nur CVEs aufzulisten, baut Wiz einen Security Graph der gesamten Umgebung auf, sodass sich Maßnahmen an dem ausrichten, was wirklich ausnutzbar ist.
Der Security Graph verbindet:
Cloud- und On-Premises-Ressourcen über virtual machines, Container, serverless, Datastores und Identitäten hinweg;
Schwachstellen aus dem agentless Workload Scanning von Dateisystemen und dependencies;
Quellcode-Probleme über Wiz Code (natives SAST und Quellcode-Scanning);
Validierungssignale aus der Runtime über den Wiz Sensor, um aktiv geladene, verwundbare Pakete zu bestätigen;
Fehlkonfigurationen, offengelegte Secrets und Malware;
Netzwerk-Angriffsfläche und internetseitigen Kontext sowie Identitätsberechtigungen;
threat intelligence aus über 20 laufend aktualisierten Schwachstellendatenbanken, darunter die NVD des NIST, um bekannte Exploits und verfügbare Fixes hervorzuheben;
eingelesene Funde aus klassischen Scannern für eine vereinheitlichte Sicht.
Der „Bericht" wird so zu einer einzigen, priorisierten Risikoliste auf Basis des Security Graph. Statt „hier sind 500 kritische CVEs" erscheint: „diese exponierte VM mit einer kritischen RCE kann über diesen Pfad diese sensible Datenbank erreichen – zuerst beheben, weil das eine vollständige Angriffskette ist." Direkt auf der Seite Explorer > Vulnerabilities lassen sich die Ergebnisse erkunden, filtern und exportieren, als CSV oder über die API ausgeben und als compliance-fertige POA&M-Vulnerability-Berichte mit detaillierten CVE-Daten, Beschreibungen, bekannten Exploits und nach Schweregrad priorisierten Fixes erstellen.
Von dort aus unterstützt Wiz die Operationalisierung:
Probleme lassen sich über Projekt-, Service- und code repository-Kontext den richtigen Verantwortlichen zuweisen – die code-to-cloud-Herkunft führt einen laufenden Workload zurück zum Team des Quellcodes.
Fix-fertige Aufgaben fließen in bestehende Ticketing- und ITSM-Workflows, Benachrichtigungen laufen automatisiert über Kanäle für security automation und Zusammenarbeit, und SLAs setzen sich über deduplizierte Tickets und POA&M-Tracking durch.
Wo unterstützt, automatisiert Wiz die Behebung und verfolgt Fortschritt, Ausnahmen und den gesamten Sicherheitsstatus über alle Cloud- und On-Premises-Umgebungen hinweg.
So entsteht die Klarheit eines Berichts und die Tiefe einer lebendigen, vernetzten Sicht – agentless im Ansatz, in der Runtime über den Wiz Sensor validiert und über Cloud und On-Premises hinweg vereinheitlicht, um das Risiko messbar zu reduzieren. Wiz UVM verwandelt Scan-Rauschen in priorisierte, fix-fertige Maßnahmen – jetzt eine Demo anfragen.