Skip to main content

Greenbone / OpenVAS Guide

What is this about?

Greenbone is not only a vulnerability scanner. It is a broader vulnerability-management stack with open-source core components, commercial appliances and services, daily feed content, web management, APIs, and automation tooling. This guide gives you a verified map of the current products, the open-source architecture, the main repositories, the supported installation paths, and a compact operator workflow for your first scans.

Source scope as of June 25, 2026

This guide is based on Greenbone's official product pages, documentation portals, OpenVAS project page, official GitHub organization, and Greenbone documents. A few important distinctions are current in the official sources:

  • The commercial product family is branded as OPENVAS on the public product page.
  • The open-source stack is documented as Greenbone Community Edition, historically also known as OpenVAS or GVM.
  • Greenbone's own community documentation explicitly states that both the container guide and the build-from-source guide are not intended for production setups.

In this section​

This page is the conceptual overview. The following guides go into operational detail, based on the official Greenbone manuals (GOS 22.04 / OPENVAS SCAN 22.04 appliance manual and the Greenbone Cloud Service manual):

Installation & administration

Daily operation

Advanced & reference

1. The mental model​

You will avoid a lot of confusion if you separate these four layers:

LayerWhat it isBest for
OpenVAS ScannerThe scan engine that executes vulnerability tests against targetsActual scanning
Greenbone Community EditionThe open-source framework around the scanner: gvmd, gsa, feeds, protocols, toolingLabs, development, integration, self-managed community use
OPENVAS commercial productsGreenbone's productized offerings such as OPENVAS BASIC and OPENVAS SCANSupported business use, faster rollout, enterprise operations
Feeds, APIs, and toolingCommunity/enterprise feed data plus GMP/OSP APIs and CLI/Python librariesAutomation, integrations, custom workflows

In other words:

  • OpenVAS can mean only the scanner,
  • or historically the broader open-source framework,
  • while Greenbone Community Edition is the clearer current umbrella term for the open-source side,
  • and OPENVAS BASIC / SCAN / upcoming products are the commercial product line.

2. Current product map​

Greenbone's official product page currently highlights these offerings:

ProductPositioningNotes
OPENVAS BASICEntry product for small businesses and individual usersEasy onboarding, simplified operation, lower feature set
OPENVAS SCANMain business and public-sector scanning productHardware or virtual appliance, broader enterprise features
OPENVAS SECURITY INTELLIGENCECentral intelligence and management layerMarked coming soon
OPENVAS AIAI-assisted remediation planningMarked as an upcoming solution

Adjacent official documentation also references:

  • Greenbone Community Edition
  • Greenbone Cloud Service
  • OPENVAS REPORT
  • OPENVAS OS
  • OPENVAS FREE in the document portal

What the official product pages say now​

OPENVAS BASIC

  • positioned as a fast and low-complexity entry point,
  • daily security tests,
  • automated scans,
  • clear reports,
  • simple operation,
  • explicit trade-offs versus OPENVAS SCAN: no sensors, no API access, no remediation tickets, no included support.

OPENVAS SCAN

  • positioned for enterprises and public institutions,
  • hardware or virtual deployment,
  • authenticated endpoint scanning,
  • container image scanning,
  • open APIs and connectors,
  • scalable architecture,
  • agent-based scanning,
  • air-gapped deployment possibilities for appliance setups.

OPENVAS SECURITY INTELLIGENCE is described as a central platform for distributed vulnerability management, consolidating results from multiple OPENVAS SCAN systems and enriching findings with CSAF and SBOM data.

OPENVAS AI is positioned as a locally operated AI layer that turns scan results into prioritized action plans without data leaving the network.

3. Open-source architecture​

Greenbone's community documentation describes the Community Edition as a multi-service framework with three main parts:

  1. executable scanner applications,
  2. gvmd,
  3. GSA with gsad.

Core components​

ComponentRole
openvas-scannerExecutes vulnerability tests against targets
ospd-openvasOSP daemon that lets gvmd control the scanner
gvmdCentral manager; stores config and results in PostgreSQL; handles users, roles, permissions, scheduling, and management logic
GSAWeb frontend
gsadWeb daemon / access layer for GSA to talk to gvmd
Notus ScannerFaster handling for local security checks by comparing installed software against known vulnerable software lists
gvm-toolsCLI tooling for GMP and OSP access
python-gvmPython library for automating Greenbone workflows

Protocols​

ProtocolPurpose
GMPGreenbone Management Protocol; XML-based management interface exposed by gvmd
OSPOpen Scanner Protocol; scanner-control protocol used between gvmd and scanner services

The docs portal currently exposes:

  • GMP API version 22.7
  • OSP API version 25.0

That split is important: the management layer and scanner layer have different APIs and version tracks.

4. Verified GitHub repositories​

The official verified GitHub organization is greenbone, linked to greenbone.net.

The most relevant repositories currently visible from the org overview are:

