Zum Hauptinhalt springen

Greenbone-/OpenVAS-Guide

Worum geht's?

Greenbone ist nicht nur ein Schwachstellen-Scanner. Es ist ein umfassenderer Vulnerability-Management-Stack mit Open-Source-Kernkomponenten, kommerziellen Appliances und Services, täglichen Feed-Inhalten, Web-Management, APIs und Automatisierungs-Tooling. Dieser Guide gibt dir eine verifizierte Übersicht über die aktuellen Produkte, die Open-Source-Architektur, die wichtigsten Repositories, die unterstützten Installationspfade und einen kompakten Betriebs-Workflow für deine ersten Scans.

Quellenstand: 25. Juni 2026

Dieser Guide basiert auf den offiziellen Produktseiten von Greenbone, den Dokumentationsportalen, der OpenVAS-Projektseite, der offiziellen GitHub-Organisation und Greenbone-Dokumenten. Einige wichtige Unterscheidungen sind in den offiziellen Quellen aktuell:

  • Die kommerzielle Produktfamilie wird auf der öffentlichen Produktseite als OPENVAS vermarktet.
  • Der Open-Source-Stack ist als Greenbone Community Edition dokumentiert, historisch auch bekannt als OpenVAS oder GVM.
  • Greenbones eigene Community-Dokumentation stellt ausdrĂĽcklich fest, dass sowohl der Container-Guide als auch der Build-from-Source-Guide nicht fĂĽr Produktivumgebungen gedacht sind.

In diesem Abschnitt​

Diese Seite ist der konzeptionelle Ăśberblick. Die folgenden Guides gehen ins operative Detail, basierend auf den offiziellen Greenbone-HandbĂĽchern (Appliance-Handbuch GOS 22.04 / OPENVAS SCAN 22.04 und das Handbuch zum Greenbone Cloud Service):

Installation & Administration

Täglicher Betrieb

Fortgeschritten & Referenz

1. Das mentale Modell​

Du vermeidest viel Verwirrung, wenn du diese vier Schichten voneinander trennst:

SchichtWas es istAm besten fĂĽr
OpenVAS ScannerDie Scan-Engine, die Schwachstellentests gegen Ziele ausfĂĽhrtDas eigentliche Scannen
Greenbone Community EditionDas Open-Source-Framework rund um den Scanner: gvmd, gsa, Feeds, Protokolle, ToolingLabore, Entwicklung, Integration, selbstverwalteter Community-Einsatz
OPENVAS kommerzielle ProdukteGreenbones produktisierte Angebote wie OPENVAS BASIC und OPENVAS SCANUnterstützter geschäftlicher Einsatz, schnellerer Rollout, Enterprise-Betrieb
Feeds, APIs und ToolingCommunity-/Enterprise-Feed-Daten sowie GMP-/OSP-APIs und CLI-/Python-BibliothekenAutomatisierung, Integrationen, eigene Workflows

Mit anderen Worten:

  • OpenVAS kann nur den Scanner bedeuten,
  • oder historisch das umfassendere Open-Source-Framework,
  • während Greenbone Community Edition der klarere aktuelle Oberbegriff fĂĽr die Open-Source-Seite ist,
  • und OPENVAS BASIC / SCAN / kommende Produkte die kommerzielle Produktlinie sind.

2. Aktuelle Produktübersicht​

Greenbones offizielle Produktseite hebt derzeit diese Angebote hervor:

ProduktPositionierungHinweise
OPENVAS BASICEinstiegsprodukt fĂĽr kleine Unternehmen und EinzelnutzerEinfaches Onboarding, vereinfachter Betrieb, geringerer Funktionsumfang
OPENVAS SCANHauptprodukt zum Scannen für Wirtschaft und öffentlichen SektorHardware- oder virtuelle Appliance, umfangreichere Enterprise-Funktionen
OPENVAS SECURITY INTELLIGENCEZentrale Intelligence- und Management-SchichtMarkiert als coming soon
OPENVAS AIKI-gestützte Planung der BehebungMarkiert als kommende Lösung

