JanusGraph official dockers fail vulnerability scans with alarming number of critical vulnerabilities

[havascolino]

The new version 1.0rc1-rc2
have a lower number of vulnerabilities 3-4 in the fallowing jar files
rc1
org.apache.hadoop_hadoop-common version 2.10.2 has 1 vulnerability
org.apache.hadoop_hadoop-common version 3.3.1 has 2 vulnerabilities
com.fasterxml.jackson.core_jackson-databind version 2.4.0 has 1 vulnerability

rc2 has only the last two

the origin of the problem is the fallowing layer
ADD file:18e71f049606f6339ce7a995839623f50e6ec6474bfd0a3a7ca799db726f47f6 in /
which seems to be not upto date

the 6.3 version has 10 vulnerabilities
from the fallowing layer

ENV JANUS_VERSION=0.6.3 JANUS_HOME=/opt/janusgraph JANUS_CONFIG_DIR=/etc/opt/janusgraph JANUS_DATA_DIR=/var/lib/janusgraph JANUS_SERVER_TIMEOUT=30 JANUS_STORAGE_TIMEOUT=60 JANUS_PROPS_TEMPLATE=berkeleyje-lucene JANUS_INITDB_DIR=/docker-entrypoint-initdb.d gremlinserver.graphs.graph=/etc/opt/janusgraph/janusgraph.properties gremlinserver.threadPoolWorker=1 gremlinserver.gremlinPool=8

with these cve

org.apache.hadoop_hadoop-common	2.8.5	CVE-2022-26612	critical
org.apache.hadoop_hadoop-common	2.8.5	CVE-2022-25168	critical
log4j_log4j	1.2.17	CVE-2022-23305	critical
org.apache.hadoop_hadoop-common	2.8.5	CVE-2021-37404	critical
log4j_log4j	1.2.17	CVE-2020-9493	critical
io.netty_netty-all	4.1.34.Final	CVE-2019-20445	critical
io.netty_netty-all	4.1.34.Final	CVE-2019-20444	critical
log4j_log4j	1.2.17	CVE-2019-17571	critical
com.nimbusds_nimbus-jose-jwt	4.41.1	CVE-2019-17195	critical
com.fasterxml.jackson.core_jackson-databind	2.4.0	CVE-2018-7489	critical

org.apache.hadoop_hadoop-common 2.8.5 [CVE-2022-26612](https://nvd.nist.gov/vuln/detail/CVE-2022-26612) critical org.apache.hadoop_hadoop-common 2.8.5 [CVE-2022-25168](https://nvd.nist.gov/vuln/detail/CVE-2022-25168) critical log4j_log4j 1.2.17 [CVE-2022-23305](https://nvd.nist.gov/vuln/detail/CVE-2022-23305) critical org.apache.hadoop_hadoop-common 2.8.5 [CVE-2021-37404](https://nvd.nist.gov/vuln/detail/CVE-2021-37404) critical log4j_log4j 1.2.17 [CVE-2020-9493](https://nvd.nist.gov/vuln/detail/CVE-2020-9493) critical io.netty_netty-all 4.1.34.Final [CVE-2019-20445](https://nvd.nist.gov/vuln/detail/CVE-2019-20445) critical io.netty_netty-all 4.1.34.Final [CVE-2019-20444](https://nvd.nist.gov/vuln/detail/CVE-2019-20444) critical log4j_log4j 1.2.17 [CVE-2019-17571](https://nvd.nist.gov/vuln/detail/CVE-2019-17571) critical com.nimbusds_nimbus-jose-jwt 4.41.1 [CVE-2019-17195](https://nvd.nist.gov/vuln/detail/CVE-2019-17195) critical com.fasterxml.jackson.core_jackson-databind 2.4.0 [CVE-2018-7489](https://nvd.nist.gov/vuln/detail/CVE-2018-7489) critical

Solving these vulnerabilities at the source could help organizations trying to adopt Janusgraph do so with ease and safety.

[FlorianHockmann]

Thanks for the report!

For the 1.0.0-rc2 image: We should not be using these versions of the dependencies listed in the report, but I guess we're getting them as a peer dependency. We should definitely investigate this.
This is also something that we should notice automatically through the code scanning that we already have in place for the Docker images. Unfortunately, it currently produces so many alerts and doesn't give us much information that we could use to filter them. The problem here is mostly that the 0.5 image is producing a very high number of alerts which isn't a big surprise as JanusGraph doesn't release new versions of that release branch any more.
I have created an issue to improve this situation with code scanning in general: #130.

Regarding the 0.6.3 image: Some of these vulnerabilities are probably expected as we are using dependencies on the 0.6 branch like Log4j 1 which isn't maintained any more, but updating them would be a breaking change. So, we will only update them in 1.0.0.
But another problem for the 0.6.3 image is that our approach of automating dependency updates has some limitations right now which results in some dependencies not being updated on that branch: JanusGraph/janusgraph#3653.

One general note regarding such automatic vulnerability scanners: Only because we have a dependency (or a peer dependency) on a version of a library where a vulnerability was found of course doesn't mean that JanusGraph is vulnerable. The vulnerability can be in a code path that isn't used by JanusGraph at all. In order to assess whether these vulnerabilities are really a problem for JanusGraph we have to check each vulnerability report to determine under which circumstances it can be used.
Nevertheless, it would of course be good if JanusGraph would only have dependencies without known vulnerabilities and we should definitely work on improving this situation (hence the issues I mentioned / created).

Since your scan only found two vulnerabilities for 1.0.0-rc2, it's probably a good idea to go with that version, even if it's currently a release candidate.