Using SBOMs to Govern Build Cache Integrity and Remote Cache Risk in Federal CI/CD Systems

Federal software pipelines have grown faster and more distributed, but the caching infrastructure underneath them has not kept pace with the governance requirements those environments demand. Remote build caches, shared pipeline runners, and artifact caching layers accelerate delivery, but they also introduce a category of supply chain risk that most SBOM programs have not been designed to address. When a cached build output is consumed without verification, the pipeline is effectively trusting a prior state of the world, one that may have changed in ways no one has documented.

The problem is not that caching is inherently unsafe. It is that caching creates a gap between what the build system believes it produced and what actually entered the pipeline. That gap is where provenance breaks down. A developer sees a green build. The artifact repository receives a signed package. But somewhere in between, a cached intermediate output substituted for a freshly compiled one, and no one recorded which inputs produced that cached entry or whether those inputs are still trusted.

Federal DevSecOps environments face this problem at scale. Agencies using managed CI/CD services, shared runner pools, or distributed build tools like Bazel, Gradle, or Maven encounter remote cache hits constantly. In many cases, those cache hits are the intended behavior. The question is whether the organization has controls in place to know when a cache hit is safe and when it represents an unverified substitution that should trigger a fresh build or a policy gate.

A build cache SBOM strategy addresses this by extending component visibility into the cache layer itself. Rather than treating cached outputs as equivalent to freshly built ones, a mature program uses SBOM data, cryptographic verification, and cache governance policy to distinguish between trusted cache entries and those that require revalidation. This article focuses on the operational controls, architecture decisions, and federal implementation patterns that make that distinction actionable.

How Build Caches Create Provenance Gaps in Federal Pipelines

Build caches operate on a simple premise: if the inputs to a build step have not changed, the outputs from a previous run can be reused. That premise is sound in a controlled environment where inputs are well-defined, the cache is isolated, and the population of cache entries is trusted. In a distributed federal CI/CD environment, none of those conditions are guaranteed by default.

Local caches, the kind that live on a single build agent or developer workstation, carry relatively contained risk. The trust boundary is narrow. If the machine is compromised, the cache is one of many concerns. Remote caches are different. A remote cache shared across a runner pool means that a cache entry written by one pipeline job can be consumed by a completely different job running in a different context, potentially with different security requirements, different authorization boundaries, or different software assurance expectations.

The provenance gap emerges when the consuming job has no way to verify that the cache entry it received was produced by a trusted build, using trusted inputs, at a point in time when those inputs were known to be clean. The build log may show a cache hit, but the SBOM generated at the end of the pipeline reflects the declared dependencies, not necessarily the actual compiled artifacts. If a cached intermediate replaced a freshly compiled one, the SBOM may accurately describe what was supposed to be built without accurately describing what was actually delivered.

This distinction matters for federal programs operating under software supply chain requirements. An SBOM that does not account for cache substitution is not a complete record of provenance. It is a record of intent. For agencies where software assurance is tied to authorization decisions, that gap is not a documentation problem. It is a risk management problem.

Cache Poisoning and Stale Artifact Risk

Cache poisoning and stale artifact consumption are related but distinct failure modes. Understanding the difference helps teams design controls that address each one specifically rather than applying a single policy that handles neither well.

Cache poisoning occurs when a malicious or corrupted entry is written into the cache and subsequently consumed by downstream jobs. In a shared remote cache, any pipeline with write access to the cache namespace can potentially introduce a poisoned entry. If cache write permissions are not scoped tightly, a compromised job, a misconfigured runner, or a dependency confusion attack that succeeds during a single build can propagate a malicious artifact to every subsequent job that hits that cache key. The consuming job has no reason to suspect a problem because the cache key matches and the build appears to succeed.

Stale artifact risk is less dramatic but more common. It occurs when a cache entry that was valid at the time of population becomes invalid due to a change in the underlying dependency, a vulnerability disclosure, a policy update, or a configuration drift in the build environment. The cache key still matches, the entry is still served, and the consuming job produces an artifact that reflects an outdated state of the world. In a fast-moving pipeline, stale cache entries can persist for days or weeks before anyone notices that the outputs do not reflect current dependency versions.

Both failure modes are compounded by the fact that most CI/CD platforms do not generate detailed logs of which cache entries were consumed during a given build, what inputs were used to compute the cache key, or when the cache entry was originally written. Without that data, incident response after a suspected poisoning event is largely forensic reconstruction rather than log review.

Cache Key Design, Namespace Isolation, and Trust Boundaries

Cache key design is the first line of defense against both poisoning and stale artifact consumption. A cache key that does not fully capture the inputs to a build step will produce false hits, where the key matches but the inputs have actually changed. A cache key that is too broad will cause cache misses that undermine the performance rationale for caching in the first place. Getting this balance right requires understanding what actually affects build outputs in a given environment.

For compiled languages, the cache key should incorporate the compiler version, the build tool version, the dependency manifest hash, the source file hashes for the relevant module, and any environment variables that affect compilation behavior. For container layer caches, the key should reflect the base image digest, not just the tag, because tags are mutable and a tag-based cache key will produce a hit even when the underlying image has changed. For package manager caches, the lock file hash is a minimum requirement, but it does not account for changes in the upstream registry or the integrity of the packages themselves.

Namespace Isolation for Shared Runners

Shared runners introduce a trust boundary problem that cache key design alone cannot solve. When multiple projects, teams, or classification levels share a runner pool, the cache namespace must enforce separation between them. Without namespace isolation, a cache entry written by a low-trust pipeline is potentially readable by a high-trust one. In a federal environment where different systems operate under different authorization boundaries, that cross-contamination is a policy violation regardless of whether any actual poisoning occurred.

Namespace design should map to the trust domains in the environment. A project-scoped namespace prevents cross-project cache sharing but may still allow sharing across branches or pipeline stages with different security requirements. A stage-scoped namespace provides tighter isolation but reduces cache reuse. The right design depends on the sensitivity of the artifacts being produced and the authorization requirements of the systems consuming them. Federal programs should document their namespace design as part of the system security plan and validate it during RMF assessment rather than treating it as a CI/CD configuration detail.

Write Access Controls and Trusted Cache Population

Trusted cache population means that only verified, policy-compliant builds are permitted to write entries into the remote cache. This requires separating read and write permissions at the cache layer and restricting write access to pipeline stages that have passed defined quality and security gates. A job that fails a static analysis scan, a dependency vulnerability check, or a policy compliance gate should not be permitted to write its outputs to the shared cache, even if the build otherwise succeeded.

Implementing this in practice requires cache backends that support fine-grained access control, which not all managed CI/CD services provide natively. In environments where the cache backend does not support write restrictions, teams can implement a proxy layer that enforces policy before allowing cache writes, or they can restrict cache population to a dedicated, hardened build environment rather than allowing any runner in the pool to write.

Cryptographic Verification and Attestation for Cached Outputs

Cryptographic verification of cache entries addresses the question of whether the entry that was retrieved is the same one that was originally written. A cache entry that has been tampered with in transit or at rest will produce a different hash than the one recorded at write time. Verifying that hash before consuming the entry prevents a class of substitution attacks where an attacker modifies a cache entry after it has been written by a trusted build.

The verification mechanism needs to be implemented at the point of consumption, not just at the point of population. A build tool that computes a hash when writing a cache entry but does not verify that hash when reading it provides no protection against post-write tampering. Federal programs should confirm that their build tools and cache backends support end-to-end integrity verification and that the verification step is not disabled for performance reasons.

Attestation goes further than integrity verification. Where integrity verification confirms that an entry has not been altered, attestation records the provenance of the entry: which build produced it, what inputs were used, what policy gates were passed, and when it was created. An attestation document associated with a cache entry allows a consuming job to make an informed trust decision rather than simply accepting the entry because the key matched and the hash verified.

Generating attestations for cache entries requires instrumentation at the build level. The build system must record the relevant metadata at the time of cache population and associate that metadata with the cache entry in a way that survives retrieval. For federal programs working toward Software Bill of Materials (SBOM) compliance, cache attestations can be structured as SBOM extensions or as in-toto attestations that link cached outputs back to their originating build steps. This creates a chain of custody that extends from source code through the cache layer to the final artifact.

SBOM Limitations and Cache Governance Controls

Standard SBOM generation tools are designed to analyze declared dependencies and, in some cases, installed packages or compiled binaries. They are not designed to detect when a cached intermediate artifact has substituted for a freshly compiled one. This is a fundamental limitation that federal programs need to understand before concluding that SBOM generation alone provides adequate visibility into build cache risk.

An SBOM generated from the final artifact of a build that consumed cached intermediates will typically reflect the declared dependency graph accurately. It will not reflect whether those intermediates were actually compiled from the declared sources during the current build, or whether they were retrieved from a cache entry that was written days or weeks earlier using a different version of a transitive dependency. The SBOM is accurate as a description of the artifact’s structure, but it does not capture the build-time substitution that occurred.

Closing this gap requires supplementing SBOM data with cache governance records. Those records should capture, at minimum, which cache entries were consumed during each build, the cache key used to retrieve each entry, the hash of the retrieved entry, the attestation associated with the entry if one exists, and the age of the entry relative to the current build. When a vulnerability is disclosed in a dependency that was present in a cached intermediate, this record allows the program to identify which builds consumed that cached entry and which artifacts may be affected.

Cache invalidation policy is a governance decision that affects SBOM accuracy downstream. When a dependency is updated, a vulnerability is disclosed, or a build environment configuration changes, any cache entries that were produced under the prior state should be invalidated. If they are not, subsequent builds that hit those entries will produce artifacts that do not reflect the current state of the dependency graph, and the SBOMs generated from those artifacts will be inaccurate in ways that are difficult to detect after the fact.

