Support SBOM creation for container image indexes

[eliaslevy]

What would you like to be added:
Create an SBOM when given a container reference that points to a container image index that includes the dependencies of all the image manifests the index points to.

Why is this needed:
Multi-architecture and multi-platform container images are becoming more common.

Additional context:
Syft supports creating an SBOM from a container reference. When given a reference, Syft will pull the reference to download the container image. When the reference points to a container image index, Syft will download one of the underlaying images depending on that platform the tool is run on, and generate an SBOM from that image. That means that the dependencies of the alternate images are not cataloged and documented in the SBOM, creating a visibility gap.

Syft should optionally download each underlaying image and document the dependencies in all of them. Ideally Syft would model the image index and image manifests as packages in the SBOM with appropriate relationships, so that the dependency graph information is recorded.

[kzantow]

Syft can download different architectures when using the --platform flag, but is unable to combine multiple sources into a single SBOM today. Would you be able to just use this flag to create separate SBOMs for each image architecture?

We investigated combining multiple SBOMs into a single one, but there are some definite issues with this. Feel free to read this issue for some more information there.

[eliaslevy]

We could generate SBOMs for each underlying container image separately, then merge them into a single SBOM. But I believe this is a common enough use case that Syft should support it.

Multi-architecture and multi-platform images are exposed to the user via the image index digest. So when they request an SBOM for the artifact, they will use that identifier in the lookup, rather than a digest for one of the underlying image manifests.

[kzantow]

Hi @eliaslevy at present this request requires a couple different things:

1. we need to be able to scan multiple images for all architectures given an image tag
2. we need to be able to combine multiple SBOMs into a single SBOM

Today, we don't have either of these features on the roadmap. Combining multiple SBOMs, for example, is a nontrivial task that requires understanding about what packages and files mean within the context of the provided SBOM.

That said, we always accept PRs and we're always happy to talk about this on Slack or our community office hours!

[JonZeolla]

I would think (at least in my scenario) that making a per-platform SBOM from a multi-platform manifest would be a very valuable step forward

[stevehipwell]

There are documented semantics for SPDX and this use case. AFAIK apko, ko & bom all already follow this semantic pattern (reference).

[willmurphyscode]

Hi all! We discussed this on our livestream today and we have some ideas:

1. The best way to unblock this is to add a mutli-image source in stereoscope, essentially adding a dimension to the file coordinates, so that the file coordinate is a tuple of (image, layer, path) instead of just (layer, path). This might be a fair bit of work, but it might unblock allowing Syft to have multiple images in flight at the same time without a major rewrite. I'll open an issue in anchore/stereoscope to track testing whether this is possible.
2. This is going to be a relatively heavy lift, regardless of how we do it. In the meantime, your best workaround is probably to use crane or similar to get a list of images from the manifest, and invoke Syft on each of them.

[stevehipwell]

@willmurphyscode providing the specification for the output SBOM would be the first step. FYI I'm not sure if the standards I linked above are actually in use. After there is a standard Syft could add support to merge the SBOMs created using crane to get the layers and Grype could then scan the result.