Begleitende offizielle Dokumentation verweist auĂźerdem auf:

  • Greenbone Community Edition
  • Greenbone Cloud Service
  • OPENVAS REPORT
  • OPENVAS OS
  • OPENVAS FREE im Dokumentenportal

Was die offiziellen Produktseiten jetzt sagen​

OPENVAS BASIC

  • positioniert als schneller und wenig komplexer Einstiegspunkt,
  • tägliche Sicherheitstests,
  • automatisierte Scans,
  • ĂĽbersichtliche Berichte,
  • einfacher Betrieb,
  • explizite Abstriche gegenĂĽber OPENVAS SCAN: keine Sensoren, kein API-Zugriff, keine Remediation-Tickets, kein inkludierter Support.

OPENVAS SCAN

  • positioniert fĂĽr Unternehmen und öffentliche Einrichtungen,
  • Hardware- oder virtuelle Bereitstellung,
  • authentifiziertes Endpoint-Scanning,
  • Scannen von Container-Images,
  • offene APIs und Konnektoren,
  • skalierbare Architektur,
  • agentenbasiertes Scannen,
  • Air-Gapped-Deployment-Möglichkeiten fĂĽr Appliance-Setups.

OPENVAS SECURITY INTELLIGENCE wird als zentrale Plattform fĂĽr verteiltes Vulnerability Management beschrieben, die Ergebnisse mehrerer OPENVAS-SCAN-Systeme konsolidiert und Befunde mit CSAF- und SBOM-Daten anreichert.

OPENVAS AI wird als lokal betriebene KI-Schicht positioniert, die Scan-Ergebnisse in priorisierte Maßnahmenpläne umwandelt, ohne dass Daten das Netzwerk verlassen.

3. Open-Source-Architektur​

Greenbones Community-Dokumentation beschreibt die Community Edition als Multi-Service-Framework mit drei Hauptbestandteilen:

  1. ausfĂĽhrbaren Scanner-Anwendungen,
  2. gvmd,
  3. GSA mit gsad.

Kernkomponenten​

KomponenteRolle
openvas-scannerFĂĽhrt Schwachstellentests gegen Ziele aus
ospd-openvasOSP-Daemon, der es gvmd ermöglicht, den Scanner zu steuern
gvmdZentraler Manager; speichert Konfiguration und Ergebnisse in PostgreSQL; verwaltet Benutzer, Rollen, Berechtigungen, Scheduling und Management-Logik
GSAWeb-Frontend
gsadWeb-Daemon / Zugriffsschicht, ĂĽber die die GSA mit gvmd kommuniziert
Notus ScannerSchnellere Abwicklung lokaler SicherheitsprĂĽfungen durch Abgleich installierter Software mit Listen bekannter verwundbarer Software
gvm-toolsCLI-Tooling fĂĽr GMP- und OSP-Zugriff
python-gvmPython-Bibliothek zur Automatisierung von Greenbone-Workflows

Protokolle​

ProtokollZweck
GMPGreenbone Management Protocol; XML-basierte Management-Schnittstelle, die von gvmd bereitgestellt wird
OSPOpen Scanner Protocol; Scanner-Steuerungsprotokoll, das zwischen gvmd und Scanner-Diensten verwendet wird

Das Doku-Portal stellt derzeit bereit:

  • GMP API Version 22.7
  • OSP API Version 25.0

Diese Trennung ist wichtig: Management-Schicht und Scanner-Schicht haben unterschiedliche APIs und Versionsstränge.

4. Verifizierte GitHub-Repositories​

Die offizielle verifizierte GitHub-Organisation ist greenbone, verknĂĽpft mit greenbone.net.

Die relevantesten derzeit in der Org-Ăśbersicht sichtbaren Repositories sind:

RepositoryWofĂĽr es da ist
openvas-scannerScanner-Komponente fĂĽr die Greenbone Community Edition
gvmdGreenbone Vulnerability Manager: Datenbank-Backend / zentraler Manager
gsaGreenbone Security Assistant: Web-Frontend
ospd-openvasOSP-Server-Implementierung zur Steuerung von OpenVAS
gvm-toolsCLI-Zugriff und Fernsteuerungs-Tooling
python-gvmPython-Client-Bibliothek
scanner-apiScanner-API-Definitionen
docsQuelle der Community-Dokumentation

