Schwachstellenscanner - Definition & Erklärung

Schwachstellenscanner sind automatisierte Werkzeuge, die IT-Infrastrukturen systematisch auf bekannte Sicherheitslücken untersuchen. Sie bilden das Fundament eines jeden Schwachstellenmanagement-Programms - können aber keinen manuellen Penetrationstest ersetzen.

Wie Schwachstellenscanner funktionieren

Scan-Ablauf:

Discovery: Welche Hosts/Ports sind aktiv? (Nmap-Basis)
Fingerprinting: Welches OS? Welche Software-Version?
Matching: Gegen CVE-Datenbank (NVD, Vendor-DBs)
Validation: Ist die Schwachstelle wirklich vorhanden? - Aktiv: Exploit-Versuch (authenticated/unauthenticated); Passiv: Version-Check gegen Known-Vulnerable-Ranges
Reporting: CVSS-Score, Beschreibung, Empfehlung

Scan-Modi:

Unauthenticated (extern): Simuliert Angreifer ohne Zugangsdaten - findet offene Ports, fehlende SSL, bekannte Web-Vulns; übersieht Konfigurationsfehler intern, fehlende Patches intern
Authenticated (intern, empfohlen): Scanner hat Zugang (SSH, WMI, SNMP-Credentials) - findet installierte Pakete, Registry-Einstellungen, Patch-Status; 3-5x mehr Findings als unauthenticated

Die wichtigsten Scanner im Vergleich

Tool	Typ	Stärken	Schwächen
Tenable Nessus	Kommerziell	Marktführer, 100.000+ Plugins	Teuer (ab €3.500/Jahr)
Qualys VM	Cloud/SaaS	Keine eigene Infrastruktur, Cloud-Assets	Abhängigkeit von Cloud
Rapid7 InsightVM	Kommerziell	Live-Reporting, SIEM-Integration	Komplex zu konfigurieren
OpenVAS/Greenbone	Open Source	Kostenlos, selbst gehostet	Setup-Aufwand, weniger Plugins
Wazuh	Open Source	SIEM + Scanner kombiniert	Kein tiefes Vuln-Scanning
Nikto	Open Source	Web-Server-spezifisch, schnell	Kein Netzwerk-Scan
Nuclei	Open Source	Template-basiert, erweiterbar	Erfordert Template-Pflege

Nessus - Praxisbeispiel

# Nessus CLI (nessuscli) - Basis-Befehle
# Scan starten
nessuscli scan new --name "Internal Q1 2026" \
  --policy "Internal Network Scan" \
  --targets "192.168.0.0/24"

# Ergebnisse exportieren
nessuscli export --scan "Internal Q1 2026" \
  --format csv --output /tmp/scan-results.csv

# Typische Nessus-Ausgabe:
# Plugin ID | Risk  | Host          | Protocol | Port | Name
# 55024     | CRIT  | 192.168.1.25 | tcp      | 443  | SSL Version 2 and 3 Protocol Detection
# 48760     | HIGH  | 192.168.1.10 | tcp      | 445  | MS17-010 EternalBlue
# 38664     | HIGH  | 192.168.1.15 | tcp      | 80   | Apache Struts RCE

OpenVAS - Open Source Alternative

# OpenVAS via Docker (Greenbone Community Edition)
docker run -d --name openvas \
  -p 8080:9392 \
  -e PASSWORD="admin123" \
  mikesplain/openvas

# gvm-cli - Automatisierung
gvm-cli --gmp-username admin --gmp-password admin123 \
  socket --socketpath /run/gvm/gvmd.sock \
  --xml "<get_tasks/>"

# Greenbone Report via API
curl -u admin:admin123 \
  "https://localhost:9390/omp?cmd=get_reports&report_id=xxx&format_id=c402cc3e-b531-11e1-9163-406186ea4fc5" \
  -o report.pdf -k

CVSS-Priorisierung

CVSS Score	Priorität	SLA
9.0-10.0	Critical	Patch innerhalb 24-48h
7.0-8.9	High	Patch innerhalb 7 Tage
4.0-6.9	Medium	Patch innerhalb 30 Tage
0.1-3.9	Low	Patch im nächsten Zyklus (90 Tage)
0.0	None	Informational, kein Action-Item

Aber CVSS allein reicht nicht: Priorität = CVSS Score × Exploitability × Asset-Kritikalität

CVE-2024-XXXX: CVSS 7.5 (HIGH) auf Produktionsdatenbank → Priorität KRITISCH (kritisches Asset + exploitbar)
CVE-2024-YYYY: CVSS 9.1 (CRITICAL) auf Testsystem ohne Internet → Priorität MEDIUM (isoliertes Asset, kein externer Zugriff)

Scanner vs. Penetrationstest

Schwachstellenscanner:

Breite Abdeckung (gesamte Infrastruktur)
Regelmäßig wiederholbar (täglich/wöchentlich)
Günstig in der Folgeanwendung
Viele False Positives
Keine Kontextualisierung
Kein Business Logic Testing
Kein Privilege Escalation Testing
Keine verketteten Angriffspfade

Penetrationstest:

Tiefe, kontextuelle Analyse
Verkettete Angriffspfade (wie ein echter Angreifer)
Manuelle Validierung - keine False Positives
Business Logic Schwachstellen
Social Engineering Tests möglich
Teuer (5.000-50.000 EUR)
Nur Snapshot (nicht kontinuierlich)
Begrenzte Abdeckung (Scope)

Best Practice: Kontinuierliches Schwachstellenscanning (automatisch) + jährlicher Penetrationstest (manuell) + nach major Changes erneuter Pentest des geänderten Bereichs.

Scan-Häufigkeit (BSI Empfehlung)

Bereich	Häufigkeit
Intern / Endpoints	Monatlich
DMZ / Exposed Services	Wöchentlich
Webapplikationen (DAST)	Bei jedem Release + monatlich
Cloud-Assets	Kontinuierlich (CSPM)
Kritische Infrastruktur	Wöchentlich

Nach Ereignissen sofortiger Scan: neue kritische CVE (CVSS ≥ 9.0), Netzwerkänderungen, neue Systeme im Scope.

Integration in CI/CD

# GitHub Actions - Trivy für Container-Images
- name: Vulnerability Scan
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'  # Pipeline-Abbruch bei kritischen Findings

# Ergebnis in GitHub Security Tab
- uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: 'trivy-results.sarif'

# OWASP ZAP - Web Application DAST
- name: ZAP Scan
  uses: zaproxy/action-full-scan@v0.10.0
  with:
    target: 'https://staging.example.com'
    rules_file_name: '.zap/rules.tsv'
    cmd_options: '-a'

Häufige Fehlalarme (False Positives)

SSL_RC4_CIPHER_SUITES_SUPPORTED: Konfiguration bereits geändert, Scanner-Cache veraltet → Lösung: Authentifizierten Scan durchführen
MS17-010 (EternalBlue): Firewall blockiert SMB (445) - nicht ausnutzbar → Lösung: Netzwerk-Kontext dokumentieren, als accepted risk markieren
Default Credentials: Test-Account explizit für Scanner-Zugang → Lösung: Scanner-Credentials aus Scope ausschließen

Faustregel: False-Positive-Rate kommerziell 5-15%, Open Source 15-30% - manuelle Validierung kritischer Findings ist immer Pflicht.