Retention policy interacts with invalidation policy. A cache entry that is retained indefinitely will eventually become stale regardless of how well the invalidation triggers are defined, because the environment around it will change even if the entry itself does not. Federal programs should define maximum retention windows for cache entries based on the sensitivity of the artifacts being produced and the rate of change in the dependency ecosystem, and they should enforce those windows through automated eviction rather than relying on manual cleanup.

Common Mistakes

The most common mistake is treating cache configuration as a CI/CD performance concern rather than a supply chain security control. When cache settings are owned by the pipeline team and optimized for build speed, the governance requirements that would make those caches trustworthy from a software assurance perspective are never applied. The result is a fast pipeline that produces artifacts with undocumented provenance gaps.

A second mistake is assuming that SBOM generation at the end of the pipeline captures the full picture of what was built. When cached intermediates are consumed without attestation, the SBOM reflects the declared dependency graph but not the actual build-time substitutions. Programs that rely on this SBOM for authorization decisions or vulnerability impact analysis are working from an incomplete record without knowing it.

Shared runner pools are frequently deployed without namespace isolation because the initial deployment prioritizes resource efficiency. As the runner pool grows to serve more projects, the lack of isolation becomes a policy problem, but by that point the configuration is embedded in dozens of pipelines and changing it requires coordinated effort across multiple teams. Federal programs should define namespace isolation requirements before deploying shared infrastructure, not after.

Cache invalidation is often treated as a manual process triggered by developer awareness rather than an automated control tied to defined events. When a dependency vulnerability is disclosed, the team responsible for the affected pipeline may invalidate their local cache, but shared remote cache entries that contain the vulnerable dependency may persist and continue to be consumed by other pipelines. Without a centralized invalidation mechanism tied to vulnerability intelligence, stale entries accumulate across the environment.

Write access to remote caches is frequently left open to all runners in the pool because restricting it requires additional configuration that is not part of the default setup. Open write access means that any compromised or misconfigured job can write to the shared cache, including jobs that have failed security gates or that are running in an untrusted context. This is the primary enabler of cache poisoning in shared pipeline environments.

Finally, cache governance is rarely included in RMF documentation or system security plans. Assessors reviewing a federal system’s software supply chain controls may examine the artifact repository, the SBOM generation process, and the pipeline configuration, but the cache layer is often undocumented and unreviewed. That gap means that cache-related risks are not formally accepted, mitigated, or tracked, which creates accountability problems when an incident occurs.

Recommended Federal Approach

Start with a current-state inventory. Before implementing any new controls, map every cache layer in the CI/CD environment: local agent caches, remote cache backends, container layer caches, package manager caches, and any caching behavior embedded in managed CI/CD services. For each cache, document who has read access, who has write access, what namespace structure is in place, what the retention window is, and whether any invalidation triggers are defined. This inventory will reveal gaps that are not visible from pipeline configuration files alone.

Assign ownership. Cache governance requires a named owner who is accountable for the policy, the configuration, and the response when something goes wrong. In many federal programs, cache configuration falls into a gap between the pipeline team, the infrastructure team, and the security team. Closing that gap requires explicit ownership assignment, documented in the program’s governance structure, not just in a team wiki.

Prioritize controls based on the trust model. Not every cache layer carries the same risk. A local cache on a dedicated, single-project build agent is a lower priority than a remote cache shared across a multi-project runner pool. Apply the most rigorous controls, namespace isolation, write access restriction, cryptographic verification, and attestation, to the shared remote caches first. Extend those controls to lower-risk caches as capacity allows.

Integrate cache governance into the SBOM program. The goal is not to generate a separate cache SBOM but to ensure that the existing SBOM program accounts for cache-related provenance gaps. This means instrumenting cache population to generate attestations, linking those attestations to the SBOM records for the artifacts that consumed the cached entries, and including cache consumption data in the build provenance documentation that supports authorization decisions.

Define invalidation triggers as policy. At minimum, cache entries should be invalidated when a dependency vulnerability is disclosed that affects the inputs used to produce the entry, when the build environment configuration changes in a way that affects outputs, when a security incident is suspected or confirmed in the pipeline, and when the entry exceeds the defined maximum retention window. These triggers should be documented, automated where possible, and tested to confirm they actually result in cache eviction.

Incorporate cache governance into RMF documentation. The system security plan should describe the cache architecture, the trust boundaries enforced through namespace isolation, the access controls on cache write operations, the integrity verification mechanism, the attestation approach, and the invalidation and retention policy. Assessors should be able to review this documentation and validate the controls during assessment rather than discovering the cache layer as an undocumented component.

Build incident response procedures that account for cache poisoning scenarios. When a suspected poisoning event occurs, the response team needs to know which cache entries were consumed during a defined time window, which builds consumed them, which artifacts those builds produced, and where those artifacts were deployed. Without pre-defined procedures and the logging infrastructure to support them, that reconstruction will take days. With them, it can take hours. Federal programs should exercise these procedures before they are needed, not after.