Trivy reports vulnerabilities from pip embedded CycloneDX SBOM instead of installed Python packages #11031
Replies: 3 comments
|
This is two different analyzers disagreeing, and the fix is to stop trusting the stale one. Trivy runs several analyzers over the same filesystem, and here two of them both report Python packages:
So it isn't that Trivy is re-reading pip and getting old data — there's a physical SBOM file baked into the image with pre-upgrade versions, and the Find the stale SBOMfind / \( -name '*.cdx.json' -o -name '*.bom.json' -o -name 'bom.json' \
-o -name '*.spdx.json' -o -name '*.spdx' \) 2>/dev/nullIt's usually left behind by a build step, a base image, or a tool that emits a bill-of-materials at build time and never refreshes it after you Or tell Trivy to ignore itIf you can't remove the file, disable the SBOM analyzer so Trivy only trusts live package metadata: trivy fs --scanners license,vuln,secret,misconfig \
--disable-analyzers sbom \
--license-full --format cyclonedx <target>( Quick way to confirm which analyzer is the culprit before you change anything: |
|
A slightly more detailed answer, in addition to #11031 (comment). What's going onThanks for the detailed investigation — you tracked the source down correctly, and I reproduced all of it locally. Starting with pip 26.2 (released 2026-07-29), pip ships a CycloneDX document listing its vendored dependencies: Trivy automatically looks for files with One important point: the SBOM neither overrides python-pkg nor is it out of date. Both entries are present in the report at the same time. Why the versions don't matchpip cannot depend on external packages: it repairs environments and may upgrade or remove a package it uses itself in the process. # inside pip
from pip._vendor import requests # its own copy
# in project code
import requests # whatever is installed in site-packagesTwo independent modules that neither see nor conflict with each other.
Had you not upgraded these two particular packages, the versions would have matched and looked like an exact duplicate. How real the findings areThe three IDs need to be treated differently. CVE-2025-47273 and CVE-2026-59890 (setuptools 70.3.0) are false positives, and the cause is pip's own metadata.
There is no GHSA-6v7p-g79w-8964 (msgpack 1.1.2) — the version really is vulnerable, but the vulnerable code path isn't executed in pip. msgpack.dumps(data, use_bin_type=True) # serialize.py:63
msgpack.loads(data, raw=False) # serialize.py:142The advisory, however, describes reusing a streaming Answers to your questions
trivy image --skip-files "**/pip/_vendor/bom.cdx.json" <image>We verified this — all three findings disappear (the same workaround is suggested in #11031 (comment)). One small correction to that same comment: there is no Why we're not excluding this file on our sideWe did consider it — there's a precedent: in v0.69.0 we excluded the That one was a literal duplicate, this one isn't. Some of these findings are genuinely useful. There's no alternative source for this information.
So a separate pip advisory for a vulnerability in a vendored library shouldn't be expected unless pip considers its own usage affected. What we will fixThe main problem with this report isn't the findings themselves but the fact that their origin isn't visible. We already have several related issues about filling in
Worth noting separately that the source can already be told apart today (this is mentioned in #11031 (comment) as well) — in the JSON output every package carries an trivy image -f json <image> | jq '.Results[] | select(.Type=="python-pkg") | .Packages[]
| {Name, Version, AnalyzedBy, FilePath}'{ "Name": "setuptools", "Version": "83.0.0", "AnalyzedBy": "python-pkg",
"FilePath": "usr/local/lib/python3.12/site-packages/setuptools-83.0.0.dist-info/METADATA" }
{ "Name": "setuptools", "Version": "70.3.0", "AnalyzedBy": "sbom",
"FilePath": null }In your image this separates 15 packages from VerdictFor now we're not going to exclude the file, and we'd like to gather feedback first. If the findings are in your way right now, the workaround is to exclude the file: trivy image --skip-files "**/pip/_vendor/bom.cdx.json" <image> |
|
Thanks! We have created a small rego file to ignore those findings. We have used To use it: |
Uh oh!
There was an error while loading. Please reload this page.
IDs
GHSA-6v7p-g79w-8964, CVE-2025-47273,CVE-2026-59890
Description
Trivy Version
Version: 0.71.2
Vulnerability Database
Latest DB (Updated: 2026-07-31)
Environment
Description
Trivy reports false-positive vulnerabilities for Python packages even though the packages have already been upgraded inside the container.
Runtime verification
However, Trivy reports the following installed versions:
The reported vulnerabilities are:
Investigation
After investigating, I found that Trivy detects two versions of the same packages.
python-pkg analyzer
sbom analyzer
The older versions originate from:
The runtime packages are correct, but Trivy appears to associate vulnerabilities with the packages discovered from the embedded CycloneDX SBOM instead of the actual installed Python packages.
Expected Behavior
Trivy should prioritize the packages detected by the python-pkg analyzer (runtime installed packages) over the packages referenced in
pip/_vendor/bom.cdx.json.Alternatively, the embedded pip vendor SBOM should not override the actual installed package versions when reporting vulnerabilities.
Additional Information
During the investigation, I:
/usr/local/lib/python3.12/site-packages/pip/_vendor/bom.cdx.jsonThis file contains references such as:
Even though the container has newer versions installed, Trivy reports vulnerabilities against the older SBOM package versions.
Questions
Is this expected behavior when Trivy detects packages from both the
python-pkganalyzer and an embedded CycloneDX SBOM?Should Trivy prioritize the runtime packages detected by the
python-pkganalyzer over the packages referenced inpip/_vendor/bom.cdx.json?Is the embedded
pip/_vendor/bom.cdx.jsonintended to be treated as an authoritative SBOM during vulnerability matching?Is there a recommended way to prevent Trivy from reporting vulnerabilities based on the embedded pip SBOM while still scanning the actual installed Python packages?
Does Trivy provide an option to ignore or disable scanning of embedded CycloneDX SBOM files such as
pip/_vendor/bom.cdx.json?Any guidance on whether this is expected behavior or a bug would be appreciated.
Reproduction Steps
--- ### Reproduction Steps 1. Build a Docker image based on Python 3.12 / Alpine. 2. Upgrade the Python packages: bash pip install --upgrade setuptools==83.0.0 pip install --upgrade msgpack==1.2.1Target
Container Image
Scanner
Vulnerability
Target OS
No response
Debug Output
Version
Checklist
-f jsonthat shows data sources and confirmed that the security advisory in data sources was correctAll reactions