Kurz gesagt: Ein Schwachstellenscan prüft Systeme automatisiert auf bekannte Schwachstellen: schnell, günstig und als Momentaufnahme. Er beweist aber nicht, ob eine Lücke real ausnutzbar ist. Genau das leistet erst ein Penetrationstest, und dauerhafte Abdeckung erst ein kontinuierliches Exposure Management.
→ Schwachstellenscan und Exposure Management mit uns besprechen: kostenloser 30-minütiger Scoping-Call.
„Schwachstellenscan“, „Vulnerability Assessment“, „Penetrationstest“, „Vulnerability Management“: diese vier Begriffe werden ständig durcheinandergeworfen. Manchmal aus Unkenntnis, oft aber bewusst: Mancher Anbieter verkauft einen einfachen Scan als Assessment oder eine oberflächliche Analyse als Pentest. Wer die Unterschiede kennt, schützt sich vor genau dieser Mogelpackung.
Was ein Schwachstellenscan ist
Ein Schwachstellenscan prüft mit spezialisierter Software Netzwerke und Systeme auf bekannte Schwachstellen und gleicht die Funde mit Schwachstellendatenbanken ab. Man unterscheidet:
- Externe Scans: IP-Adressen und offene Ports von außen
- Interne Scans: Konfigurationsfehler und schwache Passwörter von innen
Der Scan ist automatisiert, schnell und günstig und liefert eine Momentaufnahme.
Wie ein Scanner technisch arbeitet
Das Verständnis der Arbeitsweise erklärt zugleich die Grenzen. Ein Scan läuft in drei Phasen:
1. Erkennung. Welche Systeme antworten überhaupt? Der Scanner ermittelt erreichbare Hosts und offene Ports.
2. Fingerprinting. Was läuft dort? Anhand von Antwortmustern, Bannern und Protokollverhalten schließt der Scanner auf Produkt und Version: zum Beispiel „Webserver X, Version 1.2.3“.
3. Abgleich. Für diese Version werden bekannte Schwachstellen nachgeschlagen und als Befund gemeldet.
Der entscheidende Punkt steckt in Schritt drei: Der Scanner schließt in vielen Fällen von der Version auf die Verwundbarkeit, ohne die Lücke tatsächlich auszulösen. Das ist gewollt, ein Scan soll nichts kaputt machen. Es bedeutet aber, dass ein Befund eine begründete Vermutung ist, kein Beweis.
Authentifiziert oder nicht: der größte Unterschied im Ergebnis
Dies ist die folgenreichste Einstellung eines Scans, und sie wird selten diskutiert.
Ein nicht-authentifizierter Scan sieht ein System so, wie ein Fremder es sieht: von außen, ohne Anmeldedaten. Er findet exponierte Dienste und offensichtliche Schwächen: mehr nicht.
Ein authentifizierter Scan meldet sich mit Zugangsdaten an und liest den tatsächlichen Zustand aus: installierte Softwarestände, fehlende Patches, Konfigurationseinstellungen, lokale Richtlinien. Das Ergebnis ist typischerweise um ein Vielfaches umfangreicher und deutlich genauer, weil es nicht mehr auf Vermutungen beruht.
Die praktische Konsequenz: Wenn Ihr Dienstleister ausschließlich nicht-authentifiziert scannt, bekommen Sie ein Bild der Außenansicht und keines vom Zustand Ihrer Systeme. Fragen Sie explizit nach, welcher Modus verwendet wird.
Was Scanner systematisch übersehen
Kein Scanner der Welt findet die folgenden Dinge, weil sie außerhalb dessen liegen, was Signaturabgleich leisten kann:
- Fehler in der Geschäftslogik. Wenn sich durch Manipulation einer Bestellnummer fremde Rechnungen aufrufen lassen, ist das eine schwere Lücke und für den Scanner eine völlig normale HTTP-Antwort.
- Verkettete Schwachstellen. Drei für sich harmlose Befunde ergeben zusammen einen Weg zum Domänenadministrator. Der Scanner bewertet jeden Befund isoliert.
- Individualsoftware. Für Eigenentwicklungen existieren keine Signaturen.
- Zugriffskontrollfehler. Ob ein Nutzer Daten sehen darf, die er nicht sehen sollte, kann ein Scanner nicht beurteilen. Er kennt Ihr Berechtigungsmodell nicht.
- Alles, wofür noch keine Signatur existiert. Ein Scan prüft gegen Bekanntes. Was gestern veröffentlicht wurde, ist morgen prüfbar.
Ebenfalls außerhalb der Reichweite: Fehlkonfigurationen in Cloud-Diensten. Ein zu weit freigegebener Speicher-Bucket oder ein ungehärteter Kubernetes-Cluster ist technisch fehlerfrei, nur eben falsch eingestellt. Dazu S3 Bucket Security und Sicherheit in Azure Kubernetes Service.
Dazu kommen die beiden Fehlerarten, mit denen jeder Betrieb umgehen muss: False Positives, die Zeit kosten und irgendwann dazu führen, dass Berichte nicht mehr gelesen werden, und False Negatives: Lücken, die nicht gemeldet wurden und deren Fehlen niemand bemerkt.
Scan vs. Assessment
Ein Vulnerability Assessment geht weiter: Hier prüfen Sicherheitsanalysten die Scan-Ergebnisse manuell, ordnen sie in den Geschäftskontext ein und bewerten ihre tatsächliche Relevanz. Der Scan liefert die Rohdaten, das Assessment die Interpretation.
Praktisch heißt das: False Positives werden aussortiert, Befunde werden zusammengeführt und danach bewertet, was sie für Ihr Unternehmen bedeuten, nicht danach, was die Datenbank an Schwere hinterlegt hat.
Scan vs. Penetrationstest
Der entscheidende Unterschied: Ein Penetrationstest umfasst eine Exploit-Phase. Der Tester versucht aktiv einzudringen und beweist, ob eine Schwachstelle real ausnutzbar ist, nicht nur, ob sie theoretisch existiert. Ein Scan sagt „hier könnte ein Problem sein“; ein Pentest sagt „hier ist ein Problem, und so weit komme ich damit“.
Was ein solcher Test kostet und wovon der Preis abhängt, steht in Was kostet ein Penetrationstest?.
Dieser Unterschied ist nicht akademisch. Er entscheidet darüber, ob eine Diskussion mit dem Fachbereich mit „der Scanner meldet etwas“ beginnt oder mit „hier ist der Datensatz, den wir darüber ausgelesen haben“. Das zweite Gespräch verläuft anders.
Scan vs. Vulnerability Management
Vulnerability Management schließlich ist kein Einzelereignis, sondern ein kontinuierlicher Kreislauf: erkennen, bewerten, beheben, erneut prüfen. Erst dadurch werden Trends sichtbar und langfristige Verbesserung messbar.
Der Wert liegt in der Wiederholung: Ein einzelner Scan sagt, wie es heute aussieht. Eine Reihe von Scans sagt, ob Sie besser werden und ob Befunde tatsächlich verschwinden oder nur von Bericht zu Bericht weitergereicht werden.
Priorisierung: Der Schweregrad ist nicht das Risiko
Ein typischer Erstbericht enthält hunderte oder tausende Befunde. Wer sie nach CVSS-Score von oben nach unten abarbeitet, arbeitet an der falschen Reihenfolge.
CVSS beschreibt die technische Schwere unter Laborbedingungen. Für die Frage, was zuerst dran ist, brauchen Sie drei weitere Signale:
- Wird sie real ausgenutzt? Der KEV-Katalog der US-Behörde CISA listet Schwachstellen mit belegter aktiver Ausnutzung.
- Wird sie wahrscheinlich ausgenutzt? EPSS schätzt die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen.
- Wie erreichbar ist das System? Dieselbe Lücke bedeutet am Perimeter etwas anderes als auf einem internen Testsystem.
Aus tausend Befunden werden so meist einige Dutzend, die wirklich dringend sind. Genau das ist der Übergang von einer Schwachstellenliste zu einer Risikoentscheidung.
Was für welche Anforderung passt
| Verfahren | Aufwand | Beweist Ausnutzbarkeit | Typischer Einsatz |
|---|---|---|---|
| Einzelner Scan | gering | nein | schnelle Momentaufnahme |
| Zyklisches Assessment | mittel | nein | wiederkehrende Nachweispflichten |
| Vulnerability Management | laufend | nein | dauerhafte Abdeckung, messbarer Fortschritt |
| Penetrationstest | hoch | ja | vor Go-live, nach größeren Änderungen, für belastbare Aussagen |
- Einzelner Scan: schnelle, günstige Momentaufnahme
- Zyklisches Assessment: erfüllt Compliance-Anforderungen wie PCI DSS und ISO 27001
- Managed Vulnerability Management: umfassende, kontinuierliche Abdeckung
- Penetrationstest: periodisch, besonders bei Änderungen an Netzwerk oder Anwendungen
Was Regulierung tatsächlich verlangt
Die einschlägigen Rahmenwerke fordern durchgehend ein Verfahren, selten ein bestimmtes Werkzeug:
- PCI DSS verlangt regelmäßige interne und externe Schwachstellenscans, wobei externe Scans durch einen zugelassenen Dienstleister durchzuführen sind.
- ISO/IEC 27001:2022 adressiert in Anhang A das Management technischer Schwachstellen: also den Prozess, nicht das Produkt.
- NIS2 verlangt in Art. 21 Abs. 2 Buchst. e Sicherheit bei Erwerb, Entwicklung und Wartung einschließlich Behandlung und Offenlegung von Schwachstellen, und in Buchst. f Verfahren zur Bewertung der Wirksamkeit der Maßnahmen.
Ein Scan-Bericht in der Schublade erfüllt keine dieser Anforderungen. Nachgewiesen wird ein Kreislauf: erkennen, priorisieren, beheben, nachweisen. Welche Anforderungen aus NIS2 und DORA welche Leistung abdeckt, steht unter NIS2 & DORA.
Wie oft sollte gescannt werden?
Als praxistaugliche Ausgangsregel:
- Extern erreichbare Systeme: kontinuierlich oder wöchentlich. Hier ist das Zeitfenster zwischen Veröffentlichung und Angriff am kürzesten.
- Interne Systeme: monatlich, authentifiziert.
- Nach jeder wesentlichen Änderung: neue Systeme, geänderte Freigaben, Migrationen.
Wichtiger als die Frequenz ist allerdings die Vollständigkeit des Bestands: Ein wöchentlicher Scan über 80 Prozent Ihrer Systeme ist schlechter als ein monatlicher über alle. Wie schnell Patchen auf Befunde folgen sollte, steht in Cloud Patch Management.
Wie Cloud Cape unterstützt
Wir nennen die Dinge beim Namen und verkaufen keinen Scan als Pentest. Vor allem aber denken wir Schwachstellen nicht als Liste, sondern als Exposure: kontinuierlich erkennen, nach echtem Risiko priorisieren und durch reale Angriffstechniken validieren. Genau das leistet unser Continuous Threat Exposure Management und wo der Beweis der Ausnutzbarkeit zählt, ergänzt es unser Pentesting & Red Teaming.
Sprechen Sie mit uns über Exposure Management. Wir machen aus Scan-Ergebnissen priorisierte Risikoentscheidungen.