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.
At a glance
What this is: This is a tooling guide on building Docker images for amd64 and arm64 in CI/CD, with the key finding that multi-architecture support depends on buildx, BuildKit, emulation, and manifest handling.
Why it matters: It matters because CI/CD complexity often becomes a governance problem, especially when build infrastructure, container provenance, and secret handling sit inside the same delivery pipeline.
👉 Read StackHawk's guide to building multi-architecture Docker images in CI/CD
Context
Multi-architecture Docker builds solve a real portability problem, but they also widen the operational surface area of CI/CD. When teams add emulation, manifest generation, and registry pushes to a pipeline, they create more places where build integrity, image provenance, and secret handling can fail. That is especially relevant for teams that already struggle with secret exposure in code and build systems.
The identity angle here is indirect but real. CI/CD systems routinely depend on service accounts, tokens, and registry credentials, so build automation is also a Non-Human Identity governance problem. NHIMG's view is that architecture support should never be treated as a purely engineering convenience when the build path itself becomes part of the trust boundary.
Key questions
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. 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.
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. Each extra step widens the opportunity for provenance drift, misconfiguration, or credential misuse, so governance has to cover the full delivery chain rather than only the code.
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. That creates release confidence without release assurance, which is a common failure mode in distributed build systems.
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.
Technical breakdown
How multi-architecture Docker builds work in CI/CD
Multi-architecture Docker builds produce images for more than one CPU instruction set, typically amd64 and arm64, and then publish a manifest that points clients to the right image. In CI/CD, that usually means buildx, BuildKit, and platform flags coordinating the build. Where native execution is unavailable, emulation such as QEMU can bridge the gap, but it adds runtime dependency and performance overhead. The architecture choice affects not just compatibility but also how reproducible and inspectable the final artefact is.
Practical implication: standardise build steps so image creation, tagging, and manifest publication are deterministic across runners.
Why BuildKit and emulation change the trust model
BuildKit changes how Docker resolves build context, caching, and output generation, while binfmt_misc and QEMU let a host emulate another architecture during compilation. That is useful, but it also means the build result now depends on extra tooling layers outside the application code itself. In practice, pipeline operators need to understand whether the build used native execution or emulation, because discrepancies can affect test fidelity, timing, and reproducibility.
Practical implication: record whether builds ran natively or through emulation and treat that as part of release evidence.
Registry images and manifests as control points
A registry stores images, while a manifest maps multiple architecture-specific images to a single logical reference. That makes the manifest a governance object, not just a packaging detail, because it determines what clients retrieve in production. If the manifest is wrong, unsigned, or detached from the image lineage, teams can ship the wrong artefact while believing the pipeline is functioning correctly. This is why provenance and release integrity need to extend beyond the container image itself.
Practical implication: verify manifest generation and image lineage before promoting multi-architecture releases.
NHI Mgmt Group analysis
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.
CI/CD service accounts are the hidden Non-Human Identities behind most build architecture decisions. Registry pushes, manifest publication, and build orchestration all depend on credentials that often outlive the pipeline job that used them. NHIs outnumber human identities by 25x to 50x in modern enterprises, and that gap matters here because build automation expands the number of machine actors that can publish artefacts. Practitioners should treat build credentials as privileged workload identities, not as disposable scripting details.
Architecture support increases the number of places where provenance can drift. When teams rely on emulation for one target, native execution for another, and automated manifests to unify the result, they create multiple paths to the same release outcome. That can be perfectly valid, but only if the organisation can explain which path produced which artefact. The governance failure is not multi-architecture support itself, but the assumption that different build paths are equivalent without verification.
Secrets exposure risk rises whenever build systems are made more complex without corresponding secret lifecycle discipline. The NHI security issue is not only image output, but the credentials used to sign, push, and promote that output. NHIMG's position is that secret rotation, scoped registry access, and pipeline offboarding need to be explicit in CI/CD design, because the build process is a live access pathway, not a static script. That is the point where secrets governance and software delivery meet.
Multi-architecture support should be measured by release assurance, not by whether the images exist. A team can produce amd64 and arm64 images and still fail the real control objective if it cannot prove which runner, dependency chain, and manifest mapping created them. The right question is whether release artefacts remain attributable across build paths. Practitioners should therefore align multi-platform delivery with provenance, access review, and change control disciplines from the start.
What this signals
Build architecture is becoming a governance signal. When a CI/CD system can produce artefacts for multiple architectures, the question is no longer only whether the pipeline works. The question is whether the organisation can explain and verify every route through the pipeline, especially where service accounts, registry tokens, and signing credentials are involved. That is where NHI discipline and release governance converge.
Secrets sprawl is the quiet risk behind flexible build systems. If your pipeline still relies on long-lived credentials, the additional complexity of multi-platform builds multiplies the blast radius of a leak. Our research shows that 4.6% of public GitHub repositories contain at least one hardcoded secret, which is a reminder that build pipelines often fail at the same weak point: unmanaged credentials.
Release assurance needs to extend into the manifest layer. A multi-architecture pipeline can look healthy while quietly losing traceability between image, architecture, and deployment target. Teams that want durable control should connect container governance to the Ultimate Guide to NHIs and to NIST SP 800-53 Rev 5 Security and Privacy Controls, because the problem is both access control and provenance control.
For practitioners
- 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. Separate the native and emulated routes in documentation so reviewers can see which path produced each release.
- 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. Treat registry access as a privileged Non-Human Identity with explicit ownership, offboarding, and revocation steps.
- 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. Do not promote a multi-architecture release until the manifest has been validated.
- Separate build observability from application telemetry Log architecture selection, emulation usage, BuildKit settings, and registry targets as release metadata. That record should let security and platform teams reconstruct the build chain without relying on memory or ad hoc pipeline logs.
Key takeaways
- Multi-architecture Docker support is a delivery governance issue as much as a build engineering issue.
- CI/CD credentials, manifests, and emulation layers expand the trust boundary that teams have to secure.
- Practitioners should treat release provenance, secret lifecycle, and registry access as one control plane.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | CI/CD build and registry access depend on controlled permissions. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is central to container build and registry operations. |
| CIS Controls v8 | CIS-5 , Account Management | Pipeline credentials and registry identities need lifecycle governance. |
| MITRE ATT&CK | TA0003 , Persistence; TA0006 , Credential Access; TA0011 , Command and Control | Supply-chain and pipeline abuse often relies on credential abuse and sustained access. |
Model pipeline abuse against these tactics and monitor build tooling for credential theft and persistence.
Key terms
- Multi-Architecture Container Build: A multi-architecture container build creates images that can run on different CPU families, such as amd64 and arm64, from one delivery process. It usually relies on architecture-specific builds plus a manifest that routes clients to the correct artefact at pull time.
- BuildKit: BuildKit is Docker's newer build engine for creating images with better caching, parallelism, and output control. In CI/CD, it also becomes part of the trust chain because build behaviour, provenance, and reproducibility can vary depending on how it is configured and invoked.
- Container Manifest: A container manifest is metadata that ties multiple image variants to one logical image reference. It is a governance object as much as a technical one, because it determines which image a client retrieves and therefore which artefact actually reaches production.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
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.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect machine access control to the broader identity programme they already run.
Published by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
