Frequently Asked Questions (FAQ)#

Greenbone, GVM and OpenVAS – How are they connected?#

For a comprehensive background see History of OpenVAS.

Where can I ask questions and get support?#

Support is only provided for the Greenbone Enterprise product line. Besides that, the Greenbone Community can be reached at the community forum to ask question. In this forum, several Greenbone developers try to help on a voluntary basis.

Can you help with my issue on Kali, Cent OS, XYZ distribution?#

Greenbone doesn’t provide any packages for any Linux distribution besides the commercial Greenbone OS. If you have installed the Greenbone Community Edition from your distribution like Kali Linux, an external package repository or even some random docker image, Greenbone was not involved in providing this installation method to you.

The development of the Greenbone Community Edition and packaging for a distribution or container image is completely independent. Therefore, our software provided from these sources may be heavily adjusted, outdated or even completely broken. If you have issues with the software, please contact the provider of the packages first and create a ticket at their issue tracker. How to contact the provider depends and varies.

Can you help me updating my OpenVAS installation?#

This is also very similar to Can you help with my issue on Kali, Cent OS, XYZ distribution.

For updating your source build from a previous version of this guide, see Updating to Newer Releases.

For updating your installation of the Greenbone Community Containers, see Updating the Greenbone Community Containers.

We are not able to offer any help on updating installations done via any external source like Kali packages, Cent OS packages, some other guide or some random docker images because we are not aware of their specific needs and changes! Please contact the author(s) of your installation method.

Which release contains which component?#

It was often confusing to find out which software component of the Greenbone Community Edition belongs to which release. Additionally, the Greenbone OS used in the Greenbone Enterprise TRIAL had a different versioning scheme than the Community Edition. The following table contains an overview which component in which version belongs to a release.







OpenVAS Scanner

Notus Scanner


Release Date

Greenbone Community Edition 22.4










GVM 21.4








end-of-life (Community Edition: since 2023-01-17, GOS: since 2023-04-03)


GVM 20.08








end-of-life (since 2021-12-02)


GVM 11








end-of-life (since 2020-12-31)


GVM 10








end-of-life (since 2020-12-31)


OpenVAS 9


openvas-manager 7.0.y



openvas-libraries 9.0.y





My self-compiled version isn’t working as expected. Can you help me?#

All questions should be handled at the community forum but please be aware that your questions are answered on a voluntary basis. Therefore, please don’t expect immediate responses. The community forum is for individuals to exchange experiences and problems about a Free Software project and not to get instant advises from the developers or professional support to fix your current issue.

If you are using a self-compiled version of the Greenbone software stack not build from this guide or packages from an external third party like a distribution please always check if you can reproduce the same behavior with the Greenbone Enterprise TRIAL Virtual Machine If we are able to reproduce your issue it will be much easier to fix.

Can I mix components from different releases?#

Short answer: no. You must never mix versions of our components from different releases. Often people try to use version e.g. the scanner from the main branch in combination with a release version of the other components like gvmd to check if their failing scan works with a newer version. While it may work for some components in most circumstances it is very likely to break for gvmd, ospd, ospd-openvas and openvas-scanner. These components interact with each other a lot and rely on public and private interfaces that change with every release. Internal incompatible changes even might happen in bugfix releases. Therefore never mix components from different releases. Always use the latest releases or the same release branches. In the release announcements of the community forum, we always update the linked released versions which should be used and are known to work flawlessly.

I am looking for an overview about OpenVAS.#

See Greenbone, GVM, OpenVAS and How They Are Connected for some background about Greenbone OpenVAS.

Our software consists of several software components. All components are free software and can be found at GitHub.

For an overview of the components and their connections, please take a look at the Architecture.

My scan does not show any results#

After a finished scan your report doesn’t contain any results or errors.

Some common issues if scans doesn’t return any results are:

  1. The targets are not answering to an ICMP Echo Request -> Check the Alive Test setting of your target definition and try some of the other available methods. Further reading:

  2. You’re using a custom scan configuration which doesn’t include the following two VTs from the Port scanners family.

    Further reading here

  3. You’re using a Port List which isn’t optimal for your environment:

    e.g. a All TCP and All UDP port list might be responsible for your portscan to time out causing your scan to not return any results at all. It is suggested to start with a smaller port list like e.g. All IANA TCP.

  4. SELinux is enabled and blocking the scanner from doing its job.

  5. You don’t have nmap installed or not available within your PATH.

For further debugging / logging the mentioned Nmap (NASL wrapper) and Ping Host VTs allow to configure various settings:

  • Ping Host

    1. Report about unreachable Hosts configured to yes: include notes if a remote host is considered as dead / not reachable and the reason why.

    2. Log failed nmap calls and Log nmap output configured to yes: Logs additional output if nmap was used.

  • Nmap (NASL wrapper)

    1. Log nmap output configured to yes: Log additional output if nmap was used.

I still fail to see/understand the concept of greenbone-feed-sync --type vs greenbone-nvt-sync/greenbone-certdata-sync/greenbone-scapdata-sync vs gvm-feed-update#

gvm-feed-update is NOT maintained by Greenbone and is therefore not used anywhere in our docs or in code provided by Greenbone. It is maintained by the Kali/Debian packagers and just calls the standard greenbone-*-sync scripts.

greenbone-certdata-sync is just the same as greenbone-feed-sync --type CERT. It is/was only provided for backwards compatibility and does not get installed (by default) anymore since gvmd 22.5.0.

greenbone-scapdata-sync is just the same as greenbone-feed-sync --type SCAP. It is/was only provided for backwards compatibility and does not get installed (by default) anymore since gvmd 22.5.0.

greenbone-nvt-sync is the old sync script written in bash to download the vulnerability tests data (:file:.nasl and :file:.notus files). It is deprecated since openvas-scanner 22.6.0.

/usr/sbin/greenbone-feed-sync is the old sync script written in bash to download the CERT, SCAP and GVMD data. It does not get installed (by default) anymore since gvmd 22.5.0.

There is a new greenbone-feed-sync script written in Python to replace all of the above scripts, see the announcement at This script is used in the build-from-source guide already but has not been picked up by the distributions yet. Hopefully, it will arrive at the distributions in the next months. It even supports the gvm-feed-update use case because by default, if no arguments are passed, --type all is run which downloads all feed data types.