Manifest List

A manifest list is a container image index that points to multiple image manifests for different CPU architectures or operating systems. In practice, it lets a registry serve the right image variant to each runtime, while the list itself does not contain the image layers, only references and selection metadata.

How a Manifest List Works

A manifest list is the index layer of a multi-architecture container image. It gives registries and runtimes a selection map, so the correct image manifest can be chosen for the target platform without bundling the image layers into the list itself.

This design matters because the manifest list is not the workload payload, it is the routing metadata that tells a runtime which variant to pull. If that selection metadata is wrong, incomplete, or tampered with, the platform can fetch the wrong image variant and the application may fail to start or behave unexpectedly.

Why Manifest Lists Exist

Container ecosystems often need one logical image name to represent several builds, such as amd64 and arm64 variants or Linux and Windows variants. A manifest list lets the registry present those variants under a single reference while preserving per-platform manifests underneath.

That abstraction reduces naming complexity for operators and build pipelines, but it also creates an extra indirection layer. The consumer must resolve the list, then select the referenced manifest that matches its runtime, which makes manifest integrity and platform metadata part of the trust boundary.

Security Properties of the Index Layer

Because a manifest list points to other manifests rather than storing layers itself, its security value is mostly in integrity and correctness. The list should be treated as controlled metadata, since it can influence which code and dependencies are ultimately deployed on a node or cluster.

Integrity problems here are especially important in heterogeneous environments where the same repository serves multiple architectures. A malformed or manipulated list can create selection errors, cause image drift across nodes, or steer workloads toward an unintended variant that has not been validated for that platform.

Access control around publishing matters too, because whoever can update the list can change which manifest is selected for a given platform. That makes registry governance, provenance checks, and signing important companions to the index mechanism itself.

Operational Implications for Build and Deployment Pipelines

Manifest lists are usually produced by build tooling and consumed automatically by schedulers, registries, and runtimes. The practical implication is that image publishing is no longer just about pushing one artifact, it is about keeping the index and every referenced manifest aligned across platforms.

Teams should expect platform-specific validation in their release process, especially when a single tag is meant to serve mixed CPU architectures. A release may look healthy for one node class while failing on another if the list references the wrong manifest or a variant was never published.

In supply-chain terms, the manifest list is part of the selection path, so the metadata deserves the same discipline as the image artifact family it exposes. That is why provenance, digest pinning, and controlled publication workflows are more important here than simple tag management alone.

Risk and Threat Considerations

Manifest lists can create exposure when the index is stale, spoofed, or repointed to an unexpected manifest. The main risk is not that the list stores executable layers, but that it governs which image variant the runtime trusts and pulls, which can cause platform-specific outages or misdeployment at scale.

Failure mechanism: An attacker or careless publisher changes the manifest list or its referenced manifest set, causing runtimes to select the wrong architecture, an unreviewed build, or a maliciously substituted image variant.

Impact: The result can be broken deployments, inconsistent behaviour across nodes, loss of build provenance, or exposure to a compromised container image path that appears legitimate at the tag level.

Practitioner Guidance

Why practitioners should care: Treat the manifest list as a first-class deployment artifact, not as disposable metadata. In multi-architecture environments, it determines which manifest is actually delivered to each runtime, so it directly affects release correctness and trust.

What to watch for: Validate that every published platform variant is present, that the index resolves to the expected digests, and that registry updates are controlled by the same approval and provenance expectations as the image content they reference.

Practitioner takeaway: If the manifest list is wrong, the deployment can still look successful while delivering the wrong image variant, so verify the index as carefully as the image itself.

Related resources from NHI Mgmt Group

• What breaks when CI/CD pipelines can list tables with long-lived credentials?
• What breaks when Kubernetes manifest rendering trusts user input?
• Who should own unsubscribe and suppression list governance?
• How should organisations respond when a jurisdiction is added to the FATF grey list?