Describe multiple SBOM scan targets
- Dominant language
- Go
- Stars
- 9.6k
- Forks
- 954
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 42
Description
**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:
```yaml
# syft.yaml
inputs:
- type: image
id: my-image-sbom
value: docker.io/me/my-image:latest
format: spdxjson
- type: directory
id: my-source-sbom
value: ./src
format: spdx
```
This would allow for scanning an artifact and source and produce two different sboms, such that in CI invocation would simply be:
```
# syft.yaml is automatically assumed...
syft
# ...output "my-image-sbom.json" and "my-source-sbom.spdx" files
```
You could combine the output from multiple cataloging efforts into the same SBOM by using the same `id` for each input:
```yaml
# syft.yaml
inputs:
- type: image
id: my-sbom
root-package: container
value: docker.io/me/my-image:latest
format: spdxjson
- type: directory
root-package: source
id: my-sbom
value: ./src
```
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:
```
syft dir:./ image:docker.io/me/my-image:latest -o spdxjson
```
**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.
Contributor guide
Research direction
Start with the proposed syft.yaml inputs examples and the CLI form for multiple scan targets. Define how targets, IDs, formats, output files, and grouped relationships should behave, including how incompatible formats are handled; done means the selected inputs can produce separate or combined SBOMs as described.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, go
- Domain
- cli, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100