GVM 20.08 (end-of-life, initial release 2020-08-12)

Greenbone Vulnerability Management version 20.08 (GVM-20.08) is end-of-life and will not get any further releases. You should update to a newer release.

This is the first release that uses a calendar based versioning (August of 2020) and uses the same version for all main components. This will make it easier to identify which component version belongs to which release.

With the end of 2020 both GVM 10 and GVM 11 will retire and won’t get any additional releases. All users and distributions should switch to GVM 20.08 immediately.

GVM is developed for and as part of the commercial product line Greenbone Security Manager. It is developed by Greenbone and licensed as Free Software/Open Source.

GVM is published as regularly updated and tested source code releases.

It is also available as latest source code repository state, which is not fully tested and may show unexpected behavior.

  • Supported Greenbone Management Protocol (GMP) version: 20.8
  • Supported Open Scanner Protocol (OSP) version: 20.8

Source Code Release

Source Code Repository

Installing Source Code

For installation from source code, it is recommended and assumed that you are familiar with the procedure to build and install software from the actual source code.

Both procedures, building from source code release and building from source code repository follow the same common way.

After download enter each main directory and follow the instructions in the README.md and INSTALL.md files.

Typically you will need to install various missing dependencies such as development libraries and helper utilities. The configuration process tries to help you to find out about what is missing.

If you run into trouble, search the category Source Code Edition for a solution and if not found, raise your question there.

Notable Changes in this Release


With this release the object data consisting of the report formats, port lists, policies and scan configs are loaded from the feed. The object data can be synced with the new greenbone-feed-sync command, actually with greenbone-feed-sync --type GVMD_DATA. Shipping the object data with the feed allows for updating these data more frequently without having to create new releases. Please check the details below for more background information.

With GVM 11 we introduced a new scanner architecture based on ospd. For GVM 20.08 we spent a lot of resources to improve the overall performance of this new architecture which resulted in

  • huge memory consumption improvements (down to approx. 40 MiB per scan for a ospd-openvas scan process)
  • more robust start of scans by introducing scan queuing
  • not starting scans if available memory is too low
  • new experimental much faster alive host detection (opt-in by setting test_alive_hosts_only = yes in the openvas.conf file)

There is one important infrastructure change to mention. The license of gvmd, gsad, gsa, ospd and ospd-openvas has changed from GNU General Public License version 3 or later (GPLv3+) to GNU Affero General Public License 3 or later (AGPLv3+).


  • A new pgcrypto PostgreSQL DB extension is required, please see: https://github.com/greenbone/gvmd/blob/gvmd-20.08/INSTALL.md#setting-up-the-postgresql-database
  • The Feed Import Owner needs to be configured, please see: https://github.com/greenbone/gvmd/blob/gvmd-20.08/INSTALL.md#set-the-feed-import-owner
  • Scan configs will not be imported without synced VTs. gvmd needs to be connected to an ospd-openvas instance and VTs must be available on the hard disk at <install-prefix>/var/lib/openvas/plugins after running greenbone-nvt-sync.
  • A consolidated greenbone-feed-sync sync script was created in gvmd requiring updates to possible existing sync scripts (except for greenbone-nvt-sync because it is shipped with the openvas component), please see: https://github.com/greenbone/gvmd/blob/gvmd-20.08/INSTALL.md#keeping-the-feeds-up-to-date
  • The migration from a previous GVM release to 20.08 requires the report_formats of the previous release kept at <install-prefix>/share/gvm/gvmd/report_formats/*. Please make sure to keep the files and folders there when doing the upgrade (if you start from scratch this step is not necessary).
    • Important: When changing the <install-prefix> during an upgrade you need to copy over the mentioned report_format folder from <old-install-prefix>/share/gvm/gvmd/report_formats to <new-install-prefix>/share/gvm/gvmd/report_formats so that gvmd is able to find these report formats for the migration step.
  • The location of the feed-update.lock file for gvmd, openvas and ospd-openvas has been consolidated and all components expecting this file at the same location (which is <install-prefix>/var/run/feed-update.lock by default).
    • Note: When changing the default by using a different OPENVAS_RUN_DIR and GVM_RUN_DIR (Especially important for package maintainers) please make sure to set the correct OPENVAS_FEED_LOCK_PATH and GVM_FEED_LOCK_PATH for cmake during build time
  • The default OSPD unix socket path used by gvmd was changed from /tmp/ospd.sock to /var/run/ospd/ospd.sock. If your deployment relies on the previous path make sure to update the path accordingly. The default path is now also configurable via the OPENVAS_DEFAULT_SOCKET cmake flag during build time.
  • The xsltproc binary (Debian package: xsltproc) is now marked as mandatory for gvmd (it was already previously mandatory but wasn’t marked as such).
  • Fewer scan configurations, port lists and report formats are supported in GVM 20.08 in comparison to previous versions. The reasons are the following:
    • The scan configurations, port lists and report formats are now delivered via the feed and are therefore faster to maintain.
    • Some scan configurations, port lists and report formats are no longer maintained in our Greenbone Community Feed.
    • During a migration, the old scan configurations, port lists and report formats are not removed but are retained. However, they may no longer function completely or not at all.