Trivy can't find installed version when scanning images of SpringBoot app

[ASarco]

IDs

Logback 1.2.13

Description

Trivy doesn't seem to detect the installed version of Logback (or any other dependency) if the version is overriden.

Due to the recent discovery of CVE-2023-6378, we updated Logback from 1.2.12 to 1.2.13

SpringBoot 2.7.x includes Logback 1.2.12 in its dependencies BOM, so to override it, we added:

<logback.version>1.2.13</logback.version>

to the pom.
But this apparently causes Trivy to be unable to find the installed version (1.2.13), and to keep reporting the vulnerability.
This seems to only happens when scanning a Docker image, and not the filesystem:

Java (jar)
==========
Total: 1 (HIGH: 1, CRITICAL: 0)

┌────────────────────────────────┬───────────────┬──────────┬────────┬───────────────────┬────────────────────────┬──────────────────────────────────────────────────────────┐
│            Library             │ Vulnerability │ Severity │ Status │ Installed Version │     Fixed Version      │                          Title                           │
├────────────────────────────────┼───────────────┼──────────┼────────┼───────────────────┼────────────────────────┼──────────────────────────────────────────────────────────┤
│ ch.qos.logback:logback-classic │ CVE-2023-6378 │ HIGH     │ fixed  │                   │ 1.3.12, 1.4.12, 1.2.13 │ logback: serialization vulnerability in logback receiver │
│                                │               │          │        │                   │                        │ https://avd.aquasec.com/nvd/cve-2023-6378                │
└────────────────────────────────┴───────────────┴──────────┴────────┴───────────────────┴────────────────────────┴──────────────────────────────────────────────────────────┘

I don't know if I'm doing something wrong, or there is a bug in Trivy.

Reproduction Steps

1. Run `trivy image` on a dockerized Spring Boot 2.7.x app that uses logback.
2. You will get an alert about CVE-2023-6378
3. Add `<logback.version>1.2.13</logback.version>` to the pom.xml
4. Recreate the container
5. Run `trivy image` again
6. Verify that you still get the alert, and Trivy doesn't detect the installed logback version (should be 1.2.13)

Target

Container Image

Scanner

Vulnerability

Target OS

Ubuntu 22.04

Debug Output

