OpenVAS Scanner: the GPL scan engine behind Greenbone Community Edition

What openvas-scanner is, and who it is for

This repository is the scanner component of the Greenbone Community Edition. It is not the whole vulnerability management product. The README describes it as a full-featured scan engine that executes a continuously updated and extended feed of Vulnerability Tests, and notes that the same engine is used for the Greenbone Enterprise appliances. That sentence is the most useful thing in the README for a decision maker: the scanning core is shared between the commercial appliance line and the community stack, while the surrounding management, scheduling and reporting layers are what differ.

The audience is therefore narrow and specific. You are running or building a GVM deployment and you need the component that actually performs the checks. You are comfortable with a C and CMake build, or with running a container image. If you were looking for an application with a web interface and a setup wizard, this repository is the wrong entry point; the homepage at greenbone.github.io/docs/ is where the broader installation guidance lives, and INSTALL.md is where this module's own requirements are written down.

How the scan engine and the VT feed fit together

The mechanism visible in the repository is a separation between the engine and its test content. The engine is the code in this repository; the Vulnerability Tests are a feed that the engine executes. The README states the feed is continuously updated and extended, which means the detection logic changes without a scanner release. That design choice is why the project can ship patch releases like v23.50.24 while detection coverage moves independently.

Integrity is handled at the release layer. All release files are signed with the Greenbone Community Feed integrity key, downloadable from greenbone.net, with the fingerprint `8AE4 BE42 9B60 A59B 311C 2E73 9823 FAA6 0ED1 E580`. Anyone automating feed or release consumption should verify against that fingerprint rather than trusting the download.

The second mechanism is the migration. The repository contains two scanner implementations: a C implementation at the top level and a Rust project under `rust/`. The README states the Rust project aims to replace the current scanner stack, which it names as openvas-scanner, ospd-openvas and notus-scanner, and that it currently uses openvas-scanner as its scan engine. So the Rust work is a consolidation project sitting on top of the C engine, not a parallel engine that has already taken over. The licence split follows the directory split, which is covered below.

Installing openvas-scanner from source

The README gives the shortest possible build path. Two commands, run from the repository root:

cmake .
make install

The README does not present these as sufficient on their own. It points to INSTALL.md for detailed installation requirements and instructions, and states that the same file covers setting up `openvas` and making the scanner available to other GVM modules. Treat INSTALL.md as mandatory reading, not optional: the two commands above assume dependencies, paths and a user context that the README never enumerates.

If building from source is not something you want to do, the README offers two alternatives. The first is the Greenbone Enterprise TRIAL, described as a prepared virtual machine with a readily available setup, with information at greenbone.net. The second is the container route, covered in the next section. Note what the README does not offer: there is no package manager command, no Windows installer, and no single-command bootstrap for this module.

Running the published container image

The repository ships Docker files and a published image. The README states you can pull from the Greenbone registry at `ghcr.io/greenbone/openvas-scanner:stable`. That tag is the one to note if you want a moving stable reference rather than a pinned digest.

To build the image locally instead, the README gives this command:

docker build -t <image-name> -f .docker/prod.Dockerfile .

Replace `<image-name>` with your own tag; the README uses that literal placeholder. The build context is the repository root and the file is `.docker/prod.Dockerfile`, which matches the `.docker/` directory in the repository listing. For more on building images, the README defers to the official Docker documentation.

The README also points to a fully containerized solution for the Greenbone Community Edition and attaches a warning: the Greenbone Community Containers are currently under development. That warning is attached to the container documentation, and it should shape how you plan upgrades. A container image that pulls `:stable` and a container stack described as under development are two different risk profiles, and the README does not reconcile them.

Two implementations, two licences, one repository

The licence situation is unusual enough to state plainly. This module, except for the Rust implementation in `rust/`, is licensed under the GNU General Public License v2.0 only. Single files may instead be licensed under GPL v2.0 only or GPL v2.0 or later, and `license-details.md` is the file that records which is which. The Rust implementation in `rust/` is licensed under GPL v2.0 or later with an OpenSSL exception, and single files there are additionally licensed under MIT.

