I’m currently performing a security assessment for the SonarQube Docker image in a DOD tangential field, and am using a tool called Trivy (Trivy Open Source Vulnerability Scanner | Aqua) to perform this task. Upon scanning the latest Docker image available (as of writing, 9.8.0), several high/critical level vulnerabilities appear. I’ve attached the resulting .json report for reference. report.json (86.8 KB)
While some of these I can mitigate by creating a custom Dockerfile that uses Sonarqube as a base image while replacing the .jar’s outright (things like opt/sonarqube/elasticsearch/lib/snakeyaml-1.26.jar and opt/sonarqube/elasticsearch/modules/transport-netty4/netty-codec-4.1.66.Final.jar), there are several built in to Sonar built .jar files that I am unable to modify, namely opt/sonarqube/lib/sonar-application-9.8.0.63668.jar and sonar-scanner-engine-shaded-9.8.0.63668-all.jar.
I understand that a static analysis tool pointing out a potential vulnerability does not always lead to something actually exploitable, however in my position I’m unable to accept any high/critical vulnerabilities in these assessments outright regardless of context. Will these Java dependencies be updated in an upcoming release? If so, what is the target version?
which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
SonarQube Docker Image, 9.8.0-community
what are you trying to achieve
A Trivy scan free of high/critical level vulnerabilities
what have you tried so far to achieve this
Attempted to create a custom Dockerfile that will swap out standalone jars and replace them with the updated non-vulnerable versions, but enough vulnerabilities are baked into the sonar-scanner-engine and sonar-application jars that completely mitigating all of them is not possible.
Some dependencies listed in your report were updated for the (not being officially announced until tomorrow) v9.9 LTS, such as Hazelcast.
The docker image was made available this morning on DockerHub, so I suggest running any scans against that version.
Swapping in JARs is strictly unsupported – and we do run our own dependecy checks and evaluate whether or not a vulnerability may exist, like for the netty libraries embedded in Elasticsearch.
So any adjustments are done at your risk and haven’t been tested on our side.
Since 9.9 marks the LTS release for 9.X, will these dependencies be updated in 10.X?
Also, I understand the risk with regards to this admittedly janky ad-hoc jar swapping I have to do for the others. Unfortunately, in my position I have to attempt to mitigate as many vulnerabilities as possible, which can cause instability.
report-9.9.json (170.5 KB)
I’ve attached the latest scan results on 9.9.0-community. Absolutely better than before, but like I still cannot employ SonarQube fully until the aforementioned Critical/High CVE’s are patched out.
These are all related to transitive dependencies of dependencies where no upgrade is available that users the newer version. And in all cases, we’ve determined we aren’t vulnerable. No patch of these dependencies is planned.
You may be interested in using our image published in Iron Bank if you have DoD-related standards of security you must meet.