Missing (documentation of) detection of CVEs in the main package of Docker images

[MShekow]

Question

I recently realized a very irritating behavior of Trivy (also present in other scanners like Grype): Trivy often does not report vulnerabilities for the actual software that a Docker image is about (while successfully reporting CVEs for all downstream components the software depends upon, e.g. SSL, glibc, etc.).

Examples:

• In postgres:16.4, PostgreSQL < 16.5 (and thus, 16.4) is affected by CVE-2023-24329 and various other CVEs, see here - but Trivy does not find them in the image
  • interestingly, Trivy does find them in bitnami/postgresql:16.4.0
• In grafana/grafana:11.0.0, Grafana is affected by CVE-2024-9264 (see here), Trivy does not find it
• In mongo:6.0.2, Trivy finds no MongoDB-related vulnerabilities even though there are several (such as CVE-2024-8207), see here

I'm probably misunderstanding something. I could easily produce many more examples, this happens for basically every other popular Docker image.

I'm aware that some of the CVEs I mentioned are only conditionally exploitable (e.g. the one for Grafana requires a DuckDB binary on PATH). Is Trivy so smart that it can determine the exploitability, and thus not report CVEs which are not exploitable anyway? Or can Trivy sometimes not detect the version of the software properly, thus there's already a "hole" in the SBOM? (for instance, when generating a SPDX SBOM for grafana/grafana:11.0.0, I don't see any entry for "Grafana" with "versionInfo: 11.0.0" in the packages array of the SBOM file). Could be related to issues like #7745

I'm sure there is a good explanation (that is, a technical reason) for each of the examples I posted. I'm not even asking you to look into these individual examples. But I'm wondering whether such issues are documented anywhere?

Target

Container Image

Scanner

Vulnerability

Output Format

Table

Mode

Standalone

Operating System

Ubuntu

Version

0.58.0

[DmitriyLewen]

Hello @MShekow
Thanks for your interest to Trivy!

Trivy only supports Go and Rust binaries - https://trivy.dev/latest/docs/coverage/language/#supported-languages.
(issue with determining main module version of Go binary - https://trivy.dev/latest/docs/coverage/language/golang/#main-module).

Also Trivy can detect application installed from package managers - https://trivy.dev/latest/docs/coverage/os/#supported-os

So if application was copied as binary - Trivy may not detect this package and vulnerabilities for it.

[DmitriyLewen]

Unfortunately, there are no markers to determine that the found binary file is the "main" binary of the image (for example, grafana).
Not always images contain the "main" binary or use it as an endpoint.

And issuing a notification for any unscannable binary would be too noisy and could discourage or confuse users.

Just for info - Aqua scanner supports more binaries - https://trivy.dev/latest/commercial/compare/#vulnerability-scanning

[MShekow]

I understand what you mean. I also would not want a scanner like Trivy to always print warnings in such cases.

I am merely suggesting a sentence/paragraph in the container image documentation that informs users about exactly those things you mentioned in this thread. That paragraph should also mention the consequences: there is a considerable chance that Trivy will be unable to detect certain dependencies, such as the main software of the image. And because of that, teams would have to take other measures to address this (e.g. hand-crafted scripts that look up vulnerabilities in an API, or a GitHub Actions workflow that manually adds dependencies (that Trivy missed) to the Dependency Graph, so that Dependabot can cover them).

[DmitriyLewen]

hm.. perhaps you are right.
we maintainers are used to some limitations and nuances that are not obvious to users.
can you create a PR based on your experience to update the documentation?

[knqyf263]

There is a note here.
https://trivy.dev/latest/docs/scanner/vulnerability/#os-packages

[MShekow]

Fair enough, that's what I was looking for. The only suggestion I have: add a second sentence to that existing note that demonstrates the consequence so that it reads e.g. like this:

Trivy doesn't support third-party/self-compiled packages/binaries, but official packages provided by vendors such as Red Hat and Debian. Consequently, Trivy might be unable to detect vulnerabilities in the main package of a Docker image, since Docker images often include such self-compiled packages/binaries.