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
- Main:
- Extras:
Source Code Repository
- Main:
- Extras:
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
Overview
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 theopenvas.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+).
Details
- 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 anospd-openvas
instance and VTs must be available on the hard disk at<install-prefix>/var/lib/openvas/plugins
after runninggreenbone-nvt-sync
. - A consolidated
greenbone-feed-sync
sync script was created ingvmd
requiring updates to possible existing sync scripts (except forgreenbone-nvt-sync
because it is shipped with theopenvas
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 mentionedreport_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.
-
Important: When changing the
- The location of the
feed-update.lock
file forgvmd
,openvas
andospd-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
andGVM_RUN_DIR
(Especially important for package maintainers) please make sure to set the correctOPENVAS_FEED_LOCK_PATH
andGVM_FEED_LOCK_PATH
for cmake during build time
- Note: When changing the default by using a different
- 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 theOPENVAS_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.