Greenbone, GVM and OpenVAS how are they connected
When the OpenVAS project was created it only consisted of an engine for scanning vulnerabilities. Shortly after Greenbone Networks was funded to achieve professional support for vulnerability scanning. Greenbone started to lead the development, added several software components and turned OpenVAS into a vulnerability management solution still keeping the values of free software.
After several years it became obvious that using OpenVAS as the brand name for the open source project and funding nearly all development of the project wasn’t recognized from the outside. Therefore after the release of the OpenVAS 9 framework it got renamed to Greenbone Vulnerability Management (GVM) and released as Greenbone Source Edition (GSE). Since GVM 10 the term OpenVAS is only used for the scanner component as it was at the beginning of the project.
For a comprehensive background see History of OpenVAS at https://openvas.org/
GVM, GSE, GSM TRIAL, GCF, GSF, GSM, GPE, ... what are these things about
See Solution_Comparison paper
and the glossary of the gvm-tools documentation
My Report contains Report outdated / end-of-life Scan Engine
Besides only mentioning
GVM Libraries (gvm-libs) in the scan result it means your whole GVM installation is outdated. All software components of our stack need to be updated not only gvm-libs. The software components you are using our not supported anymore. Issues you are currently facing with such a version are very likely already fixed in newer versions. See this table to get an overview of our software versions. This issue needs to be fixed by the provider of your installation of our software, which is most likely your distribution package maintainer.
External issue reports for Report outdated / end-of-life Scan Engine / Environment (local):
Can you help to update my GVM version on Kali, Cent OS, XYZ distribution
Greenbone doesn’t provide any packages for any Linux distribution besides our own commercial Greenbone OS. If you have installed our software from your distribution, an external package repository or even a docker image Greenbone wasn’t involved in providing this installation method to you. The software from these sources may be heavily adjusted, outdated or even completely broken. Therefore if you have issues with the software please contact the provider of the packages first. How to contact the provider really depends and varies.
We are not able to offer any help on updating packages from any external source like Kali, Cent OS, Docker Image, …!
Please help me installing GVM and please advice on recommended platform OS too
This is very similar to Can you help to update my GVM version on Kali, Cent OS, XYZ distribution. Greenbone can’t provide installation docs for the many available Linux distributions available. Setups, configurations, build systems, packaging tools, available software, best practices, … diverge to much to offer official packages, scripts or anything else. We offer installation documentation for our components and this forum for discussing setup problems. Therefore Greenbone also doesn’t recommend any distribution nor do we prefer one distribution over the other. Most of the time we are even not aware which distribution ships which version of our software.
If you want to build from source you can try following https://sadsloth.net/post/install-gvm-20_08-src-on-debian/ for GVM 20.08 on Debian (should work for Ubuntu or Kali too). This guide is not maintained by Greenbone nor is it official in any kind but the community reported that it works well.
Which release contains which component? GOS version vs. GSE version?
It is often confusing to find out which software component of the Greenbone Source Edition belongs to which GVM release. Additionally the Greenbone OS used in the GSM Trial Virtual Machine had a different versioning scheme then GVM. We are aware of this and therefore with the 20.08 release we changed our versioning scheme to Calendar Versioning. With this change all software components (besides gvm-tools and python-gvm), GVM and GOS are using the same version.
|GVM 20.08||20.08||gvmd 20.08||GMP 20.08||20.08||gvm-libs 20.08||openvas 20.08||stable||2020-08-12|
|GVM 11||6||gvmd 9||GMP 9||9||gvm-libs 11||openvas 7||old stable (eol end of 2020)||2019-10-14|
|GVM 10||5||gvmd 8||GMP 8||8||gvm-libs 10||openvas-scanner 6||old old stable (eol end of 2020)||2019-04-05|
|OpenVAS 9||4||openvas-manager 7||OMP 7||7||openvas-libraries 9||openvas-scaner 5.1||community eol||2017-03-07|
My self compiled version of GVM isn't working as expected. Can you help me?
All questions in this forum are answered on voluntary basis. Therefore please don’t expect immediate responses. This is a forum for individuals to exchange experiences and problems about a Free Software project and not to get instance advises from the developers to fix your current issue.
If you are using a self-compiled version of our GVM stack (our Greenbone Source Edition) or from an external third party like a distribution please always check if you can reproduce the same behavior with our GSM Trial VM. 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 master 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. 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 this forum we always update the linked released versions which should be used and are known to work flawlessly.