RepositoryWhat it is for
openvas-scannerScanner component for Greenbone Community Edition
gvmdGreenbone Vulnerability Manager database backend / central manager
gsaGreenbone Security Assistant web frontend
ospd-openvasOSP server implementation for controlling OpenVAS
gvm-toolsCLI access and remote control tooling
python-gvmPython client library
scanner-apiScanner API definitions
docsCommunity documentation source

The docs and architecture pages also reference further component repositories such as Notus Scanner and gsad. Those are part of the documented architecture even if they were not among the first repositories surfaced in the GitHub org overview we checked.

5. Which deployment path to choose​

Greenbone's own sources point to three distinct paths for the community/open-source side, and separate commercial paths.

PathBest forImportant caveat
Community containersFast local evaluation, labs, learning, test setupsOfficially not intended for production
Build from sourceDevelopers working on the stack itself or needing source-level controlOfficially not intended for production
Kali Linux packagesSecurity lab setups, quick local installsPackaging is maintained by Kali / Offensive Security, not Greenbone
Commercial OPENVAS SCAN / BASICSupported business deploymentBest fit when you need support, appliances, simpler operations, and enterprise feed coverage
  • Choose OPENVAS BASIC if you want the fastest supported entry point for a small environment.
  • Choose OPENVAS SCAN if this is a real operational security platform for an organization.
  • Choose community containers if you want to learn the stack, automate against it, or validate workflows cheaply.
  • Choose build from source only if you actually need source-level development or patching.
  • Choose Kali packages for lab and security-workstation scenarios, not as your default production deployment model.

6. Community containers: the practical default for development​

If you are a developer, integrator, or lab operator, Greenbone's container path is the shortest route to a working environment.

What the docs say​

The official container guide states:

  • Docker knowledge is required,
  • a basic understanding of the architecture is required,
  • the guide is for users who want to test new features or get familiar with the Community Edition,
  • it is not intended for production setups.

Resource requirements​

Official community-container guidance lists:

ProfileCPURAMStorage
Minimum2 cores4 GB20 GB free
Recommended4 cores8 GB60 GB free

Supported distributions in the guide​

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

The same page notes that other Debian derivatives will likely work with small adjustments.

Important operational details​

  • Always use the latest compose.yaml.
  • The initial feed load can take minutes to hours.
  • The default admin user is admin with password admin, and the docs strongly recommend changing it immediately.
  • By default, the web interface is exposed only on 127.0.0.1.

Why containers are good for developers​

  • fast setup,
  • clean teardown and rebuild,
  • straightforward log access,
  • easier GMP/OSP experimentation,
  • easier integration testing with gvm-tools and python-gvm.

7. Building from source​

The official source-build guide is clearly aimed at developers, not operators.

Greenbone says this path requires knowledge of:

  • terminal usage,
  • shell basics,
  • package installation,
  • C compiler usage,
  • cmake and make,
  • systemd,
  • Linux filesystem structure,
  • architecture understanding.

And the guide explicitly says it is not intended for production setups.

When source build actually makes sense​

Use this path only when you need to:

  • work on Greenbone component code,
  • debug a component in depth,
  • test custom patches,
  • validate changes across gvmd, scanner, or UI layers,
  • understand internal compatibility and service wiring.

If your real goal is "run scans safely and keep the platform stable", source build is usually the wrong choice.

8. Kali Linux installation​

The official Kali install guide is useful, but it comes with an important ownership boundary:

  • installation packages are maintained by Offensive Security,
  • bugs should be reported to the Kali Linux bug tracker,
  • Greenbone states it is not involved in the packaging process and does not take responsibility for those native Kali packages.

Official quick-start flow on Kali​

  1. sudo apt update
  2. sudo apt install gvm
  3. sudo gvm-setup
  4. gvm-check-setup
  5. open https://127.0.0.1:9392
  6. verify feed status before the first scan

This is a good lab path, but not a substitute for a supported enterprise deployment.

9. Feeds and why they matter​

Greenbone's stack depends on much more than "the scanner binary".

The feed delivers:

  • vulnerability tests,
  • CVE/CPE and SCAP data,
  • CERT advisories,
  • report formats,
  • port lists,
  • scan configurations,
  • other gvmd data objects.

Community vs enterprise feed​

The official comparison paper says:

  • everything in the Community Feed is also in the Enterprise Feed,
  • the Enterprise Feed adds more tests and guidelines,
  • enterprise feed coverage includes more enterprise products and compliance content,
  • support and professional services are tied to the commercial side.

For development, that means:

  • the Community Edition is real and useful,
  • but feature and coverage assumptions must be tested against the feed tier you will actually use in production.

Initial sync expectations​

The container workflow docs explicitly warn that:

  • feed download and loading can take several minutes to hours,
  • scans without fully loaded feed data will produce incomplete or erroneous results.

That is one of the most common operator mistakes.

10. Developer automation: GMP, OSP, CLI, and Python​

