The emergence of AWS’ Graviton and “Apple Silicon” (aka M1 and now M2) a few years ago created a shockwave disrupting the architectural monoculture that had been the norm for both Cloud and developer workstations for (at least) the last decade. In these last few years we have also seen Google Cloud and Microsoft Azure launch their own Arm-based offerings to compete. The impact of this on the container space has been a dramatic increase in the need for multi-architecture container images (aka OCI image index, Docker manifest lists, or previously “fat manifests”).
Will the container image I am using deploy to an Arm-based production cluster?
Will my developers be able to test and debug things locally on Arm-based laptops?
At Chainguard, we are very bullish on these trends, and are building support for handling multiple architectures into our entire product line. A key piece of this is everyone’s favorite topic: SBOMs!
For single-architecture images, SBOMs are associated with that image’s digest:
However, for multi-architecture images (hereafter the “index”), there were several open questions:
.jpg)
We decided that since it is still possible to reference one of the variant images directly, that it was important for each image to carry its contribution to the multi-architecture SBOM as its own single-architecture SBOM that can stand on its own (e.g. if the variant does end up referenced directly):
.jpg)
To take a look at a practical example of this, you can browse the SBOM for the linux/arm64 variant of one of the Chainguard images using Sigstore cosign:
We also decided that duplicating the information from each variant at the index-level wasn’t necessary, and opened the door to inconsistencies we would rather avoid. If we could represent the “materials” directly relevant to our index (the images), and recursively discover / access their SBOMs, then we have a single source of truth for each shard of the metadata (and we can losslessly verify the signatures on each constituent piece of information).
.jpg)
To take a look at a practical example of this, we can browse the SBOM of one of the Chainguard images using Sigstore cosign:
This will download the SBOM of the index, and you will see packages for the index:
… as well as each architecture variant (here linux/amd64):
One note here is that mediaType is a non-standard option, which we are currently attempting to standardize as media_type upstream.
You will also see relationships between the index and each variant image’s packages designating them as “variants of” the index:
As we said earlier, we are building support for handling multiple architectures into our entire product line, and proposing it as the standard for how this information is represented in SPDX. Support for the above is already in Chainguard’s apko tool (as well as the CNCF’s ko project, and bom, the Kubernetes SBOM generator) by default, and all of the Chainguard Images surface this metadata today. If you deploy an index with this metadata to a cluster enrolled in Chainguard Enforce we will surface its variants under the Architecture tab of the image details page:
.png)
When Chainguard Enforce, our supply chain risk management platform, encounters an index, it will recursively ingest the variant images. For example, here is the arm64 variant of the above image, where you can see its packages:
.png)
We will also evaluate policies against these variants:
.png)
As the world becomes more architecturally diverse, we at Chainguard want to make sure our users are armed with the tools they need to remain secure.
Reach out and get started with a 30-day free trial of Chainguard Enforce today.
