Rund 26.000 neue CVEs wurden im Jahr 2025 veröffentlicht. Diese Zahl verlangsamt sich 2026 nicht – sie beschleunigt sich. Wer keine aktiven Scans nach bekannten Schwachstellen durchführt, betreibt kein Risikomanagement, sondern hofft einfach auf das Beste. OpenVAS ist seit über einem Jahrzehnt ein Eckpfeiler des Open-Source-Schwachstellenscans und bleibt trotz der Flut kommerzieller Alternativen ein ernstzunehmendes Werkzeug. Die Frage ist nicht, ob es gut ist – sondern ob es für Ihre spezifische Situation das Richtige ist.
Dieser Leitfaden erklärt, was OpenVAS wirklich ist, wie es unter der Haube funktioniert, wie es im Vergleich zu anderen Schwachstellenscannern abschneidet und wo seine tatsächlichen Grenzen liegen. Kein Vendor-Hype. Nur die technische Realität.
Was ist OpenVAS wirklich?
OpenVAS – Open Vulnerability Assessment System – entstand 2005 als Fork von Nessus, nachdem Tenable den Quellcode schloss. Heute wird es von Greenbone Networks gepflegt und dient als Scan-Engine hinter der Greenbone Community Edition. Die Architektur hat sich erheblich weiterentwickelt, aber das Grundkonzept bleibt: authentifiziertes und nicht-authentifiziertes Netzwerk-Scanning gegen einen kontinuierlich aktualisierten Feed von Network Vulnerability Tests (NVTs).
Mitte 2026 enthält der Greenbone Community Feed über 160.000 NVTs, die CVEs, Konfigurationsschwächen, Standard-Anmeldeinformationen und Service-Fehlkonfigurationen abdecken. Diese Tests laufen über den OpenVAS Scanner Daemon (ospd-openvas), der über die GVM-API-Schicht verwaltet wird. Der Stack ist: GVM → ospd-openvas → OpenVAS Scanner. Die Weboberfläche GSA sitzt oben auf GVM.
Was OpenVAS wirklich leistungsfähig macht, ist das authentifizierte Scannen. Geben Sie Anmeldedaten an – SSH, SMB, ESXi – und es prüft nicht nur offene Ports, sondern meldet sich an und inspiziert installierte Pakete, Registry-Schlüssel, laufende Dienste und Patch-Stände. So finden Sie CVE-2024-21338 auf einem Windows-Host, der von außen unauffällig wirkt, aber einen verwundbaren Kernel-Treiber ungepacht enthält.
Installation und Erstkonfiguration
Der einfachste Weg, OpenVAS 2026 zu betreiben, ist der Greenbone Community Containers-Ansatz mit Docker Compose. Vergessen Sie die alten apt-basierten Installationen – Dependency Hell auf Ubuntu 22.04 ist real. Der containerisierte Stack startet GVM, ospd-openvas, die PostgreSQL-Datenbank und den Redis-Feed-Cache als separate Services. Die erste NVT-Feed-Synchronisation dauert je nach Bandbreite 30–60 Minuten. Folgesynchronisierungen sind inkrementell.
Für Bare-Metal- oder VM-Deployments bleibt Kali Linux die reibungsloseste Option, da Greenbone-Pakete im Kali-Repo gepflegt werden. Wer OpenVAS in TryHackMe-Labs verwendet, kennt den gvm-setup/gvm-check-setup-Workflow gut. Kritischer Konfigurationsschritt: Passen Sie die Scanner-Einstellungen an. Die Standard-Scan-Konfiguration Full and Fast balanciert Abdeckung und Geschwindigkeit, aber für Produktionsumgebungen sollten Sie diese Konfiguration kopieren, störende NVTs deaktivieren und angemessene Timeouts pro Host setzen.
OpenVAS im Vergleich zur Scan-Tool-Landschaft
OpenVAS versus Nessus: Tenable hat über 200.000 Plugins gegenüber ~160.000 NVTs. Die EPSS-Integration von Tenable ist für die Priorisierung besser. Nessus Essentials ist auf 16 IPs begrenzt; darüber hinaus kostet Nessus Professional rund 3.990 $/Jahr. OpenVAS ist kostenlos. Für ein Startup mit 200 internen Hosts und knappes Budget liegt die Entscheidung auf der Hand.
OpenVAS versus Nuclei: Nuclei von ProjectDiscovery ist ein Template-basierter Scanner, der auf Anwendungsschicht- und Web-Schwachstellen spezialisiert ist. Kein Ersatz für OpenVAS, sondern eine Ergänzung. Nuclei glänzt bei API-Endpoint-Tests und CVE-spezifischen Web-Probes, OpenVAS dominiert beim Infrastruktur- und Host-Level-Scanning.
Für Container-Scanning ist weder OpenVAS noch Nuclei das richtige Werkzeug. Container Image Scanning erfordert einen grundlegend anderen Ansatz – die Inspektion von Layer-Manifests, OS-Paketen und Sprachabhängigkeiten innerhalb des Images. OpenVAS und ein laufender Container-Service sind hier klar nicht gleichbedeutend.
Vulnerability-Management-Workflow mit OpenVAS
Ein Scanner, der einmal pro Quartal läuft, ist ein Compliance-Häkchen, kein Sicherheitskontrollmechanismus. Effektives Vulnerability Management erfordert eine Scan-Frequenz, die auf die Änderungsrate Ihrer Umgebung abgestimmt ist. Wenn Sie täglich in die Produktion deployen, sollten Scans mindestens wöchentlich stattfinden und bei jedem bedeutenden Deployment ausgelöst werden.
Beim Umgang mit False Positives: OpenVAS erzeugt sie. Das ist kein einzigartiger Fehler – jeder Scanner tut das. Die Disziplin liegt im Triage. Erstellen Sie Suppression-Listen für bekannte False Positives. Nutzen Sie CVSS v3.1-Basiswerte als Ausgangspunkt, aber gehen Sie nicht weiter. Ein CVSS 9.8 ohne Netzwerkzugang und ohne öffentlichen Exploit ist weniger dringlich als ein CVSS 7.5 mit EPSS-Score 0,94 und einem Metasploit-Modul.
Für die Integration in CI/CD stellt die GVM Python Library (gvm-tools) eine skriptfähige API bereit. Kombinieren Sie dies mit SAST-Tooling für Code-Level-Befunde und Sie haben eine solide Shift-Left-Strategie.
OpenVAS und Cloud-Umgebungen
Cloud-Umgebungen erfordern mehr als traditionelle Netzwerkscanner bieten können. Ephemere Instanzen, Auto-Scaling-Gruppen und Serverless-Funktionen bleiben nicht lange genug stehen, damit ein geplanter Scan sie erfassen kann. OpenVAS kann Cloud-Instanzen wie On-Prem-Hosts scannen – aber es hat kein Bewusstsein für Cloud-Posture, IAM-Fehlkonfigurationen, Storage-Bucket-Policies oder Network-Security-Group-Drift.
Hier wird dediziertes CSPM-Tooling unverzichtbar. Wenn Ihr Security-Stack nur OpenVAS umfasst und Sie Workloads in AWS, GCP oder Azure betreiben, haben Sie einen erheblichen blinden Fleck. Ergänzen Sie OpenVAS durch eine Posture-Management-Schicht, die Cloud-native Konstrukte versteht.
OpenVAS in Compliance-Kontexten
PCI-DSS 4.0 erfordert vierteljährliche externe Scans durch einen Approved Scanning Vendor – OpenVAS qualifiziert sich nicht als ASV. NIS2 Artikel 21 fordert technische Schwachstellenmaßnahmen, schreibt aber keine Tools vor. ISO 27001:2022 Annex A Control 8.8 ist ebenfalls tool-agnostisch. OpenVAS unterstützt Ihre Compliance-Lage, erfüllt aber keine ASV-spezifischen Anforderungen. Wenn Sie Compliance-Anforderungen über mehrere Frameworks hinweg navigieren, dokumentieren Sie Scan-Konfigurationen, Aufbewahrungsfristen und Remediation-SLAs explizit.
Wann über OpenVAS hinausgehen?
OpenVAS ist richtig für: kleine bis mittlere Umgebungen, budgetbeschränkte Teams und Organisationen, die ihr erstes strukturiertes Vulnerability-Management-Programm aufbauen. Es gerät an seine Grenzen bei 10.000+ Hosts, Multi-Cloud-Umgebungen und Kontexten, in denen auditgerechte Berichte obligatorisch sind.
Die VM Scans-Funktionalität moderner Plattformen integriert Vulnerability-Befunde mit Asset-Inventar, Cloud-Kontext und Remediation-Workflows auf eine Weise, die ein eigenständiges OpenVAS-Deployment nicht bieten kann. Das macht OpenVAS nicht obsolet – es bedeutet, die Grenzen des Tools zu kennen und Ihre Programmarchitektur entsprechend aufzubauen.