trivy image  --format json --exit-code  1 --ignore-unfixed --vuln-type  os,library --severity  CRITICAL,HIGH --timeout 10m 3d54466cc0270f5ed8ca3f027fcbea7493ed144ba59961aa586d0b77dab245f6 --debug
2023-12-11T15:29:08.387Z        DEBUG   Severities: ["CRITICAL" "HIGH"]
2023-12-11T15:29:08.388Z        DEBUG   Ignore statuses {"statuses": ["unknown","not_affected","affected","under_investigation","will_not_fix","fix_deferred","end_of_life"]}
2023-12-11T15:29:08.394Z        DEBUG   cache dir:  C:\Users\sarc83518\AppData\Local\trivy
2023-12-11T15:29:08.396Z        DEBUG   DB update was skipped because the local DB is the latest
2023-12-11T15:29:08.397Z        DEBUG   DB Schema: 2, UpdatedAt: 2023-12-11 12:11:42.075738895 +0000 UTC, NextUpdate: 2023-12-11 18:11:42.075738604 +0000 UTC, DownloadedAt: 2023-12-11 13:23:56.0695989 +0000 UTC
2023-12-11T15:29:08.402Z        INFO    Vulnerability scanning is enabled
2023-12-11T15:29:08.402Z        DEBUG   Vulnerability type:  [os library]
2023-12-11T15:29:08.402Z        INFO    Secret scanning is enabled
2023-12-11T15:29:08.402Z        INFO    If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2023-12-11T15:29:08.402Z        INFO    Please see also https://aquasecurity.github.io/trivy/v0.48/docs/scanner/secret/#recommendation for faster secret detection
2023-12-11T15:29:08.402Z        DEBUG   Enabling misconfiguration scanners: [azure-arm cloudformation dockerfile helm kubernetes terraform terraformplan]
2023-12-11T15:29:08.415Z        DEBUG   No secret config detected: trivy-secret.yaml
2023-12-11T15:29:08.415Z        DEBUG   The nuget packages directory couldn't be found. License search disabled
2023-12-11T15:29:08.415Z        DEBUG   No secret config detected: trivy-secret.yaml
2023-12-11T15:29:08.416Z        DEBUG   Image ID: sha256:3d54466cc0270f5ed8ca3f027fcbea7493ed144ba59961aa586d0b77dab245f6
2023-12-11T15:29:08.416Z        DEBUG   Diff IDs: [sha256:8ceb9643fb36a8ac65882c07e7b2fff9fd117673d6784221a83d3ad076a9733e sha256:9c79d2d925a7ea64395c6a2e4b97adf997782442fd3e9a274a360f50355f361e sha256:d99b20f3567b634920e8ec30d57f07f526ca3336ee391dbac4b2d2a011c1885b sha256:a102bf278b817d0ae92fc8401eac1e011a711426a6cad6a340de7b1dbee92277 sha256:9075b61192695f9bbebda270b4d09137bde06ec6333108acbd83bdb76fda47fb sha256:c11e80fd33fc32e642e4cf733aa34cf76c90e5478a31b28da75d973ed90c4b1b sha256:5841a3a1f30c3782aaf47023047de4bf77c85138429435a0e269cb9c762bf2bc sha256:2dd1167e013198a431fa11d85b0c00c2a0c9776b940ba21f444dd75049347d80 sha256:417e5bfc3c82b9373cf6804206e071d2fc74560df867d0f39cb21ac3d15231b6 sha256:c919858645ae24f04f234284b673d46e8e238b7068b17c85d2d9d4ac99b7952a sha256:585d8b141d7aa07eecde5a1bae075c7898ab5809a215d66f160d3dfd46eaf577 sha256:366ce7d1a7f90f2e4ad08752f87510eee3ffca18736fa63c03823c8c4ebf2925 sha256:90b0eb2b67f4a97da19dd7927a2ac9f1764454ea16450b56d5a2121c97789b2f sha256:b0345aa516fe08acaea7594d723b69b5263787240a6cd3c86f317126960f8954 sha256:ab99df5db2b97d32fa490bf9196b11e367a7f722f7df9f914fbfe4914305e43e sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef sha256:4b05ee4d02d3555ba4098b3f17912e1ea8831608faa59a5d3bcd4d8b4e521afa sha256:52bdf732d0aa5634fcdba04f56236d8788875d9111055af7f2b7e7cce5d7f782 sha256:9b01e3d17226cb926d56787ba05c9ce5d6a3495d352e7d960be6e5657fb88f58 sha256:fe1f734439e11d4ce8912d67204180d6ce000a7f3e620a3ed91113107eff8059 sha256:1dc94a70dbaa2171fb086500a5d27797f779219b126b0a1eebb9180c2792e80e]
2023-12-11T15:29:08.416Z        DEBUG   Base Layers: []
2023-12-11T15:29:08.428Z        INFO    Detected OS: ubuntu
2023-12-11T15:29:08.428Z        INFO    Detecting Ubuntu vulnerabilities...
2023-12-11T15:29:08.428Z        DEBUG   ubuntu: os version: 22.04
2023-12-11T15:29:08.428Z        DEBUG   ubuntu: the number of packages: 108
2023-12-11T15:29:08.429Z        INFO    Number of language-specific files: 5
2023-12-11T15:29:08.430Z        INFO    Detecting gobinary vulnerabilities...
2023-12-11T15:29:08.430Z        DEBUG   Detecting library vulnerabilities, type: gobinary, path: layers/paketo-buildpacks_ca-certificates/helper/helper
2023-12-11T15:29:08.430Z        DEBUG   Detecting library vulnerabilities, type: gobinary, path: layers/paketo-buildpacks_spring-boot/helper/helper
2023-12-11T15:29:08.430Z        DEBUG   Detecting library vulnerabilities, type: gobinary, path: layers/paketo-buildpacks_adoptium/helper/helper
2023-12-11T15:29:08.431Z        DEBUG   Detecting library vulnerabilities, type: gobinary, path: cnb/lifecycle/launcher
2023-12-11T15:29:08.431Z        INFO    Detecting jar vulnerabilities...
2023-12-11T15:29:08.431Z        DEBUG   Detecting library vulnerabilities, type: jar, path:
2023-12-11T15:29:08.444Z        DEBUG   Found an ignore file: .trivyignore
2023-12-11T15:29:08.445Z        DEBUG   Ignored {"id": "CVE-2017-5929", "path": "Java"}
2023-12-11T15:29:08.445Z        DEBUG   Ignored {"id": "CVE-2012-6153", "path": "Java"}
2023-12-11T15:29:08.445Z        DEBUG   Ignored {"id": "CVE-2016-1000027", "path": "Java"}
2023-12-11T15:29:08.445Z        DEBUG   Ignored {"id": "CVE-2016-1000027", "path": "Java"}

Version

Version: 0.48.0
Vulnerability DB:
  Version: 2
  UpdatedAt: 2023-12-11 12:11:42.075738895 +0000 UTC
  NextUpdate: 2023-12-11 18:11:42.075738604 +0000 UTC
  DownloadedAt: 2023-12-11 13:23:56.0695989 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2023-12-11 00:49:01.121535103 +0000 UTC
  NextUpdate: 2023-12-14 00:49:01.121534983 +0000 UTC
  DownloadedAt: 2023-12-11 13:30:07.9686834 +0000 UTC

