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 StackHawk guide on building Docker images for multiple architectures in CI/CD, with the key finding that portability increases pipeline and registry complexity.
Why it matters: For practitioners, the main issue is governance of build paths, emulation dependencies, and manifest integrity so that cross-architecture releases remain verifiable and controlled.
Context
Multi-architecture Docker builds let the same software ship as different images for different CPU architectures, but that flexibility creates more places where build logic, tooling assumptions, and release artefacts can drift. In CI/CD, the control problem is not simply whether the build succeeds, but whether the pipeline produces the intended image for the intended architecture every time.
This topic has a real identity-security angle because CI/CD pipelines depend on service credentials, registry access, and build-system permissions to create and publish the artefacts that later run in production. When architecture-specific build paths multiply, governance has to cover both the pipeline itself and the non-human identities that move images from build to registry to deployment.
Key questions
Q: What breaks when multi-architecture Docker builds are not governed carefully?
A: The release process can produce valid-looking artefacts that do not match the intended architecture, build inputs, or manifest mapping. That creates a trust gap between what CI/CD says it published and what workloads actually pull. The failure is not only technical compatibility but release integrity, because the wrong image can be promoted as if it were the correct one.
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: How can security teams tell whether cross-architecture release controls are working?
A: Look for consistent build outputs, repeatable manifest generation, and the ability to trace every published image back to the exact build path that produced it. If a team cannot explain which runner, emulator, and registry action created each artefact, the control set is not giving reliable assurance. Provenance should be demonstrable, not inferred from a successful pipeline run.
Q: What should organisations do when Docker builds span both local and CI runners?
A: They should treat local and CI environments as separate trust zones and require the same architecture-targeting rules in both. That means aligning build flags, access permissions, and release validation so a developer workstation cannot produce artefacts that bypass CI controls. The goal is consistent governance across every place a release can be built or promoted.
Technical breakdown
How multi-architecture Docker builds change the trust boundary
A multi-architecture build is not one artefact path but several, because the same source can produce different binaries, images, and manifests depending on target architecture. That means CI/CD must govern build inputs, emulation layers, and output tagging with far more precision than a single-architecture pipeline. BuildKit and buildx can orchestrate this process, but they do not remove the need to validate that each architecture-specific image is built from the right inputs and associated with the right manifest. The security concern is provenance consistency across build variants, not just successful compilation.
Practical implication: Treat each architecture output as a separately governed release artefact, not as a routine variation of one build.
Why emulation and platform tooling widen operational risk
Cross-building on Linux often depends on QEMU and binfmt_misc to emulate foreign architectures when native support is absent. That introduces another dependency layer in the build chain, and each dependency becomes part of the effective trust boundary. Docker Desktop may hide some of this complexity, but CI environments usually expose it directly, especially when DOCKER_BUILDKIT and platform flags must be set explicitly. If those build conditions are inconsistent, teams can end up with images that are technically valid but operationally different from what the release process expected.
Practical implication: Lock down the build environment so emulation, build flags, and architecture targeting are standardised across runners.
Registry manifests are now governance objects, not just packaging metadata
In multi-architecture delivery, the manifest is the routing layer that tells clients which image to pull for a given architecture. That makes manifests a governance control point because they determine whether users and workloads receive the correct artefact. Registries may hold several images and a single manifest list, so the integrity of the mapping matters as much as the image itself. If tagging, pushing, or manifest generation is inconsistent, the result is a release that appears complete while quietly serving the wrong payload to the wrong platform.
Practical implication: Verify manifest generation and image-to-architecture mapping as part of release approval, not after deployment.
Threat narrative
Attacker objective: The objective is to tamper with build outputs or release routing so that a manipulated image or manifest is published as trusted software.
- Entry occurs through the CI/CD build system and its supporting tooling, where architecture-specific build paths, emulation, and registry access must all be trusted.
- Credential or configuration abuse at that layer can affect which images are built, tagged, pushed, or referenced by the manifest list.
- The downstream impact is release integrity failure, where the wrong image or an unverified build path can reach production across one or more architectures.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Multi-architecture build governance is now a release-integrity problem, not a packaging problem. Once a pipeline has to produce amd64 and arm64 artefacts, the organisation is no longer managing one build path but several trust decisions across the same delivery chain. That increases the need for provenance controls, runner consistency, and manifest validation. Practitioners should treat architecture expansion as a governance change, not a routine compatibility tweak.
CI/CD identity becomes more important when build logic depends on registry and emulator access. The article shows that automation details such as buildx, BuildKit, and container registries are not neutral plumbing. They are permissioned systems that rely on service accounts and build credentials to produce deployable artefacts. In identity terms, this is a reminder that non-human identities used in pipelines need the same lifecycle, scoping, and review discipline as any other privileged access path.
Manifest integrity is the named control gap teams often miss. The most specific risk in multi-architecture delivery is not just whether images exist, but whether the manifest correctly binds each image to the intended platform. If that binding drifts, the release process can remain green while the wrong artefact is served. Practitioners should make manifest validation a formal release control, not an assumed by-product of successful image pushes.
Cross-architecture support is becoming a normal expectation, which means governance maturity has to rise with it. As more software teams target arm64 alongside amd64, the baseline question changes from can we build it to can we prove what we built and where it will run. That shift pushes release engineering, identity governance, and cloud registry controls into the same conversation. Teams that do not align those controls will accumulate release risk faster than architecture coverage.
Build portability creates control sprawl unless organisations define ownership clearly. The same pipeline can span local developer machines, CI runners, emulation layers, and registry endpoints. Each handoff widens the operational surface unless the organisation assigns explicit ownership for artefact provenance, identity permissions, and release verification. The practical conclusion is simple: multi-architecture delivery should be governed as a supply chain, not as a developer convenience.
What this signals
Architecture expansion changes the control boundary. Once a build process has to support multiple target platforms, release governance must cover provenance, environment consistency, and artefact routing together. If those controls live in different teams, the organisation will have gaps between engineering convenience and release assurance.
NHI governance now extends into build automation. The service accounts and tokens that operate CI/CD and registry workflows are non-human identities with direct production impact. Their access scope should be reviewed as release-critical privilege, not as background tooling permission.
Manifest validation is the hidden checkpoint. Teams often focus on whether a build completes, but the more important question is whether the published manifest sends each client to the correct image. That control deserves explicit testing because it is where cross-architecture correctness becomes enforceable.
For practitioners
- Define architecture-specific release gates Require separate validation for amd64 and arm64 outputs before any multi-architecture manifest is published. The gate should confirm source, build environment, and image tag consistency.
- Standardise CI build environments Use the same BuildKit, platform flags, and emulator assumptions across all runners so local success does not mask CI drift.
- Review non-human identities used in build and registry flows Inventory the service accounts and tokens that can build, tag, or push images, then reduce their scope to the minimum needed for release automation.
- Validate manifest-to-image mapping before release Check that every published manifest points to the intended architecture-specific image and that no stale or mismatched tag can be pulled by clients.
Key takeaways
- Multi-architecture Docker delivery expands the number of artefacts, build paths, and trust decisions that CI/CD must govern.
- The main risk is not architecture support itself, but weak provenance and inconsistent manifest handling across runners and registries.
- Practitioners should validate build identity, release permissions, and image-to-architecture mapping before treating cross-platform builds as production ready.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | CI/CD build and registry access depends on tightly scoped service accounts and tokens. |
| Recommendation — Review build and registry service accounts under CIS-5 and remove unnecessary permissions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article's build and publish flow depends on managed credentials and tokens. |
| Recommendation — Apply IA-5 to rotate and control authenticators used by build and registry automation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Multi-architecture CI/CD needs explicit governance over who and what can publish artefacts. |
| Recommendation — Use PR.AA-05 to enforce least-privilege access for build, tag, and publish operations. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Pipeline compromise and token abuse are central threat paths in CI/CD build environments. |
| Recommendation — Map pipeline abuse to TA0006 and TA0008 when hunting for credential misuse and build-path pivoting. | ||
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.
- Allow List: A policy control that permits SMS or voice verification only to preapproved locations. It is useful when users operate in a predictable set of countries or regions and the organisation wants to reduce exposure to fraud, unwanted delivery, or out-of-policy message routing.
- Cross-Platform Emulation: The use of tooling such as QEMU to build or run software for a target architecture that differs from the host system. It enables portability, but it also introduces another dependency that must be controlled, monitored, and standardised in build pipelines.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for security leaders who need practical guidance on governing privileged automation and machine identities.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org