Die Doku- und Architekturseiten verweisen außerdem auf weitere Komponenten-Repositories wie Notus Scanner und gsad. Diese sind Teil der dokumentierten Architektur, auch wenn sie nicht zu den ersten Repositories gehörten, die in der von uns geprüften GitHub-Org-Übersicht auftauchten.

5. Welchen Deployment-Pfad wählen​

Greenbones eigene Quellen verweisen auf drei verschiedene Pfade fĂĽr die Community-/Open-Source-Seite sowie separate kommerzielle Pfade.

PfadAm besten fĂĽrWichtiger Vorbehalt
Community-ContainerSchnelle lokale Evaluierung, Labore, Lernen, Test-SetupsOffiziell nicht fĂĽr Produktivumgebungen gedacht
Build from SourceEntwickler, die am Stack selbst arbeiten oder Kontrolle auf Quellcode-Ebene benötigenOffiziell nicht für Produktivumgebungen gedacht
Kali-Linux-PaketeSecurity-Lab-Setups, schnelle lokale InstallationenDas Packaging wird von Kali / Offensive Security gepflegt, nicht von Greenbone
Kommerzielles OPENVAS SCAN / BASICUnterstützter geschäftlicher EinsatzBeste Wahl, wenn du Support, Appliances, einfacheren Betrieb und Enterprise-Feed-Abdeckung benötigst

Empfohlene Entscheidungslogik​

  • Wähle OPENVAS BASIC, wenn du den schnellsten unterstĂĽtzten Einstiegspunkt fĂĽr eine kleine Umgebung willst.
  • Wähle OPENVAS SCAN, wenn dies eine echte operative Sicherheitsplattform fĂĽr eine Organisation ist.
  • Wähle Community-Container, wenn du den Stack lernen, gegen ihn automatisieren oder Workflows kostengĂĽnstig validieren willst.
  • Wähle Build from Source nur dann, wenn du tatsächlich Entwicklung oder Patching auf Quellcode-Ebene benötigst.
  • Wähle Kali-Pakete fĂĽr Labor- und Security-Workstation-Szenarien, nicht als dein standardmäßiges Produktiv-Deployment-Modell.

6. Community-Container: der praktische Default für die Entwicklung​

Wenn du Entwickler, Integrator oder Lab-Betreiber bist, ist Greenbones Container-Pfad der kĂĽrzeste Weg zu einer funktionierenden Umgebung.

Was die Doku sagt​

Der offizielle Container-Guide stellt fest:

  • Docker-Kenntnisse sind erforderlich,
  • ein grundlegendes Verständnis der Architektur ist erforderlich,
  • der Guide richtet sich an Nutzer, die neue Funktionen testen oder sich mit der Community Edition vertraut machen wollen,
  • er ist nicht fĂĽr Produktivumgebungen gedacht.

Ressourcenanforderungen​

Die offizielle Community-Container-Anleitung nennt:

ProfilCPURAMSpeicher
Minimum2 Kerne4 GB20 GB frei
Empfohlen4 Kerne8 GB60 GB frei

Unterstützte Distributionen im Guide​

  • Debian stable (bookworm)
  • Ubuntu 24.04 LTS
  • Fedora 35 / 36
  • CentOS 9 Stream

Dieselbe Seite weist darauf hin, dass andere Debian-Derivate mit kleinen Anpassungen wahrscheinlich funktionieren.

Wichtige operative Details​

  • Verwende immer die neueste compose.yaml.
  • Das initiale Laden des Feeds kann Minuten bis Stunden dauern.
  • Der Standard-Admin-Benutzer ist admin mit dem Passwort admin, und die Doku empfiehlt dringend, dies sofort zu ändern.
  • Standardmäßig wird das Web-Interface nur auf 127.0.0.1 bereitgestellt.

Warum Container für Entwickler gut sind​

  • schnelles Setup,
  • sauberes AbreiĂźen und Neuaufbauen,
  • unkomplizierter Zugriff auf Logs,
  • einfacheres GMP-/OSP-Experimentieren,
  • einfacheres Integrationstesten mit gvm-tools und python-gvm.

