Compare repeated builds of the same commit and look for changes in resolved digests, runner identity, build arguments, or artifact size that cannot be explained by source control. If the build output changes without a commit change, the pipeline is not fully controlled.
How to tell drift from normal build variability
Security teams should treat pipeline drift as a reproducibility problem first: the same source revision should produce the same security-relevant build facts unless an approved input changed. The most reliable signal is not a single failed run, but repeated builds of the same commit diverging in ways that matter for trust, especially when the change is in resolved dependencies, runner context, build flags, or the artifact itself.
That means the team is not asking “did the build succeed?” but “did the build behave deterministically under the same declared inputs?” If output changes appear without a source-control change, the pipeline is no longer behaving as a controlled system. SLSA is the clearest external model for framing that expectation around build provenance and artifact integrity.
Teams usually look for drift by comparing the build graph, resolved digests, environment-dependent behavior, and final artifact properties across repeated executions. If those values move when the commit does not, the issue is usually not “randomness”, it is hidden state, mutable infrastructure, or an unauthorized dependency on something outside source control. The question is whether that dependency is acceptable and explicitly managed, not whether the output happened to work.
What evidence makes pipeline drift visible
Drift becomes visible when you compare the same commit across enough runs to expose hidden variance. Practical indicators include different dependency hashes, different runner identities, different build arguments, different fetched transitive components, or artifact size and metadata that shift without any corresponding change in code.
A useful test is to separate source changes from execution changes. If the commit, lockfile, and declared build recipe are stable but the build still resolves to a different output, the pipeline is admitting uncontrolled inputs somewhere in the chain. That can include mutable base images, floating tags, non-pinned actions, ambient credentials, or self-hosted runner state that survives between jobs. CI/CD Pipeline Identity Security Guide and CI/CD pipeline exploitation case study both reinforce how hidden pipeline inputs and exposed execution paths can change outcomes without a code change.
The strongest evidence is comparative and repeatable. One odd build is a clue; multiple identical commits producing different digests, different signing material, or different runner context is a control failure. If the build cannot be reproduced or explained from declared inputs, the drift is real even before you prove malicious tampering.
Why drift matters for trust and release decisions
Pipeline drift breaks confidence in the build as a security control. Once the same revision can produce different outputs, you can no longer assume the artifact you tested is the artifact you shipped, which undermines provenance, rollback confidence, and incident investigation.
It also widens the attack surface for poisoning and persistence. An attacker does not need to alter source code if they can influence a runner, secret, dependency source, or build step that the pipeline silently trusts. ArtiPACKED 2024 shows how build and artifact handling can expose live tokens, while Shai Hulud npm malware campaign illustrates how supply-chain abuse can turn normal automation into a secret-exposure path.
For security teams, the important consequence is operational as well as adversarial: drift makes attestations weaker, triage slower, and root-cause analysis harder. If an artifact differs from the previous known-good build, you need to assume either uncontrolled variance or compromise until the pipeline explains the difference.
Risk and Threat Considerations
Pipeline drift is risky because it can hide either configuration decay or active abuse inside a process teams usually trust. Even when no attacker is present, unexplained variance means the build is depending on mutable state outside source control, which creates exposure around integrity, auditability, and release assurance.
Failure mechanism: Mutable dependencies, reused runners, unpinned build steps, or inherited environment state change the result of a build even though the commit did not change. An attacker can exploit the same weakness to poison output, intercept secrets, or preserve persistence through the pipeline.
Impact: Teams may promote or deploy an artifact that is not reproducible, not fully reviewed, and not the same object they previously validated. That weakens provenance, complicates incident response, and can let a compromise survive across builds.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build drift directly concerns artifact provenance and reproducibility. |
| Recommendation — Adopt SLSA controls to pin inputs and verify build provenance before release. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | Drift often comes from uncontrolled build settings and mutable pipeline state. |
| CM-2 — Baseline Configuration | Repeated builds should match a controlled baseline to detect unauthorized variation. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Runner and tool identities affect trust in automated build execution paths. | |
| Recommendation — Enforce approved configuration baselines for build runners and pipeline steps. Define and monitor a build baseline so unexplained output changes are flagged. Authenticate non-human build identities and constrain their trusted access paths. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Pipeline drift is a configuration-control problem when builds diverge unexpectedly. |
| Recommendation — Control pipeline configuration changes and review deviations from the approved build setup. | ||
Practitioner Guidance
What to verify: For any suspicious build, verify the commit SHA, dependency resolution, runner identity, image digest, and final artifact hash together. A mismatch in any one of those is enough to require deeper investigation, because reproducibility depends on the whole chain, not just source control.
What good looks like: Repeated builds of the same revision should converge on the same resolved digests and artifact fingerprints when the pipeline is under control. If they do not, treat the discrepancy as a pipeline governance issue, not merely a build nuisance.
Practitioner takeaway: The key judgment is whether the pipeline can explain every change in output from an approved input change; if it cannot, drift is already present even before you prove intent.
Related resources from NHI Mgmt Group
- How do security teams know whether pipeline access is actually under control?
- How do security and data science teams know whether embedding monitoring is actually detecting meaningful drift?
- How do security teams know whether their log collection pipeline is actually preserving the right data end to end?
- How do security teams know whether Terraform drift controls are actually working?