CVEs reported against dependencytrack/apiserver

[lokesh2019]

Hello,

We have just run Mend version 24.10.3 against a local deployment of latest Dependency-Track before we deploy it on our local network, and it has reported some CVEs against the Debian packages on dependencytrack/apiserver container.

I have found a similar discussion about a past version here: #3812 but that is against an older version of Dependency-Track so I hope this new thread is not inappropriate.

More information about the component versions:
Scanner: Mend, version 24.10.3

Dependency-Track versions from docker-compose up output:

dtrack-apiserver_1  | 2024-12-19 17:02:34,686 INFO [Config] --------------------------------------------------------------------------------
dtrack-apiserver_1  | 2024-12-19 17:02:34,687 INFO [Config] OS Name:      Linux
dtrack-apiserver_1  | 2024-12-19 17:02:34,687 INFO [Config] OS Version:   6.1.0-28-amd64
dtrack-apiserver_1  | 2024-12-19 17:02:34,687 INFO [Config] OS Arch:      amd64
dtrack-apiserver_1  | 2024-12-19 17:02:34,687 INFO [Config] CPU Cores:    12
dtrack-apiserver_1  | 2024-12-19 17:02:34,688 INFO [Config] Max Memory:   9.6 GB (10,309,074,944.0 bytes)
dtrack-apiserver_1  | 2024-12-19 17:02:34,688 INFO [Config] Java Vendor:  Eclipse Adoptium
dtrack-apiserver_1  | 2024-12-19 17:02:34,689 INFO [Config] Java Version: 21.0.4+7-LTS
dtrack-apiserver_1  | 2024-12-19 17:02:34,689 INFO [Config] Java Home:    /opt/java/openjdk
dtrack-apiserver_1  | 2024-12-19 17:02:34,689 INFO [Config] Java Temp:    /tmp
dtrack-apiserver_1  | 2024-12-19 17:02:34,689 INFO [Config] User:         dtrack
dtrack-apiserver_1  | 2024-12-19 17:02:34,690 INFO [Config] User Home:    /data/
dtrack-apiserver_1  | 2024-12-19 17:02:34,690 INFO [Config] --------------------------------------------------------------------------------
dtrack-apiserver_1  | 2024-12-19 17:02:34,690 INFO [Config] Initializing Configuration
dtrack-apiserver_1  | 2024-12-19 17:02:34,690 INFO [Config] System property alpine.application.properties not specified
dtrack-apiserver_1  | 2024-12-19 17:02:34,690 INFO [Config] Loading application.properties from classpath
dtrack-apiserver_1  | 2024-12-19 17:02:34,694 INFO [Config] --------------------------------------------------------------------------------
dtrack-apiserver_1  | 2024-12-19 17:02:34,694 INFO [Config] Application:  Dependency-Track
dtrack-apiserver_1  | 2024-12-19 17:02:34,694 INFO [Config] Version:      4.11.7
dtrack-apiserver_1  | 2024-12-19 17:02:34,694 INFO [Config] Built-on:     2024-08-14T12:37:10Z
dtrack-apiserver_1  | 2024-12-19 17:02:34,694 INFO [Config] --------------------------------------------------------------------------------
dtrack-apiserver_1  | 2024-12-19 17:02:34,695 INFO [Config] Framework:    Alpine
dtrack-apiserver_1  | 2024-12-19 17:02:34,695 INFO [Config] Version :     2.2.5
dtrack-apiserver_1  | 2024-12-19 17:02:34,695 INFO [Config] Built-on:     2024-02-29T20:30:01Z
dtrack-apiserver_1  | 2024-12-19 17:02:34,695 INFO [Config] --------------------------------------------------------------------------------

And the scan reports these packages as vulnerable:

apt_2.6.1_amd64.deb Low: 1
coreutils_9.1-1_amd64.deb Medium: 2
util-linux_2.38.1-5+deb12u1_amd64.deb Medium: 1
libgcc-s1_12.2.0-14_amd64.deb Medium: 1
libstdc++6_12.2.0-14_amd64.deb Medium: 1
libgcrypt20_1.10.1-3_amd64.deb High: 1
gcc-12-base_12.2.0-14_amd64.deb Medium: 1
tar_1.34+dfsg-1.2+deb12u1_amd64.deb Critical: 1

Could you please advise how best to upgrade and keep the packages up to date on the docker images?

Or, is it possible to deploy Dependency-Track outside of the containers? I realise this goes against docker's "it just works" deployment but it might help us keep on top of the linux packages. I have seen #2925 but it does not seem very encouraging.

[valentijnscholten]

The easiest solution is to update the Dockerfile to use the latest Alpine base image and build the containers yourself.
The build process is here: https://github.com/DependencyTrack/dependency-track/blob/master/.github/workflows/_meta-build.yaml

Even easier might be to look at the vulnerabilities and conclude they are not a high risk :-)