7. Build from Source​

Der offizielle Source-Build-Guide richtet sich klar an Entwickler, nicht an Betreiber.

Greenbone gibt an, dass dieser Pfad Kenntnisse erfordert in:

  • Terminal-Nutzung,
  • Shell-Grundlagen,
  • Paketinstallation,
  • Nutzung eines C-Compilers,
  • cmake und make,
  • systemd,
  • Linux-Dateisystemstruktur,
  • Architekturverständnis.

Und der Guide sagt ausdrĂĽcklich, dass er nicht fĂĽr Produktivumgebungen gedacht ist.

Wann ein Source-Build tatsächlich sinnvoll ist​

Nutze diesen Pfad nur, wenn du:

  • am Code von Greenbone-Komponenten arbeiten musst,
  • eine Komponente tiefgehend debuggen musst,
  • eigene Patches testen musst,
  • Ă„nderungen ĂĽber die Schichten gvmd, Scanner oder UI validieren musst,
  • interne Kompatibilität und Service-Verdrahtung verstehen musst.

Wenn dein eigentliches Ziel "Scans sicher ausfĂĽhren und die Plattform stabil halten" ist, ist der Source-Build meist die falsche Wahl.

8. Kali-Linux-Installation​

Der offizielle Kali-Installations-Guide ist nützlich, hat aber eine wichtige Zuständigkeitsgrenze:

  • die Installationspakete werden von Offensive Security gepflegt,
  • Bugs sollten dem Kali-Linux-Bugtracker gemeldet werden,
  • Greenbone stellt fest, dass es nicht am Packaging-Prozess beteiligt ist und keine Verantwortung fĂĽr diese nativen Kali-Pakete ĂĽbernimmt.

Offizieller Quick-Start-Ablauf unter Kali​

  1. sudo apt update
  2. sudo apt install gvm
  3. sudo gvm-setup
  4. gvm-check-setup
  5. https://127.0.0.1:9392 öffnen
  6. Feed-Status vor dem ersten Scan ĂĽberprĂĽfen

Das ist ein guter Lab-Pfad, aber kein Ersatz fĂĽr ein unterstĂĽtztes Enterprise-Deployment.

9. Feeds und warum sie wichtig sind​

Greenbones Stack hängt von weit mehr ab als "der Scanner-Binärdatei".

Der Feed liefert:

  • Schwachstellentests,
  • CVE-/CPE- und SCAP-Daten,
  • CERT-Advisories,
  • Berichtsformate,
  • Portlisten,
  • Scan-Konfigurationen,
  • weitere gvmd-Datenobjekte.

Community- vs. Enterprise-Feed​

Das offizielle Vergleichspapier sagt:

  • alles im Community Feed ist auch im Enterprise Feed enthalten,
  • der Enterprise Feed fĂĽgt weitere Tests und Richtlinien hinzu,
  • die Enterprise-Feed-Abdeckung umfasst mehr Enterprise-Produkte und Compliance-Inhalte,
  • Support und Professional Services sind an die kommerzielle Seite gebunden.

FĂĽr die Entwicklung bedeutet das:

  • die Community Edition ist echt und nĂĽtzlich,
  • aber Annahmen zu Funktionsumfang und Abdeckung mĂĽssen gegen die Feed-Stufe getestet werden, die du tatsächlich in Produktion einsetzen wirst.

Erwartungen an die initiale Synchronisierung​

Die Doku zum Container-Workflow warnt ausdrĂĽcklich, dass:

  • das Herunterladen und Laden des Feeds mehrere Minuten bis Stunden dauern kann,
  • Scans ohne vollständig geladene Feed-Daten unvollständige oder fehlerhafte Ergebnisse liefern.

Das ist einer der häufigsten Betreiberfehler.

10. Entwickler-Automatisierung: GMP, OSP, CLI und Python​

Greenbone ist auf mehreren Schichten automatisierbar.

GMP​

Verwende GMP, wenn du Management-Aufgaben automatisieren willst:

  • Versionsinformationen abfragen,
  • Ziele verwalten,
  • Scan-Tasks erstellen,
  • Jobs einplanen,
  • Benutzer oder Konfigurationen verwalten,
  • Berichte und Metadaten abrufen.