The practical consequence is that the licence of the code you link or embed depends on which directory it came from, and for the C side it can depend on the individual file. If your legal position depends on GPL-2.0-only versus GPL-2.0-or-later, `license-details.md` is the document to read, not the README summary. Contributions are gated as well: the README asks contributors to commit the contribution agreement from the RELICENSE folder with their first pull request, and to follow the conventional commit rules in CONVENTIONAL-COMMITS.md because the project has an autolabel for releases. That autolabel is why commit message format matters to release numbering.

Limitations and the cases where this is the wrong component

The README is thin in ways that matter for operations. It documents no rollback procedure, no downgrade path between releases, and no migration steps for moving a deployment from the C scanner to the Rust stack. The Rust project is described as aiming to replace the current stack, with openvas-scanner still serving as its scan engine, so anyone planning around the Rust implementation is planning around something the README does not describe as finished.

The container guidance carries its own caveat, quoted above: the Greenbone Community Containers are currently under development. If your requirement is a supported, stable container platform, that sentence is the one to weigh.

This is also the wrong component if you want the product rather than the engine. Scheduling, result storage, reporting and the user interface live in the other GVM modules that the README names when describing the Rust project's scope. Installing openvas-scanner alone gives you the thing that runs checks, not the thing that manages them. And if you need to run scans from Windows, nothing in the README suggests a Windows build path; the documented routes are a source build, a container image, or the prepared virtual machine.

How it relates to other vulnerability scanners

The natural comparison is Nessus, and the difference that matters is structural rather than technical. Nessus is a commercial product with a vendor-operated plugin feed and a licensing model tied to the vendor. openvas-scanner is GPL-2.0, part of the Greenbone Community Edition, and executes the Greenbone Community Feed, whose releases are signed with a public key and fingerprint you can verify yourself. The trade is control against convenience: you get a scanner you can inspect, rebuild and self-host, and in exchange you own the build, the feed integrity checks and the upgrade path that a commercial product would handle for you.

Against a general-purpose scanner that maps findings to CVE identifiers, the difference is the unit of detection. This engine executes Vulnerability Tests from a maintained feed, and the README frames that feed as continuously updated and extended. That is a different model from a tool that reports CVE matches and leaves interpretation to you. Neither is strictly better; they answer different questions about a host.

Maintenance status and upgrade cost

The repository is not archived. The last push was on 2026-09-22, and the most recent release in the listing is v23.50.24 from 2026-08-31, preceded by v23.50.23 on 2026-08-26 and v23.50.22 on 2026-08-25. Patch releases arrive at a short cadence, and the release numbering in that series is what you should track if you pin versions.

The maintainer is Greenbone AG, stated in the README. Support routes are split: usage questions go to the Greenbone Community Portal, bugs go to the GitHub issue tracker, and Greenbone customers can additionally use the Greenbone Support Portal. That split is worth knowing before you file anything, because a community portal question and a support ticket are not the same channel.

Upgrade cost has two distinct parts. Scanner releases are frequent and small, which keeps individual upgrades cheap but means the cadence is continuous rather than periodic. The Rust migration is the opposite: it is a stack-level change whose completion the README does not date, and it is the item most likely to require planning rather than a routine update. Budget for the first and watch the second.

Editorial conclusion

Adopt openvas-scanner if you want a self-hosted, GPL-2.0 scan engine that executes the Greenbone Community Feed and you are willing to build from source or run the published container image. Do not adopt it if you need a Windows agent, a single-binary installer, or a documented rollback path between the C and Rust implementations, because the README describes neither. Before committing, verify two things: that your host satisfies the requirements in INSTALL.md, and whether your deployment should track the stable tag on ghcr.io/greenbone/openvas-scanner or build the prod Dockerfile yourself, since the README states the Community Containers are still under development.

Frequently asked questions

Official sources

1. greenbone/openvas-scanner on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases