How should security teams govern multi-architecture Docker builds in CI/CD?

Treat the build pipeline as a controlled delivery system, not just an automation script. Pin build dependencies, scope registry credentials, record whether the build ran natively or through emulation, and verify that manifests map cleanly to the intended images before promotion.

Why This Matters for Security Teams

Multi-architecture Docker builds expand reach, but they also widen the trust boundary inside CI/CD. A single pipeline may now produce multiple image variants, pull cross-platform base layers, and rely on emulation or remote builders to finish the job. That creates security risk if teams assume one build identity, one provenance trail, or one validation path covers every output. Governance should focus on release integrity, not just build success.

For practitioners, the main issue is that build systems become identity-bearing production components. Registry tokens, signing keys, cache access, and build runners all need explicit control because compromise in any one area can affect every architecture artifact downstream. Guidance from the NIST Cybersecurity Framework 2.0 supports this kind of asset and supply chain discipline, even though it does not prescribe Docker-specific mechanics. In practice, teams that treat amd64 and arm64 outputs as equivalent often miss subtle drift in base image content, build flags, or dependency resolution until release validation fails or an incident forces reconstruction.

In practice, many security teams encounter multi-architecture drift only after a manifest list has already been promoted, rather than through intentional build-time verification.

How It Works in Practice

Governance works best when the pipeline can prove three things for every build: what was built, how it was built, and which artifact belongs to which architecture. That means pinning base images by digest, locking build tooling versions, and capturing build metadata that records the target platform, runner type, and whether emulation was used. The point is not to eliminate flexibility, but to make the build path auditable enough that a promoted manifest can be traced back to a specific, reproducible process.

Security teams should also separate duties across the pipeline. Build credentials for registries should be narrowly scoped, signing credentials should not live in the same trust zone as general CI variables, and promotion should require validation of both content and metadata. Where possible, compare the generated manifest against the expected architecture set before release. For teams aligning to supply chain controls, the CISA software bill of materials guidance is useful context because the same traceability mindset applies to image composition and dependency provenance.

• Use immutable references for base images and critical build inputs.
• Record the runner, platform target, and emulation status for each artifact.
• Require registry access tokens with minimal write scope and short lifetimes.
• Validate that the manifest list matches the intended architectures before promotion.
• Store build attestations and logs in a system that is protected from pipeline admin access.

Operationally, this is strongest when CI/CD, registry, and signing controls are all visible to the same governance process. The SLSA framework is helpful here because it reinforces provenance and build integrity expectations across the software supply chain. These controls tend to break down when shared runners allow uncontrolled caching across architectures because the resulting artifacts can inherit state that was never intended for the target platform.

Common Variations and Edge Cases

Tighter build governance often increases pipeline overhead, requiring organisations to balance release speed against traceability and assurance. That tradeoff becomes visible in heterogeneous environments where native builders, QEMU emulation, and remote build services coexist. Best practice is evolving here: there is no universal standard for how much build metadata must be retained, but current guidance suggests preserving enough evidence to reconstruct the artifact path without relying on ephemeral CI logs alone.

Edge cases matter. Emulated builds can hide architecture-specific defects, so a pipeline that passes on x86 may still produce a weak or broken arm64 image. Shared cache layers may also create false confidence if one architecture reuses layers built for another. In regulated environments, this becomes more than a quality issue because release accountability depends on being able to show that each artifact was validated in its actual execution context. Where container images support privileged workloads or secret injection, the governance bar should be higher, since image tampering can quickly become a credentials exposure problem.

For teams formalising controls, mapping the process to the OWASP supply chain security guidance can help translate policy into reviewable checks. The main exception is highly dynamic build farms with frequent ephemeral runners and external cache services, where evidence retention and artifact traceability often lag behind delivery velocity.

Related resources from NHI Mgmt Group

• How should security teams govern machine credentials across cloud and CI/CD environments?
• How should security teams govern credentials used by CI/CD pipelines?
• How should security teams govern CI/CD jobs that publish security policy?
• What do security teams get wrong about workload identity in cloud and CI/CD environments?