Build cache poisoning occurs when an attacker seeds a CI cache with malicious or untrusted content that later gets reused by a trusted job. Because caches are designed to speed up builds, poisoned entries can bypass expected checks and alter release outputs. Segregating trusted and untrusted workflows reduces the risk.
Expanded Definition
Build cache poisoning is a software supply chain attack against CI and build systems in which an attacker introduces malicious, stale, or untrusted cache artifacts that are later consumed by a trusted pipeline run. The key issue is not the cache itself, but the trust boundary around reuse: once a build process treats cached output as authoritative, the poisoned artifact can influence compilation, packaging, or release steps without re-executing the original checks.
Definitions vary across vendors and toolchains because cache design differs across language ecosystems, runners, and orchestrators, but the security pattern is consistent. A poisoned cache becomes dangerous when a privileged job can read data written by a less trusted job, or when cache keys are too broad and allow collisions between unrelated workflows. NHI Management Group treats this as a pipeline integrity issue, not merely a performance defect.
The most common misapplication is assuming cache reuse is safe by default, which occurs when teams do not separate cache namespaces for forked, external, and trusted builds.
Examples and Use Cases
Implementing cache controls rigorously often introduces slower builds and stricter workflow segregation, requiring organisations to weigh delivery speed against the cost of stronger integrity boundaries.
- A pull request from an external contributor writes dependency artifacts into a shared cache, and a later main-branch build reuses them during packaging.
- A broad cache key, such as one based only on the branch name, causes unrelated jobs to restore artifacts that were produced under different trust conditions.
- A compromised CI runner seeds a compiler cache with tampered objects, affecting subsequent releases even though source code reviews remain clean.
- A build pipeline that does not isolate caches for signed and unsigned jobs allows an untrusted workflow to influence a release candidate.
- Security teams map cache governance to NIST SP 800-53 Rev 5 Security and Privacy Controls when defining integrity, access, and change management expectations for CI environments.
Why It Matters for Security Teams
Build cache poisoning matters because it turns efficiency tooling into an integrity weakness. Security teams may focus on source control protections, code review, and artifact signing, yet still miss the build layer where cached inputs can silently shape outputs. Once poisoned content enters a trusted job, the resulting compromise can affect binaries, containers, packages, or SBOM generation, making investigation difficult because the malicious input never appeared in the source tree.
This issue is especially relevant in modern software delivery because build systems often run with elevated credentials, access to secrets, and permissions to publish artifacts. In identity terms, the concern is not human identity but workload trust: service accounts, CI tokens, and ephemeral runners become the actors that need constrained access and clear provenance. Cache isolation, key scoping, and trust-segmented pipelines are therefore governance controls as much as technical ones.
Organisations typically encounter the impact only after a clean-looking release behaves unexpectedly in production, at which point build cache poisoning becomes operationally unavoidable to investigate and contain.
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 and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-6 | Integrity of data at rest and in transit applies to cached build artifacts. |
| NIST SP 800-53 Rev 5 | SI-7 | Integrity verification controls map directly to detecting tampered build cache content. |
| OWASP Non-Human Identity Top 10 | NHI guidance applies because CI runners and service accounts act as non-human identities here. | |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero trust separates trust decisions from network location, fitting cache reuse risks. |
| NIST SP 800-63 | IAL2 | Assurance concepts help distinguish trusted automation identities from untrusted contributors. |
Add integrity checks and provenance validation before restored cache entries can influence releases.
Related resources from NHI Mgmt Group
- Why do shared CI workspaces make build-cache attacks more dangerous?
- What happens when a shared cache uses user-controlled headers to build redirects or page metadata?
- How should security teams defend against web cache poisoning when CDNs and origin servers parse URLs differently?
- Why do URL parsing differences between a CDN and an application server create cache poisoning risk?
