You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What would you like to be added:
Be able to specify multiple targets that where one or more SBOMs are created. Take the following examples for illustrative purposes:
Where the result would be a single my-sbom.json in the spdxjson output. Additionally, anything found in the container will have a relationship tied to a phantom "container" package and anything in the source scanning would have a relationship to a phantom "source" package.
I'm not 100% in love with the proposed format above as it would be easy to abuse when it comes to combining incompatible formats, but it suits for illustrative purposes.
We could surface a small set of this functionality via the CLI by allowing for multiple scan targets:
Why is this needed:
For more complicated workflows it would be ideal to encode what needs to be cataloged into a description instead of relying on the consumer to orchestrate multiple syft calls with bash.
Additionally there is no way to deal with "multiple" SBOMs with syft, or grouping related items with relationships, which could be a powerful pattern.
The text was updated successfully, but these errors were encountered:
wagoodman
added
multiple-sources
Issues that are dependent on supporting multiple sources
and removed
I/O
Describes bug or enhancement around application input or output
labels
Aug 12, 2024
What would you like to be added:
Be able to specify multiple targets that where one or more SBOMs are created. Take the following examples for illustrative purposes:
This would allow for scanning an artifact and source and produce two different sboms, such that in CI invocation would simply be:
You could combine the output from multiple cataloging efforts into the same SBOM by using the same
id
for each input:Where the result would be a single
my-sbom.json
in the spdxjson output. Additionally, anything found in the container will have a relationship tied to a phantom "container" package and anything in the source scanning would have a relationship to a phantom "source" package.I'm not 100% in love with the proposed format above as it would be easy to abuse when it comes to combining incompatible formats, but it suits for illustrative purposes.
We could surface a small set of this functionality via the CLI by allowing for multiple scan targets:
Why is this needed:
For more complicated workflows it would be ideal to encode what needs to be cataloged into a description instead of relying on the consumer to orchestrate multiple syft calls with bash.
Additionally there is no way to deal with "multiple" SBOMs with syft, or grouping related items with relationships, which could be a powerful pattern.
The text was updated successfully, but these errors were encountered: