Why do shared CI workspaces make build-cache attacks more dangerous?

Shared workspaces let untrusted writes survive long enough to be consumed by later jobs that run with higher privilege or more secrets. That turns a local cache issue into a supply-chain problem because the attacker is not trying to break the build immediately. They are trying to influence the next trusted execution step.

Why Shared CI Workspaces Turn Cache Poisoning into a Supply-Chain Issue

Shared CI workspaces are dangerous because they collapse trust boundaries. A job that should only produce artifacts can leave behind files, cache entries, or symlinks that are later consumed by a different job with broader permissions. That is why cache abuse is not just a local build integrity problem. It becomes a path to influencing trusted execution, secret exposure, or artifact tampering. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks shows how often secrets and service identities are overexposed in real environments.

The operational mistake is assuming the workspace belongs to the pipeline, when in practice it becomes a shared persistence layer for code, credentials, and build outputs. Industry guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need to isolate assets and limit cross-process contamination, but CI systems often lag behind that model. In practice, many security teams discover cache poisoning only after a trusted build has already reused attacker-controlled data.

How the Attack Works in Practice

Attackers usually do not need to break the primary build step. They need to write something durable into a shared cache, workspace, or dependency directory that a later job will trust. That later job may run on a protected branch, have release-signing permissions, or inherit secrets used for publishing. Once the poisoned content is consumed, the attacker can alter build behavior, inject code, or steer the pipeline toward unsafe outputs.

This risk is amplified when CI workers reuse volumes across jobs, when cache keys are broad, or when untrusted pull request builds share the same runner pool as protected builds. The most common failure modes are stale dependency directories, writable build caches, and workspace artifacts that are not scrubbed between executions. For background on how non-human identities and exposed secrets compound this risk, see the 52 NHI Breaches Analysis and the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research.

• Use isolated runners for untrusted and trusted jobs.
• Make caches read-only for consumers whenever possible.
• Scope cache keys to branch, lockfile, and trust level.
• Scrub workspaces between jobs, not just between pipelines.
• Store secrets outside the workspace and inject them just in time.

Controls such as provenance checks, artifact signing, and cache partitioning matter most when untrusted code can reach the same runner image, because then the attacker can shape what the next privileged job sees before any detection occurs. These controls tend to break down in long-lived self-hosted runners with shared disks and permissive cache reuse.

Where the Standard Advice Breaks Down

Tighter cache isolation often increases build time, storage cost, and runner complexity, so organisations have to balance performance against integrity. Best practice is evolving, and there is no universal standard for every CI platform yet. The practical question is not whether caching helps, but which cached objects are safe to share across trust boundaries.

One useful mental model is to treat the workspace as an untrusted input channel unless it is freshly created for a specific trust tier. That means separating caches for pull requests, release branches, and signed builds; enforcing short retention windows; and denying write access from jobs that do not need it. NIST-style least privilege remains relevant, but shared CI often needs stronger segregation than ordinary RBAC because the same repository can host both hostile and trusted execution paths. For broader identity and secret governance patterns, NHI Management Group’s Top 10 NHI Issues and OWASP NHI Top 10 are useful references.

The edge case is ephemeral or matrix-style CI where dozens of jobs fan out across the same disk image, because even small cache contamination can spread across many executions before anyone notices.

Related resources from NHI Mgmt Group

• How can organizations counter AI-driven cyber attacks?
• How should teams respond when CI or developer secrets are exposed?
• Why do secrets stay dangerous even when they are no longer actively used?
• Why do service-to-service credentials make MITM attacks more dangerous?