Because they make builds non-deterministic. The same source tree can resolve different base images, libraries, or runtime flags at different times, which means two builds that look equivalent in version control may produce different code paths or expose different attack surface.
Why mutable tags and timing make builds non-deterministic
Mutable tags turn a build input into a moving target. A reference such as latest can point to one artifact today and a different artifact later, so the same source commit no longer maps to the same base image, dependency tree, or runtime behaviour. Timing adds another variable because package resolution, registry state, and transitive dependency selection can change between runs.
That is why supply chain risk rises even when the repository itself is unchanged. The build output is no longer fully determined by the reviewed source tree, so the security properties you think you are shipping may not be the ones actually deployed. Reproducibility is the practical control boundary here, because it lets you prove what was built and later rebuild the same result.
In other words, mutable references make provenance weaker. If you cannot reliably answer which artifact was consumed, you also cannot reliably answer whether a malicious update, a dependency substitution, or an upstream configuration change altered the result. That gap is what attackers exploit when they target build-time trust relationships.
Where the risk shows up in real build and release pipelines
The risk is not limited to one layer. A pinned application commit can still pull a different base image, a package manager can resolve a newer transitive library, and a CI job can inherit different flags or scripts because the environment changed between executions. Those shifts can change code paths, introduce hidden dependencies, or activate features that were not present in the reviewed build.
Supply chain controls therefore need to cover more than source control. Build inputs, artifact references, dependency managers, registries, and release automation all need stable versioning and traceability. SLSA is directly relevant here because it focuses on build provenance and integrity verification, which is exactly what mutable tags and timing undermine.
Dependency timing also creates a test-and-release problem. If builds succeed or fail depending on when a package is fetched, you do not have a clean signal that the code is safe, only that it was available at that moment. That makes incident review harder too, because you have to reconstruct both the source state and the upstream state to understand what really shipped.
How to reduce exposure without slowing delivery unnecessarily
Practitioners should treat tags, digests, lockfiles, and release metadata as security controls, not just convenience features. Pin base images by digest where possible, lock dependencies with integrity checks, and preserve the exact build recipe and resolved artifact list so the release can be audited or reproduced later. NIST SSDF (SP 800-218) reinforces that software integrity depends on controlled build practices, not only on source review.
Use mutable references only when the operational benefit is intentional and short-lived, then add compensating controls such as signed artifacts, provenance records, and approval for dependency updates. The key judgement is whether a changing reference is part of a managed release process or an uncontrolled supply chain dependency. If it is uncontrolled, it belongs in the same risk category as any other unreviewed change source.
For wider supply-chain assurance, compare the build output against expected provenance rather than trusting the current contents of a registry. OpenSSF is a useful navigation point for practices and projects that improve open source supply chain security, while LiteLLM PyPI package breach shows how dependency trust can be abused when package integrity is not tightly controlled.
Risk and Threat Considerations
Mutable tags and time-dependent dependency resolution create a classic substitution opportunity. An attacker does not always need to change your source code if they can influence what the build process fetches, when it fetches it, or which transitive artifact gets selected at release time.
Failure mechanism: The build resolves different artifacts or runtime inputs across runs, so a later build can incorporate a poisoned dependency, a changed base image, or an altered script path without any visible source diff.
Impact: The released software may contain unexpected functionality, hidden exfiltration paths, or a widened attack surface, and teams may lose the ability to prove what was actually deployed or to reproduce it during incident response.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance and artifact integrity are directly affected by mutable tags and timing. |
| Recommendation — Adopt provenance controls and verify artifact integrity for every release. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Mutable references create unreviewed changes in build inputs and dependencies. |
| SI-7 — Software, Firmware, and Information Integrity | Integrity controls are needed when dependencies can change outside source control. | |
| SA-12 — Supply Chain Protection | The question is about supply-chain exposure from changing upstream artifacts. | |
| Recommendation — Require approval and tracking for any build-input change. Verify software integrity before promotion and deployment. Assess and control upstream dependencies, sources, and update paths. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Dependency pinning and release integrity are core application security safeguards. |
| Recommendation — Implement dependency control and release integrity checks in the pipeline. | ||
Practitioner Guidance
What to verify: Confirm that production builds are reproducible from recorded inputs, including base image digests, lockfiles, and resolved transitive dependencies. If a release cannot be rebuilt to the same artifact, treat that as a control failure rather than a documentation gap.
Decision rule: If a dependency reference can change without an explicit review event, require pinning, provenance capture, or a compensating approval path before it is allowed into a release pipeline. If the change is expected and routine, make the update process deliberate and auditable instead of implicit.
Practitioner takeaway: The security question is not whether a dependency is trusted at checkout time, but whether the same input set will still produce the same artifact when you need to verify, rebuild, or investigate it later.
Related resources from NHI Mgmt Group
- Why do package hallucinations and dependency confusion increase supply chain risk?
- Why do loose dependency constraints increase supply chain risk in application security?
- Why do mutable action tags create such a high supply chain risk in CI/CD?
- Why does dependency depth increase the risk of supply chain vulnerabilities in Node.js projects?