Vulnerability versions in pom.xml are not found if the version is referenced from a variable

[blaargh]

Description

When a dependency from maven looks like this:

where the actual dependency version is referenced with a variable, Trivy does not find this vulnerable version

If its explicitly listed like this:

the vulnerability is detected correctly

Desired Behavior

The vulnerable version should be found

Actual Behavior

The vulnerable version is not found

Reproduction Steps

1. Build a jar with for example https://mvnrepository.com/artifact/com.networknt/json-schema-validator/1.0.43
2. Do a scan via trivy rootfs json.jar

Target

Filesystem

Scanner

Vulnerability

Output Format

Table

Mode

Standalone

Debug Output

trivy rootfs json.jar --debug
2023-10-16T13:39:14.316+0200    DEBUG   Severities: ["UNKNOWN" "LOW" "MEDIUM" "HIGH" "CRITICAL"]
2023-10-16T13:39:14.317+0200    DEBUG   Ignore statuses {"statuses": null}
2023-10-16T13:39:14.320+0200    DEBUG   cache dir:  /home/lla/.cache/trivy
2023-10-16T13:39:14.320+0200    DEBUG   DB update was skipped because the local DB is the latest
2023-10-16T13:39:14.320+0200    DEBUG   DB Schema: 2, UpdatedAt: 2023-10-16 06:19:40.151341334 +0000 UTC, NextUpdate: 2023-10-16 12:19:40.151341034 +0000 UTC, DownloadedAt: 2023-10-16 08:09:53.329493033 +0000 UTC
2023-10-16T13:39:14.320+0200    INFO    Vulnerability scanning is enabled
2023-10-16T13:39:14.320+0200    DEBUG   Vulnerability type:  [os library]
2023-10-16T13:39:14.321+0200    INFO    Secret scanning is enabled
2023-10-16T13:39:14.321+0200    INFO    If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2023-10-16T13:39:14.321+0200    INFO    Please see also https://aquasecurity.github.io/trivy/v0.45/docs/scanner/secret/#recommendation for faster secret detection
2023-10-16T13:39:14.321+0200    DEBUG   No secret config detected: trivy-secret.yaml
2023-10-16T13:39:14.321+0200    DEBUG   Walk the file tree rooted at 'json.jar' in parallel
2023-10-16T13:39:14.321+0200    INFO    JAR files found
2023-10-16T13:39:14.322+0200    INFO    Analyzing JAR files takes a while...
2023-10-16T13:39:14.322+0200    DEBUG   Parsing Java artifacts...       {"file": "json.jar"}
2023-10-16T13:39:14.325+0200    DEBUG   OS is not detected.
2023-10-16T13:39:14.325+0200    DEBUG   Detected OS: unknown
2023-10-16T13:39:14.325+0200    INFO    Number of language-specific files: 1
2023-10-16T13:39:14.325+0200    INFO    Detecting jar vulnerabilities...
2023-10-16T13:39:14.325+0200    DEBUG   Detecting library vulnerabilities, type: jar, path:

Operating System

Windows 10 with Ubuntu WSL2

Version

Version: 0.45.1
Vulnerability DB:
  Version: 2
  UpdatedAt: 2023-10-16 06:19:40.151341334 +0000 UTC
  NextUpdate: 2023-10-16 12:19:40.151341034 +0000 UTC
  DownloadedAt: 2023-10-16 08:09:53.329493033 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2023-10-16 00:56:02.324200576 +0000 UTC
  NextUpdate: 2023-10-19 00:56:02.324200176 +0000 UTC
  DownloadedAt: 2023-10-16 08:10:24.208197242 +0000 UTC

Checklist

• Run trivy image --reset
• Read the troubleshooting

[DmitriyLewen]

Hello @blaargh
Thanks for your report!

You wrote about pom.xml file, but you scanned jar files (2023-10-16T13:39:14.325+0200 DEBUG Detecting library vulnerabilities, type: jar, path:).

Can you try scanning your pom.xml files in fs mode?

[blaargh]

I can try the pom.xml directly, but that is not our use case. In fact, we usually scan docker images via the Harbor integration of Trivy. What we witnessed there was, it doesn't matter if the jar within the docker image actually contains a vulnerable library. Only the meta information are scanned. This lead to a false positive for Snakeyaml 1.33, where we had explicitly version 2.2 in our jar, but some library mentions a dependency on version 1.33 in their meta data, even though there was no file with that version present.

We then tried to debug this, to see if there were any false negatives we didn't catch. And this mentioned json library was one of them. The jar explicitly contained this version, and it still didn't find it because the metadata looked like the Screenshot, at least that is our assumption.

[DmitriyLewen]

Okay, can you scan your image with the -f json --list-all-pkgs flags and check the filepath field for Snakeyaml to see the path to the jar file with the wrong version of Snakeyaml and send it to me is this jar file for investigation?

[blaargh]

Yup, I will prepare the jar and send it to you today. Thank you!