Use package ID from decoded SBOMs when provided#1872
Merged
wagoodman merged 5 commits intoanchore:mainfrom May 8, 2025
Merged
Conversation
Signed-off-by: James Neate <jamesmneate@gmail.com>
Contributor
Author
|
The alternate is that the entire BOM-Ref field becomes the ID instead of the package-id suffix? Happy to make said change if needed. |
kzantow
reviewed
Jun 12, 2023
hectorj2f
reviewed
Jun 13, 2023
hectorj2f
reviewed
Jun 13, 2023
This comment was marked as outdated.
This comment was marked as outdated.
4 tasks
This comment was marked as outdated.
This comment was marked as outdated.
…-provided Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>
Contributor
|
I've changed my mind on this -- if we can make this behavior change without introducing new fields then we should prefer that minimal approach. I'll get this across the finish line today. |
Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>
Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>
wagoodman
changed the title
wagoodman
approved these changes
May 8, 2025
kzantow
approved these changes
May 8, 2025
Contributor
kzantow
left a comment
kzantow
left a comment
There was a problem hiding this comment.
Nothing blocking, but I something doesn't sit well for me seeing hashes no longer redacted in the snapshots it seems like something slightly different could be done for testing here
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Today if you use
syft convert, the syft API (say via grype) with an SBOM, or use the SBOM cataloger, all packages raised up from the underlying SBOM get new IDs derived from the data discovered as opposed to using the ID found within the artifact. There are pros and cons with each approach, however, this PR is changing syft's opinion on this to prefer the ID of artifacts from the SBOM discovered.This is done by using the existing
pkg.Package.OverrideID()at decode-time when constructing the package. If the ID is blank then we fallback to the standard derived Syft artifact ID.Note that this approach only affects package ID and not file IDs from decoded SBOMs --that will require further work since there could be drawbacks to adding an
idfield tofile.Coordinates(which are heavily used as map keys).Here's an example of before and after of a grype run with these changes integrated; now the artifact IDs in the grype JSON are the native SBOM ID:
Addresses anchore/grype#1265
Design alternatives
There was another approach considered where we persist the upstream cyclonedx and spdx library types onto the package and the SBOM object. This would go a long way towards lossless conversion, however, this was a little too much to bite off for now and the current approach selected (using ID overrides) does not conflict with that future goal.
Type of change
Checklist