SBOM generated are missing packages #6457
Replies: 3 comments 5 replies
-
I can confirm this issue and this goes beyond SBOM generation, python version was not identified at all, not even when going directly to vuln scan instead of first SBOM. |
Beta Was this translation helpful? Give feedback.
-
Most likely the root cause of this issue is part of the docs https://aquasecurity.github.io/trivy/v0.50/docs/scanner/vulnerability/: We are thinking of abandoning trivy because of this. Seems that trivy is useless for scanning distroless images, since it won't even detect the main binary which runs on the distroless image... |
Beta Was this translation helpful? Give feedback.
-
Hello @kovacs-levent Unfortunately Trivy supports only Go binaries and Rust Binaries built with cargo-auditable - https://aquasecurity.github.io/trivy/v0.50/docs/coverage/language/
That is why Trivy can't detect this package. Regards, Dmitriy |
Beta Was this translation helpful? Give feedback.
-
Description
We are using trivy to generate SBOMs for our images. Unrelated to the issue itself, but for added context, I found this while working on implementing end of life scans using the SBOMs generated by trivy.
When testing the end of life scans, I found that obvious outdated packages are not part of the SBOM. For demonstration purposes, I'll use xeol. When scanning an outdated docker image of
python:3.7.17-slim-bullseye
, directly scanning the image using xeol detects the following package as part of the image and being EOL:This is expected result, but when I first generate the SBOM using trivy, then scanning with the tool I get a different result:
You can see that there are no EOL software packages detected during this scan... You may notice the warnings, which I suspected that the xeol scanner could be the culprit, so I manually checked the SBOM, and no matter how I tried, but there is no version information detected for any python packages, which is obviously causing the xeol tool to miss the python 3.7.17 EOL finding. There are references to python, but version information is missing. An excerpt from
result3.json
for example:I searched/looked in the SBOM lots of ways, but there's no version information regarding python 3.7.17, leading me to believe that trivy fails to generate the SBOMs properly, and is missing out on some packages...
Another reasoning I can give is that when generating SBOMs for the same image using syft, I get a much larger SBOM file compared to trivy. Scanning the same image as before:
When checking the size, it's evident that the SBOM generated by
syft
is 15 times larger in the same format (let's disregard the fact thatsyft
also omits indentation in the resulting json, so it "compresses" the SBOM more thantrivy
does). Leading me to believe thatsyft
catches much more packages astrivy
when generating the SBOM.When manually checking the SBOM of syft, I see that there's a python package with the correct version, this is completely missing from
result-trivy.json
SBOM (following is an excerpt fromresult-syft.json
):Desired Behavior
That
trivy
generates the SBOM with sufficient package information to run EOL scans and keeping track of software components (without missing obvious packages, likepython
). Also that the SBOM sizes will be similar withsyft
, since it's the same SPDX-json format with both tools.Actual Behavior
trivy
missed the python version, resulting in an obviously missing package in the SBOM.syft
manage to generate an SBOM file 15x the size compared totrivy
SBOM.Reproduction Steps
1. trivy image --format spdx-json --output result-trivy.json python:3.7.17-slim-bullseye 2. Try searching for python 3.7.17 version 3. python 3.7.17 version package is not part of the generated SBOM
Target
Container Image
Scanner
None
Output Format
SPDX
Mode
Standalone
Debug Output
Operating System
Ubuntu 22.04.4 LTS
Version
Checklist
trivy image --reset
Beta Was this translation helpful? Give feedback.
All reactions