Notifications
Clear all
Topic starter
02/08/2026 9:43 am
TL;DR: Multi-architecture Docker builds extend portability, but they also increase the number of build paths, emulation dependencies, and registry artefacts security teams must govern, according to StackHawk. The real control problem is less about architecture support and more about ensuring CI/CD builds, images, and manifests stay verifiable across environments.
NHIMG editorial — based on content published by StackHawk: Building Multi-Architecture Docker Images in CICD
Questions worth separating out
Q: How should security teams govern multi-architecture Docker builds in CI/CD?
A: Treat the build pipeline as a controlled delivery system, not just an automation script.
Q: Why do multi-architecture builds increase governance complexity for CI/CD teams?
A: They add more moving parts, including emulation, manifest creation, registry publishing, and multiple architecture-specific artefacts.
Q: What breaks when manifest generation is not controlled in container pipelines?
A: Teams can publish the wrong image, lose traceability between architecture-specific builds, or send clients to artefacts that were not tested under the expected conditions.
Practitioner guidance
- Define a trusted build path for each architecture Pin the build toolchain, emulator image, and Docker build configuration so amd64 and arm64 artefacts follow a reproducible path from commit to registry.
- Scope registry credentials to the minimum release job Use short-lived CI/CD credentials for image push and manifest publication, and rotate them on a fixed lifecycle.
- Verify manifest-to-image integrity before promotion Check that the manifest points only to the intended architecture-specific images and that each image is traceable to the same commit, build runner, and signing policy.
What's in the full article
StackHawk's full post covers the implementation detail this post intentionally leaves for the source:
- Gradle task structure for automating amd64 and arm64 image builds.
- BuildKit and binfmt_misc setup details for Linux CI environments.
- Manifest generation flow for mapping architecture-specific images to a single reference.
- Platform-specific notes on supporting Apple silicon development workflows.
👉 Read StackHawk's guide to building multi-architecture Docker images in CI/CD →
Multi-architecture Docker builds in CICD: what security teams should watch?
Explore further
02/08/2026 12:36 pm
Multi-architecture build pipelines are now a supply chain governance problem, not just an engineering optimisation. The article shows that arm64 support depends on emulation, BuildKit, manifests, and registry orchestration, which means the delivery path itself has more trust dependencies than a single-architecture build. In practice, this is where NIST CSF and NIST SP 800-53 style control thinking becomes useful, because build integrity must be managed as an operational control surface, not a convenience feature.
A question worth separating out:
Q: What is the difference between native and emulated multi-architecture builds?
A: Native builds run on hardware that matches the target architecture, while emulated builds translate instructions through tools such as QEMU. Native builds usually provide cleaner fidelity, but emulation is useful for coverage. The governance difference is that emulated builds require extra trust in the translation layer.
👉 Read our full editorial: Multi-architecture Docker builds in cicd need stronger controls