Das TechDoc-Portal dokumentiert derzeit GMP 22.7, und sogar eine einfache <get_version/>-Anfrage ist als vollwertiger Befehl dokumentiert.

OSP​

Verwende OSP, wenn du Steuerung auf Scanner-Ebene benötigst.

Das TechDoc-Portal dokumentiert derzeit OSP 25.0, einschlieĂźlich Befehlen wie start_scan.

Dies ist die untergeordnete Schnittstelle hinter der Manager-/Scanner-Interaktion.

gvm-tools​

Die Community-Doku zeigt gvm-tools ausdrĂĽcklich als praktischen CLI-Pfad zum Abfragen von gvmd und ospd-openvas.

Beispiel aus der offiziellen Workflow-Doku:

gvm-cli --gmp-username admin socket --pretty --xml "<get_version/>"

python-gvm​

Wenn du Folgendes baust:

  • CI-Checks,
  • Integrationsskripte,
  • internes Provisioning,
  • eigenes Reporting,
  • geplante Plattformautomatisierung,

dann ist python-gvm der sauberste First-Party-Python-Weg.

Praktische API-Design-Tipps​

  • Verwende GMP fĂĽr die meiste Business-Logik.
  • Verwende OSP nur dann, wenn du wirklich Verhalten auf Scanner-Ebene benötigst.
  • Bevorzuge gvm-tools fĂĽr Exploration und Debugging.
  • Bevorzuge python-gvm fĂĽr wartbare Anwendungsintegration.

11. Fernzugriff, TLS und Sicherheits-Posture​

Die Doku zum Community-Container-Workflow hebt mehrere wichtige operative Punkte hervor:

  • Fern-Web-Zugriff erfordert das Bearbeiten der Compose-Konfiguration,
  • TLS ist standardmäßig mit generierten selbstsignierten Zertifikaten aktiviert,
  • eigene Zertifikate können in den nginx-Container eingehängt werden,
  • die UI auf allen Interfaces bereitzustellen ist möglich, sollte aber bewusst geschehen.

Gute Defaults​

  • halte die UI lokal, solange du keinen Fernzugriff benötigst,
  • wenn du sie bereitstellst, verwende ordentliches TLS,
  • ändere das Standard-Admin-Passwort sofort,
  • beschränke den Zugriff auf Netzwerkebene,
  • behandle den Scanner als privilegiertes internes Sicherheitssystem.

Sehr wichtiger rechtlicher / operativer Hinweis​

Scanne nur Systeme und Netzwerke, zu deren PrĂĽfung du autorisiert bist.

Das ist nicht nur eine Frage des Anstands. Schwachstellen-Scanning kann Alarme auslösen, fragile Systeme beeinträchtigen und rechtliche Risiken erzeugen, wenn es außerhalb des genehmigten Umfangs durchgeführt wird.

12. Ein praktischer Entwicklungs-Workflow​

Dies ist der kĂĽrzeste sinnvolle Pfad, wenn dein Ziel ist, Greenbone zu verstehen und zu integrieren, und nicht nur einmal herumzuklicken.

  1. Beginne mit Community-Containern unter Ubuntu 24.04 oder Debian Bookworm.
  2. Warte, bis die initiale Feed-Synchronisierung abgeschlossen ist.
  3. Ă„ndere das Admin-Passwort sofort.
  4. Verifiziere den Stack ĂĽber die GSA und eine GMP-Anfrage.
  5. Teste gvm-tools.
  6. Wechsle zu python-gvm fĂĽr skriptgesteuerte Workflows.
  7. Entscheide, ob dein eigentliches Ziel ist:
    • Community-/Lab-Einsatz,
    • eine unterstĂĽtzte kommerzielle Appliance,
    • oder tatsächlicher Beitrag auf Quellcode-Ebene.

