(SBOM generate + SBOM scan) metadata differs from image scan metadata #7169
Replies: 5 comments 4 replies
-
I've spent a bit of time looking at this, I think I have an understanding of where the problem might be. Essentially I suspect that in the process of parsing and loading the SBOM, transitive dependencies are not being identified and attached to their parent component correctly (c.f. dependency resolution defined here). The result is that some of these transitive dependencies are not picked up and end getting added later as orphaned packages. I think the implementation could be fixed using Kahn’s algorithm, either when resolving dependencies in addLangPkgs or when resolving dependencies initially. However, I'm not familiar enough with the intentions behind this code to know whether this approach is sensible or not. Happy to have a crack at fixing this if project owners agree this is the right way forward. |
Beta Was this translation helpful? Give feedback.
-
Also, surely this discussion should be promoted to an issue? Seems like a genuine bug to me. |
Beta Was this translation helpful? Give feedback.
-
Hello @mspraggs We are working in #8104 |
Beta Was this translation helpful? Give feedback.
-
@DmitriyLewen not sure if the PR you link is complete or not, so forgive me if I'm jumping ahead, but it looks like it doesn't fix the problem stated here. The steps above gives me:
and
|
Beta Was this translation helpful? Give feedback.
-
Created #8143 for this Task |
Beta Was this translation helpful? Give feedback.
-
Description
I have noticed that some images provide different target names in their scanner output, when the image is scanned compared to when Trivy is used to generate an SBOM and then that SBOM is scanned.
The vulnerability counts provided in these cases are the same, which is why I think this differs from #3649.
I haven't been able to identify exactly what the scope of the issue is, but it is at least the case for
gobinary
target types. This is not reproducible for every image that contains vulnerable Go binaries.Also I didn't run
trivy clean --all
as suggested when filing this issue because it doesn't appear to be a supported subcommand anymore.Desired Behavior
The path to Go binaries should be consistent for any given image, whether an image scan is performed or whether an SBOM is generated (by Trivy) for the image, and then that SBOM is scanned.
Actual Behavior
The image scan provides a full path to the vulnerable Go binary. Generating an SBOM (with Trivy) and then scanning that SBOM provides an empty path to the vulnerable Go binary, with the vulnerability information, and the full path to the vulnerable Go binary, with no associated vulnerability information.
Reproduction Steps
Target
Container Image
Scanner
Vulnerability
Output Format
JSON
Mode
Standalone
Debug Output
Operating System
Ubuntu 22.04.4 LTS
Version
Checklist
trivy clean --all
Beta Was this translation helpful? Give feedback.
All reactions