Catalog discovered SBOMs
- Dominant language
- Go
- Stars
- 9.6k
- Forks
- 954
- Avg merge
- 23h 27m
- Merged PRs (30d)
- 48
Description
**What would you like to be added**:
If a container image (or directory) being scanned contains an SBOM it would be interesting to consider taking additional actions based on detecting that it's an SBOM. These actions might be:
- merge the discovered SBOM with the current SBOM being created
- additionally output the discovered SBOM and create a relationship between the two
- summarize the SBOM in a subsection of the SBOM being created
- another option?
This would give syft a more intelligent avenue for SBOM data discovered other than reporting it as "another file" discovered within the scanned source.
**Why is this needed**:
This could play into https://github.com/anchore/syft/issues/31 , but that is not clear yet.
**Additional context**:
If a "merge" of the discovered SBOM and the current SBOM is selected, it is important to be transparent about which packages were not directly detected by a package cataloger and which were (and specifically, which SBOM file each package came from). Additionally, if the merge path is detected this has certain implications about the ID-system for packages (there may be overlap in IDs used, which can get complicated fast).
Contributor guide
Research direction
Read issue #31 and inspect how Syft currently reports SBOM files discovered in a scanned container image or directory as another file. Decide which action is in scope—merge, separate output with a relationship, or a summary—and define how package provenance and overlapping IDs should be represented before implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100