1642 Write down decision about OpenVAS integration

Weltraumschaf · J12934 · commit dcd18cdadddb · 2023-10-25T10:36:09.000+02:00
Signed-off-by: Sven Strittmatter &lt;sven.strittmatter@iteratec.com&gt;
diff --git a/documentation/docs/architecture/09_architecture_decisions/adr_0019.md b/documentation/docs/architecture/09_architecture_decisions/adr_0019.md
@@ -10,7 +10,7 @@ sidebar_label: "ADR-0019"
 
 | <!-- -->       | <!-- -->                                                                                     |
 |----------------|----------------------------------------------------------------------------------------------|
-| **Status**:    | DRAFT                                                                                        |
+| **Status**:    | ACCEPTED                                                                                     |
 | **Date**:      | 2023-09-14                                                                                   |
 | **Author(s)**: | Heiko Kiesel <heiko.kiesel@iteratec.com>, Sven Strittmatter <sven.strittmatter@iteratec.com> |
 
@@ -29,25 +29,27 @@ Technically, one can communicate to parts of OpenVAS with two protocols. The Ope
 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.
 
 
-### Problem
+### 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.
 
-TODO: do we even need it?
+### Possible Solution
 
-### Solutions
+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.
 
-TODO
+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
 
-TODO
+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
 
-TODO
+- Users need to operate two complete systems.
 
 [Issue 1642]: https://github.com/secureCodeBox/secureCodeBox/issues/1642
 [OpenVAS]: https://openvas.org/
@@ -56,3 +58,4 @@ TODO
 [Minimal OpenVAS Docker setup]: https://forum.greenbone.net/t/minimal-docker-setup-with-python-gvm-osp-api/15630
 [python-gvm]: https://python-gvm.readthedocs.io/en/latest/usage.html
 [Persistence Hook]: https://www.securecodebox.io/docs/hooks/defectdojo
+[DefectDojo]: https://owasp.org/www-project-defectdojo/
