A multi-stage build separates build time dependencies from the final runtime image. Teams use it to keep private tooling, intermediate files, and sensitive build artifacts out of the final image, reducing the chance that credentials or other unwanted data survive into production.
Expanded Definition
A multi-stage build is a container image construction pattern that uses one stage to compile, download, or assemble application components and a later stage to produce the runtime image. Its security value is that only selected artifacts are copied forward, which helps exclude build tools, transient files, and secrets that may be present during compilation. In practice, this matters because build environments often have broader network access, package manager credentials, or source control tokens that should never appear in production. The pattern is especially relevant in software supply chain hardening, where image minimisation and artifact separation reduce the blast radius of a compromised build step.
Definitions vary across vendors and platforms, but the core idea is consistent: a build stage is for transformation, while the final stage is for execution. That distinction aligns with guidance in the NIST Cybersecurity Framework 2.0, which emphasises securing software and infrastructure across the lifecycle rather than only at deployment. The most common misapplication is treating a multi-stage build as a secret-management control, which occurs when teams assume build-time credentials are safe simply because they are not visible in the final image.
Examples and Use Cases
Implementing multi-stage builds rigorously often introduces pipeline complexity, requiring organisations to weigh smaller, safer runtime images against more careful build orchestration and artifact handling.
- Compiling a Go or Rust application in a full toolchain stage, then copying only the compiled binary into a minimal runtime image.
- Building a web application with Node.js dependencies in one stage, then serving static assets from a lightweight runtime container with no package manager installed.
- Generating documentation, test reports, or client bundles in a build stage while ensuring private signing keys, cache files, and source maps do not carry into production.
- Creating a hardened image for an internal service where only the runtime library set is included, reducing the attack surface exposed to scanners and attackers.
- Using a separate stage to fetch dependencies from trusted repositories, then copying only vetted outputs into the final image after review.
For container supply chain hygiene, the approach is a practical companion to image scanning and provenance checks described in guidance such as NIST Cybersecurity Framework 2.0. It is most effective when teams explicitly control what gets copied between stages and review every added file as if it were production code.
Why It Matters for Security Teams
Security teams care about multi-stage builds because they reduce the chance that sensitive build-time content survives into the runtime environment. That includes credentials, signing material, private package sources, debug binaries, and intermediate artifacts that can expose implementation details or broaden an attacker’s foothold. The control is not a substitute for secret injection discipline, but it is a strong containment measure when paired with short-lived credentials, isolated build runners, and image signing. In identity and agentic AI workflows, the same principle applies to pipelines that assemble models, toolchains, or agent packages: only the minimum execution-ready output should reach production, never the scaffolding used to create it.
When this concept is misunderstood, teams often assume a clean final image means the whole pipeline is safe. That assumption breaks down if secrets were available during build, because a compromised CI system or leaked layer can still expose sensitive data even when the runtime image looks minimal. Organisations typically encounter the consequences only after a registry leak, supply chain review, or incident response exercise, at which point multi-stage build discipline becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Multi-stage builds help protect data in transit from build stage to runtime image. |
| NIST SP 800-53 Rev 5 | CM-2 | Configuration baselines support controlled, repeatable container image composition. |
| ISO/IEC 27001:2022 | A.8.9 | Configuration management helps keep build artifacts and runtime contents intentionally separated. |
| OWASP Non-Human Identity Top 10 | NHI workloads often package tokens and service credentials into build pipelines and images. | |
| NIST AI RMF | AI RMF applies where multi-stage builds package model or agent artifacts for release. |
Minimise sensitive data exposure by copying only required artifacts into production images.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
