[Bug] Rootio Images are showing old false positives vulnerabilities that did not appear in "original" image

[benjifin]

IDs

CVE-2019-1010022 CVE-2019-1010023 CVE-2023-31486 CVE-2018-20796 CVE-2019-9192 CVE-2018-5709 CVE-2018-6951 CVE-2018-6829 CVE-2018-6952 CVE-2017-17740 CVE-2015-3276 CVE-2011-4116 CVE-2022-24975 CVE-2020-36325

Description

These vulnerabilities are showing up in many rootio images that did not appear in the original image. These all look to be old vulnerabilities that have been marked as false positives in someway by Debian, but are now being surfaced in our images.

Reproduction Steps

1. Scan an image before rootio has been processed on it - e.g. rootioinc/common-elasticsearch:9.0.1-bookworm-slim - get Trivy output
2. Scan the same image post rootio e.g. - rootioinc/common-elasticsearch:9.0.1-bookworm-slim_rootio
3. While vulnerabilities that were fixed by root no longer show up, these "new" vulnerabilities all suddenly appear in the report
...

Target

Container Image

Scanner

Vulnerability

Target OS

Debian: Bookworm (rootio)

Debug Output

Cant share this as too many characters, happy to share whatever snippet is required.

Version

Version: 0.64.1
Vulnerability DB:
  Version: 2
  UpdatedAt: 2025-07-09 06:28:13.697441436 +0000 UTC
  NextUpdate: 2025-07-10 06:28:13.697440865 +0000 UTC
  DownloadedAt: 2025-07-09 09:47:30.920413 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2025-07-02 04:02:48.924518349 +0000 UTC
  NextUpdate: 2025-07-05 04:02:48.924518238 +0000 UTC
  DownloadedAt: 2025-07-02 08:19:29.556587 +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

[benjifin]

@knqyf263 @DmitriyLewen can you guys look at this? Were ending up with tons of false positives in all our images now 😅

[benjifin]

This holds true across all scans we've done. Images that are not "rooted" do not have these vulns in Trivy scans, once we put the image through root - these vulns appear.

I'm happy with either solve - either that they don't show up in any scan, or that they show up in both if that's Trivy's approach - but the current situation where they don't show up in regular Debian images, but do show up in ours is problematic and I assume buggy behaviour :)

[DmitriyLewen]

perhaps i am missing something.
I added CVEs that you wrote in grep:

➜  ~ trivy -q image debian:12 --pkg-types os -f json --cache-backend memory | grep -E "CVE-2019-1010022|CVE-2019-1010023|CVE-2023-31486|CVE-2018-20796|CVE-2019-9192|CVE-2018-5709|CVE-2018-6951|CVE-2018-6829|CVE-2018-6952|CVE-2017-17740|CVE-2015-3276|CVE-2011-4116|CVE-2022-24975|CVE-2020-36325" | grep VulnerabilityID | sort -u
          "VulnerabilityID": "CVE-2011-4116",
          "VulnerabilityID": "CVE-2018-20796",
          "VulnerabilityID": "CVE-2018-6829",
          "VulnerabilityID": "CVE-2019-1010022",
          "VulnerabilityID": "CVE-2019-1010023",
          "VulnerabilityID": "CVE-2019-9192",
          "VulnerabilityID": "CVE-2023-31486",
➜  ~ trivy -q image rootioinc/common-elasticsearch:9.0.1-bookworm-slim --pkg-types os -f json --cache-backend memory | grep -E "CVE-2019-1010022|CVE-2019-1010023|CVE-2023-31486|CVE-2018-20796|CVE-2019-9192|CVE-2018-5709|CVE-2018-6951|CVE-2018-6829|CVE-2018-6952|CVE-2017-17740|CVE-2015-3276|CVE-2011-4116|CVE-2022-24975|CVE-2020-36325" | grep VulnerabilityID | sort -u
          "VulnerabilityID": "CVE-2011-4116",
          "VulnerabilityID": "CVE-2018-20796",
          "VulnerabilityID": "CVE-2018-6829",
          "VulnerabilityID": "CVE-2019-1010022",
          "VulnerabilityID": "CVE-2019-1010023",
          "VulnerabilityID": "CVE-2019-9192",
          "VulnerabilityID": "CVE-2023-31486",

debian:12 and your image have same CVEs

[benjifin]

@DmitriyLewen you are correct, it looks like there is some disrepancy in the way we parsed these CVEs. Thank you for jumping on this, and apologise for what looks like a false alarm. We can close out this report. Thanks again.

[knqyf263]

One possibility is that --ignore-unfixed is enabled somehow when scanning debian:12 through --ignore-unfixed flag, TRIVY_IGNORE_FIXED env, or trivy.yaml.

[benjifin]

👍 Thanks that's a good place for us to look - We also moved to using SBOM output rather than Trivy json in our scanning, I think this might be a difference we missed that we need to handle.

[benjifin]

OK so after digging into this deeper we've identified the actual issue it looks like, while all those CVEs do exist in the pre-root image the severity for them is defined as "low" while in the new scan they are defined as Critical or High.

We think this might be caused by Trivy now for some reason using a different severity source (NVD) in scans for us as oppose to the existing one (Debian in this case) and that the reason for this is because the ecosystem source for our images is now "root" and not "Debian" or whichever. We looked into the SBOM where the full severity data is provided, and each of these CVEs seems to match the "debian" source severity in the pre-root image, and the NVD severity in the post-root image, so this looks like the culprit.

Looking at the logic in the getVendorSeverity function that also seems to mesh - we are a different "source" so it defualt's to NVD.

Given we don't provide severity for vulnerabilities, the correct behaviour in Trivy should be to use the severity source of the underlining image, so if a root debian image - the severity source should be debian, if root ubuntu than ubuntu etc, and only then follow the next default pattern to NVD if that severity does not exist.

Does this make sense?

[DmitriyLewen]

I needed to be more precise 😄
I need a case where Trivy shows fixed version retrieved from the root.io feed.

[benjifin]

The use case you are describing can't really happen "naturally" (or is difficult to recreate) - because once we remediate we apply all our fixes to the post image, so there won't be any "fixed version" identified by Trivy, as the image is already upgraded with all available fixes.
But I'm not sure you need that - what we are seeing is that when the image has any rootio package in it then using the code I linked above Trivy switches the ecosystem of the entire image to root. Afterwards when it looks to grab a severity, the image is now considered root, and will not match the "debian" (or ubuntu, alpine etc) source severity provided.

[DmitriyLewen]

I tried to cover all possible cases.
Let's consider the case:
There is a root.io image (with one (or more) *.root.io.1 packages).
The image contains [email protected].

Just for example: you release a fix for CVE-2024-53427 (fixed_versions: [ "1.6-2.1.root.io.2" ]).

But the user has not updated their image yet.

So Trivy should show this vulnerability and severity level for this CVE.
We should take severity level from Debian source, right? Or should we use nvd source code (as first priority?)

[benjifin]

Ideally, the fact that an image has been "rooted" should not impact the general logic defined in getVendorSeverity at all - so yes in your use case we should show the Debian source.

[DmitriyLewen]

Created #9178