Skip to main content

ADR-0019: OpenVAS Integration

Status:ACCEPTED
Date:2023-09-14
Author(s):Heiko Kiesel heiko.kiesel@iteratec.com, Sven Strittmatter sven.strittmatter@iteratec.com

Context​

In the past, there were multiple requests for an OpenVAS integration (e.g., Issue 1642). OpenVAS is an all-in-one solution, consisting of a scanner, database, frontend dashboard, and so on. Its architecture is shown in detail on their OpenVAS architecture page.

The scanner uses the NASL Attack Scripting Language to implement vulnerability tests. These tests are fetched periodically from the free Greenbone Community Feed or the paid Greenbone Enterprise Feed. These feeds combine Network Vulnerability Tests, CVEs, CPEs, CERT-Bund-Advisories, and DFN-CERT-Advisories.

The offered vulnerability tests offer another type of scans compared to secureCodeBox. They seem to be more focussed on particular CVE's, outdated service versions and advisories. Moreover, some vulnerabilities, for example SSH weaknesses, are already covered in our offered scanners, e.g., ssh_scan and ssh-audit. The question is whether the tests offered by OpenVAS are already covered by secureCodeBox.

The scanners and their corresponding parsers in secureCodeBox are implemented with Docker containers. We either dockerized them ourselves or used provided ones. Greenbone also provides a dockerized version of their OpenVAS scanner in a Docker Compose file.

Technically, one can communicate to parts of OpenVAS with two protocols. The Open Scanner Protocol is provided by ospd-openvas. With that, it is possible to start scans, get Vulnerability Tests information and receive scan results. The Greenbone Management Protocol allows to communicate with the core OpenVAS Greenbone Security Assistant. With it, one can create, read, update and delete scans and vulnerability information. These two protocols are available in the official python-gvm package.

Furthermore, OpenVAS offers another type of scans (vulnerability tests). They seem to be more focussed on particular CVE's, outdated service versions and advisories. Moreover, some vulnerabilities, for example SSH weaknesses, are already covered in our offered scanners, e.g., ssh_scan and ssh-audit.

Problematic Container Setup of OpenVAS​

Due to OpenVAS being an all-in-one solution, the Docker Compose file consists of 16! containers. As we only need support for the Open Scanner Protocol, we tried to isolate the ospd-openvas container - the core scanner component. However, it seems like that it is only possible to reave out the container serving the frontend. It is not possible to isolate the scanner. Thus, we need to include the whole OpenVAS setup. For more information see my question regarding a Minimal OpenVAS Docker setup.

In contrast, secureCodeBox integrates more than 20 independent scanning tools. Each scanning tool is available as a docker container (and the corresponding parsing container). Unlike OpenVAS, only two containers (the operator and MinIO) must be running all the time. The other containers are created and stopped on runtime.

Possible Solution​

A more or less reasonable solution could be to run OpenVas as a whole besides secureCodeBox and use secureCodeBox to trigger OpenVAS scans. But there is currently no mechanism implemented to trigger scans outside the secureCodeBox. It may be possible to use a read-hook to do that.

It is unclear how we could read the findings from OpenVAS back into the secureCodeBox because the design of our architecture does not provide a mechanism for that. Currently test results a lurked by a scanner's sidecar container. We're not sure if this is even possible with OpenVAS.

Decision​

We will not integrate OpenVAS into the secureCodeBox because of its nature as a whole ecosystem and for the problems mentioned above.

Albeit, we think that OpenVAS – but we have very view experience with it – may be a good choice to scan infrastructure additionally to the secureCodeBox. At the moment we think a better solution would be to run OpenVAS as a whole besides secureCodeBox and feed the results from both systems into DefectDojo.

Consequences​

  • Users need to operate two complete systems.