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 = yesin theopenvas.conffile)
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
pgcryptoPostgreSQL 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 Ownerneeds 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.
gvmdneeds to be connected to anospd-openvasinstance and VTs must be available on the hard disk at<install-prefix>/var/lib/openvas/pluginsafter runninggreenbone-nvt-sync. - A consolidated
greenbone-feed-syncsync script was created ingvmdrequiring updates to possible existing sync scripts (except forgreenbone-nvt-syncbecause it is shipped with theopenvascomponent), 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_formatsof 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_formatfolder from<old-install-prefix>/share/gvm/gvmd/report_formatsto<new-install-prefix>/share/gvm/gvmd/report_formatsso that gvmd is able to find these report formats for the migration step.
-
Important: When changing the
- The location of the
feed-update.lockfile forgvmd,openvasandospd-openvashas been consolidated and all components expecting this file at the same location (which is<install-prefix>/var/run/feed-update.lockby default).- Note: When changing the default by using a different
OPENVAS_RUN_DIRandGVM_RUN_DIR(Especially important for package maintainers) please make sure to set the correctOPENVAS_FEED_LOCK_PATHandGVM_FEED_LOCK_PATHfor cmake during build time
- Note: When changing the default by using a different
- The default OSPD unix socket path used by
gvmdwas changed from/tmp/ospd.sockto/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_SOCKETcmake flag during build time. - The
xsltprocbinary (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.