Zu vermeidende Anti-Pattern​

  • den Container-Guide als Produktions-Hardening-Guide zu behandeln,
  • Scans zu starten, bevor der Feed vollständig geladen ist,
  • anzunehmen, dass das Verhalten des Kali-Packagings dem Verhalten des Upstream-Greenbone entspricht,
  • aus dem Quellcode zu bauen, wenn du eigentlich nur einen stabilen Scanner brauchst,
  • die Web-UI breit ohne TLS und Zugriffskontrollen bereitzustellen.

13. Kurzanleitung für Anwender​

Dieser Abschnitt ist bewusst kurz gehalten. Er richtet sich an den ersten Betreiber oder Analysten, der die Web-UI nutzt, nicht an Plattform-Engineering.

UI-Beschriftungen können leicht variieren

Die genauen Beschriftungen und Abläufe können sich zwischen Community Edition, kommerziellen Produkten und Release-Linien unterscheiden. Die folgenden Schritte beschreiben die standardmäßige Betriebsabfolge und sind teilweise aus der dokumentierten Greenbone-Architektur und den Installationsabläufen abgeleitet.

1. Erste Anmeldung​

Nach der Installation:

  • öffne das GSA-Web-Interface,
  • melde dich mit den Admin-Zugangsdaten an,
  • ändere das Standardpasswort sofort.

Für Community-Container öffnet die Doku die GSA unter https://127.0.0.1.
FĂĽr Kali verwendet der offizielle Quick Start https://127.0.0.1:9392.

2. Feed-Bereitschaft prüfen​

Vor dem ersten echten Scan:

  • bestätige, dass die Feed-Synchronisierung abgeschlossen ist,
  • verifiziere, dass Scan-Konfigurationen, Portlisten und Schwachstellentests geladen sind,
  • vertraue frĂĽhen Scan-Ergebnissen nicht, solange das Laden des Feeds noch läuft.

3. Ein Ziel erstellen​

Definiere das System oder Netzwerk, das du prĂĽfen darfst.

Typische Beispiele:

  • ein einzelner Server,
  • ein Lab-Subnetz,
  • ein VM-Bereich,
  • ein kleines BĂĽronetzwerk.

Fang eng an. Ein kleiner Pilot-Scope erleichtert die Fehlersuche.

4. Einen Scan-Task erstellen und starten​

Verwende eine der Standard-Scan-Konfigurationen und starte einen Task gegen das Ziel.

FĂĽr die erstmalige Nutzung:

  • bevorzuge einen kleineren Scope,
  • vermeide es, zuerst sensible Produktivbereiche zu scannen,
  • beobachte Laufzeit und Auswirkung auf den Host.

5. Ergebnisse überprüfen​

Verwende die Web-UI, um:

  • zuerst Befunde mit hoher Schwere zu untersuchen,
  • zu bestätigen, ob das Problem tatsächlich fĂĽr den Host relevant ist,
  • Befunde nach betroffenem Asset, Schwere und Dringlichkeit der Behebung zu gruppieren,
  • bei Bedarf Berichte zu exportieren.

6. Scans zur Routine machen​

Greenbone wird deutlich nĂĽtzlicher, sobald es eingeplant und operationalisiert ist:

  • Scans in einem festen Takt wiederholen,
  • Ergebnisse ĂĽber die Zeit vergleichen,
  • ausnutzbare oder ins Internet exponierte Schwachstellen zuerst priorisieren,
  • die Ausgabe in Ticketing- oder Security-Workflows einbinden, falls deine Edition das unterstĂĽtzt.

14. Wann welcher Greenbone-Weg zu nutzen ist​

SituationBeste Wahl
den Stack lokal lernenCommunity-Container
Automatisierung gegen GMP / OSP testenCommunity-Container + gvm-tools / python-gvm
zum Scanner- oder Manager-Code beitragenBuild from Source
eine schnelle Lab-Installation auf einer Security-Distro ausfĂĽhrenKali-gvm-Pakete
für eine unterstützte Geschäftsumgebung bereitstellenOPENVAS BASIC oder OPENVAS SCAN
Sensoren, API-Zugriff, Enterprise-Support, größeren Funktionsumfang benötigenOPENVAS SCAN
den einfachsten Einstiegspunkt fĂĽr kleine Unternehmen wollenOPENVAS BASIC

Produkte

Open Source / Doku