Checklist

• Read the documentation regarding wrong detection
• Ran Trivy with -f json that shows data sources and confirmed that the security advisory in data sources was correct

[DmitriyLewen]

Hello @ASarco
Thanks for your report!

Looks like Trivy can't find version for your SpringBoot app.
Can you share test image to investigation?

[re3turn]

Possibly unable to discover library information for direct dependencies.
gradle/gradle#23578

[DmitriyLewen]

yes. This is possible.

[ASarco]

Possibly unable to discover library information for direct dependencies. gradle/gradle#23578

I'm not using Gradle, I'm using Maven.

[ASarco]

Hello @ASarco Thanks for your report!

Looks like Trivy can't find version for your SpringBoot app. Can you share test image to investigation?

I can't reproduce this with a minimum SpringBoot 2.7.x project. And I can't send you an image of the real application for obvious reasons.
So the problem must be somewhere else.

[DmitriyLewen]

Okay. Then i need your help with this:

Scan your image with -f json --list-all-pkgs flags.
In result you need to find ch.qos.logback:logback-classic package and check FilePath.
If it is separate jar file - it should just be package jar and you can send it.
If this is part of your app jar:

• if path contains 2 (or more) jar files (e.g. ./app.jar/dir/ch.qos.logback:logback-classic-1.2.x.jar) - unzip your app jar and send me this (ch.qos.logback:logback-classic-1.2.x.jar) jar file
• if path only contains single jar - you need to unzip your app jar and find all pom.properties files. One of these files contains info about ch.qos.logback:logback-classic. Find it and send me content of this file.

[DavidACastagna]

I wasn't sure if I should add this here or log a new issue but this looks very similar to what we're seeing.

1. I run trivy images on a base image (yuzutech/kroki:0.24.1) which comes up with a whole bunch of fixes to make (libraries to update)
2. Then I create a wrapper Dockerfile which uses apt-get to execute all of the suggested library updates.
3. Then I build this new Dockerfile to produce a new image.
4. I scan it and trivy image <new-image> produces exactly the same report as before (it sees none of the package updates).
5. To verify that the updates actually occurred I did a docker run as root and checked the stalled packages with apt show <package>. This shows the packages are in fact updated.

This is particularly problematic since any attempt to squash layers or to use expressions like: FROM ... as base + FROM scratch + COPY --from=base / / will all end up erasing the base-image's ENTRYPOINT or ENV settings which are critical to making the image work properly.

So to summarize: To harden a base image I run a scan, install package upgrades via an enclosing Dockerfile, scan again and see no changes.

I'm hoping the issue is simple to resolve with a trivy option of some kind? But I'm guessing that there is something more difficult going on here.

If it matters, the following is the Dockerfile with the suggested changes in it:

FROM docker.io/yuzutech/kroki:0.24.1
USER root
RUN apt-get update
RUN apt-get upgrade -y
RUN apt-get install -y bash curl libcurl4 libc6 libc-bin libgssapi-krb5-2 libk5crypto3 \
                   libkrb5-3 libkrb5support0 libnghttp2-14 libprocps8 libgnutls30 \
                   libldap-2.5-0 libpam-modules libpam-modules-bin libpam-runtime \
                   libpam0g locales login libgssapi-krb5-2 libssl3 zlib1g libssh-4 \
                   openssl passwd perl-base procps tar
HEALTHCHECK CMD curl --fail http://localhost:3000 || exit 1
USER kroki

A scan of the base third-party image shows (among lots of other things) these two packages needing updates:

 │ curl               │ CVE-2023-46218 │ MEDIUM   │ fixed    │ 7.81.0-1ubuntu1.14           │ 7.81.0-1ubuntu1.15           │ curl: information disclosure by exploiting a mixed case flaw │
│ libc-bin           │ CVE-2023-5156  │ MEDIUM   │ fixed    │ 2.35-0ubuntu3.4              │ 2.35-0ubuntu3.5              │ glibc: DoS due to memory leak in getaddrinfo.c               │

To verify the image contains the right stuff I ran apt show on curl and libc-bin and got:

root@01acd61ff1b7:/# apt show curl
Package: curl
Version: 7.81.0-1ubuntu1.15
Priority: optional
. . .
root@01acd61ff1b7:/# apt show libc-bin
Package: libc-bin
Version: 2.35-0ubuntu3.6
Priority: required
. . .

Which are upgraded from the baseline and match or exceed what was in the original trivy report.

[DmitriyLewen]

Hello @DavidACastagna
Your problem doesn't related with this case.

Can you open new discussion for this issue?

Regards, Dmitriy