Treat each platform of a multi-architecture image as its own artifact with its own SBOM. A multi-platform image is a manifest list pointing at separate images, each with its own layers, and packages can differ between amd64 and arm64. One SBOM for the whole tag can hide those differences.
What a multi-platform image is
Docker's documentation describes it plainly. A single platform image has one manifest pointing at one configuration and one set of layers. A multi-platform image has a manifest list pointing at multiple manifests, each of which points at a different configuration and set of layers. When you pull it, the registry returns the manifest list and Docker selects the variant that matches the host, for example linux/arm64 on an ARM based board and linux/amd64 on an x86-64 laptop.
So the thing people call "the image" is really a pointer to several images. Anything you attach to the tag alone is attached to the pointer, not to the content.
Why the contents can differ
Two images built from the same Dockerfile for different architectures can still differ:
- A package may have a different version, or not exist at all, on one architecture.
- A native dependency may be compiled on one platform and downloaded prebuilt on another.
- A build step may include an architecture specific library or driver.
- Emulated builds and native builds can take different paths through the build.
If your SBOM is generated once for one platform and described as covering the tag, then customers on the other platform receive a bill of materials for something they do not run.
What to do
| Situation | Recommended approach |
|---|---|
| You support two or more architectures in production | One SBOM per platform manifest |
| You are sure the platforms are identical | Still generate per platform and diff; the diff proves it |
| A customer asks for the SBOM of a tag | Provide the list per platform with the digest of each |
| A scanner reports a finding | Record which platform it applies to |
Steps
- Build the multi-platform image and note the digest of the manifest list and of each platform manifest.
- Generate an SBOM for each platform manifest, not for the tag.
- Name each SBOM file after the platform and its manifest digest.
- Diff the package lists between platforms and record the differences in a short note.
- Attach or store the SBOMs so each one stays linked to its manifest digest.
A digest identifies content exactly, while a tag can move. Using digests means a reader can tell which SBOM belongs to which build, even after the tag has been repointed.
Package identifiers help
Package URLs allow qualifiers for details such as the architecture. If your tool fills those in, two builds of the same package for different CPUs stay distinguishable.
Where Safeguard fits
Safeguard scans container images and produces SBOM output for dependency review. Check a specific platform variant with the free scan at gold.safeguard.sh/scan, and compare the results between variants.
Quick check
Can I attach one SBOM to the manifest list?
You can, but it describes only whichever platform it was generated from. Per platform SBOMs are clearer.
Why use digests instead of tags?
Tags can move, digests cannot. A digest ties each SBOM to exact content.
Sources
Last reviewed: 19 October 2026.
