anchore
fix: indicate upstream packages for sbom cataloger
Description
To include the GENERATED_FROM relationships is a good way to resolve the issue, (~~but there might be better solutions to it~~,or maybe it's up to Grype not to make the upstream package false positive)
~~Proposal: we can preserve the name&version pair of the upstream packages in the comment field of the relationship like evidence/ownership-by-file-overlap or and strip the upstream packages out.~~
This proposal will introduce huge amounts of updates ,so the first option is preferred. Keep the packages as they were.
- Fixes #3983
Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
Checklist:
- [x] I have added unit tests that cover changed behavior
- [x] I have tested my code in common scenarios and confirmed there are no regressions
- [x] I have added comments to my code, particularly in hard-to-understand sections
Hey @VictorHuu -- thanks for working on this! We had a brief discussion on the team about whether or not we wanted to include things in our own data model that seem to be predominantly SPDX-only (although perhaps CycloneDX formulation is similar?), and we had pros and cons for both as it relates to this particular situation.
One con is that today, every package is supposed to be something Syft believes to be installed in the scanned target. By adding packages such as this, it breaks that assumption and makes downstream consumers more difficult, as they need to process relationships to determine if a package has some sort of exclusionary relation such as this. As you've astutely pointed out: "it's up to Grype not to make the upstream package false positive"
One pro is that we are able to more accurately convert from SPDX to SPDX, but there are other ways to accomplish this and there are a number of other parts of SPDX that we probably will never include native support for in the Syft model, so this seems to be less important than the former point.
Would you be able to help me understand why you've opted for this change rather than filtering out these packages when reading SPDX or in the SBOM cataloger (which admittedly would need the relationship)? Are there any other changes that might work for your purposes?
Hi @VictorHuu -- we discussed this as a team and have path forward for this change. I made another PR which temporarily ignores the packages during import that we'll have to revert as part of this change, as well as make a separate location in the Syft SBOM for packages that describe things which are not considered to be present in the scanned system. More details are in the issue: https://github.com/anchore/syft/issues/3983