Greenbone is automatable at several layers.

GMP​

Use GMP when you want to automate management tasks:

  • query version information,
  • manage targets,
  • create scan tasks,
  • schedule jobs,
  • manage users or configurations,
  • retrieve reports and metadata.

The TechDoc portal currently documents GMP 22.7, and even a simple <get_version/> request is documented as a first-class command.

OSP​

Use OSP when you need scanner-level control.

The TechDoc portal currently documents OSP 25.0, including commands such as start_scan.

This is the lower-level interface behind the manager/scanner interaction.

gvm-tools​

The community docs explicitly show gvm-tools as the practical CLI path for querying gvmd and ospd-openvas.

Example from the official workflow docs:

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

python-gvm​

If you are building:

  • CI checks,
  • integration scripts,
  • internal provisioning,
  • custom reporting,
  • scheduled platform automation,

then python-gvm is the cleanest first-party Python route.

Practical API design advice​

  • Use GMP for most business logic.
  • Use OSP only when you truly need scanner-layer behavior.
  • Prefer gvm-tools for exploration and debugging.
  • Prefer python-gvm for maintainable application integration.

11. Remote access, TLS, and security posture​

The community-container workflow docs highlight several important operational points:

  • remote web access requires editing the compose configuration,
  • TLS is enabled with generated self-signed certs by default,
  • custom certificates can be mounted into the nginx container,
  • exposing the UI on all interfaces is possible, but it should be done intentionally.

Good defaults​

  • keep the UI local unless you need remote access,
  • if you expose it, use proper TLS,
  • change the default admin password immediately,
  • restrict access at the network layer,
  • treat the scanner as a privileged internal security system.

Very important legal / operational note​

Scan only systems and networks you are authorized to assess.

That is not just etiquette. Vulnerability scanning can trip alerts, impact fragile systems, and create legal exposure if performed outside approved scope.

12. A practical development workflow​

This is the shortest sensible path if your goal is to understand and integrate Greenbone, not just click around once.

  1. Start with community containers on Ubuntu 24.04 or Debian Bookworm.
  2. Wait for the initial feed sync to complete.
  3. Change the admin password immediately.
  4. Verify the stack via GSA and one GMP request.
  5. Test gvm-tools.
  6. Move to python-gvm for scripted workflows.
  7. Decide whether your real target is:
    • community/lab use,
    • a supported commercial appliance,
    • or actual source-level contribution.

Anti-patterns to avoid​

  • treating the container guide as a production hardening guide,
  • starting scans before the feed fully loads,
  • assuming Kali packaging behavior equals upstream Greenbone behavior,
  • building from source when you really just need a stable scanner,
  • exposing the web UI broadly without TLS and access controls.

13. Quick user guide​

This section is intentionally short. It is for the first operator or analyst using the web UI, not for platform engineering.

UI labels can vary slightly

The exact labels and flows can differ between Community Edition, commercial products, and release lines. The steps below describe the standard operating sequence and are partly inferred from the documented Greenbone architecture and installation flows.

1. First login​

After installation:

  • open the GSA web interface,
  • sign in with the admin credentials,
  • change the default password immediately.

For community containers, the docs open GSA at https://127.0.0.1.
For Kali, the official quick start uses https://127.0.0.1:9392.

2. Verify feed readiness​

Before the first real scan:

  • confirm that feed synchronization is complete,
  • verify that scan configs, port lists, and vulnerability tests are loaded,
  • do not trust early scan results while feed loading is still in progress.

3. Create a target​

Define the system or network you are allowed to assess.

Typical examples:

  • a single server,
  • a lab subnet,
  • a VM range,
  • a small office network.

Start narrow. A small pilot scope makes troubleshooting easier.

4. Create and start a scan task​

Use one of the standard scan configurations and launch a task against the target.

For first-time usage:

  • prefer a smaller scope,
  • avoid scanning sensitive production ranges first,
  • watch runtime and host impact.

5. Review results​

Use the web UI to:

  • inspect high-severity findings first,
  • confirm whether the issue is actually relevant to the host,
  • group findings by affected asset, severity, and remediation urgency,
  • export reports if needed.

6. Turn scans into a routine​

Greenbone becomes much more useful once it is scheduled and operationalized:

  • repeat scans on a cadence,
  • compare results over time,
  • prioritize exploitable or internet-facing weaknesses first,
  • connect output into ticketing or security workflows if your edition supports it.

14. When to use which Greenbone route​

SituationBest fit
learn the stack locallyCommunity containers
test automation against GMP / OSPCommunity containers + gvm-tools / python-gvm
contribute to scanner or manager codeBuild from source
run a quick lab install on a security distroKali gvm packages
deploy for a supported business environmentOPENVAS BASIC or OPENVAS SCAN
need sensors, API access, enterprise support, wider feature setOPENVAS SCAN
want the easiest small-business entry pointOPENVAS BASIC

Products

Open source / docs