Why build once and promote the same artifact through environments?

Because what you tested must be what you ship. Build the artifact once, record its digest, sign it, and promote that same artifact from test to staging to production. If each environment rebuilds from source, each build can differ, and a tampered build is harder to notice.

The idea in plain words

An artifact is the thing you deploy: a container image, a package, a binary. Build once means one build produces one artifact with one cryptographic digest. Every later stage deploys that digest and nothing else. Configuration changes between environments, the artifact does not.

What goes wrong with rebuild per environment

• Different inputs. A rebuild a day later may pull a newer dependency or base image, so production runs something you never tested.
• Different build environment. A different runner, tool version or cache changes the output.
• Unverifiable chain. You cannot say that the production artifact is the one that passed your tests.
• More chances to tamper. Each build is another place an attacker with pipeline access can alter output.

OWASP lists this under improper artifact integrity validation. Its description: an attacker with a foothold in the delivery process can move malicious artifacts through the pipeline while they still look legitimate. It cites SolarWinds, where code was altered during the build so the change left no trace in the codebase. Its mitigations include signing each resource when generated and verifying the signature before later steps use it, and using projects such as in-toto, SLSA and Sigstore.

OWASP's flow control guidance also says artifacts should move through the pipeline only if a pre-approved CI service account created them, with secondary review for artifacts uploaded by other accounts.

How to do it

1. Build in one trusted job. Run it on an isolated, ephemeral runner.
2. Record the digest. Refer to the artifact by digest, not by a mutable tag like latest.
3. Sign and attach metadata. Keep the commit, build job and SBOM linked to the digest.
4. Promote by reference. Later stages deploy that digest and verify the signature first.
5. Scan once, keep scanning. New vulnerabilities appear after release, so keep checking the deployed digest.
6. Detect drift. Compare what runs in production with what the pipeline produced, as OWASP suggests.

When rebuilding is acceptable

If an environment truly needs a different build, for example a different target architecture, treat each as its own artifact with its own digest, tests and sign-off. Do not rebuild the same target in different environments.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a released artifact can gain new findings after it shipped, which is why one known digest is easier to monitor.

Quick check

Safeguard generates SBOMs, scans dependencies and monitors what you have shipped, and policies and gates can block a release on findings. Try the free scan.

Sources

• OWASP CICD-SEC-9: Improper Artifact Integrity Validation
• OWASP CICD-SEC-1: Insufficient Flow Control Mechanisms

Last reviewed: 19 October 2026.