GitHub Actions Adds Granular cache-mode Controls to Thwart Supply Chain Poisoning

GitHub has made the `cache-mode` configuration generally available across all plans for GitHub Actions, enabling engineering teams to enforce least-privilege access over workflow caching at both the workflow and job levels. The new syntax supports four distinct permission states: `read` (cache restoration only), `write` (both save and restore), `write-only` (saving new caches without restoring), and `none` (complete cache isolation). These controls are enforced natively by GitHub's cache service and propagate automatically through reusable workflows, preventing downstream or called workflows from escalating cache access beyond what the parent caller authorized. This update addresses a critical vulnerability space in continuous integration: cache poisoning. In complex build pipelines, dependency and build artifact caches are often shared across jobs or pull request evaluations to optimize execution speed. When low-trust events—such as forks running via `pull_request_target`—or semi-trusted jobs gain write permissions to the cache store, an attacker can overwrite cached binaries, libraries, or tooling with compromised versions. When high-privilege release or deployment workflows subsequently restore those poisoned caches, attackers achieve arbitrary code execution inside trusted boundary contexts. By locking down cache access declaratively, organizations can ensure that untrusted PR evaluations and external code paths cannot alter shared repository caches. The feature directly aligns with the broader industry movement toward zero-trust CI/CD infrastructure and software supply chain hardening. As platforms transition from treating CI runners as monolithic batch processors to tightly constrained execution sandboxes, access controls are moving down to the micro-level—spanning tokens, environment variables, network egress, and storage. The introduction of `cache-mode` complements GitHub's wider security roadmap for Actions, which emphasizes deterministic execution, bounded trust domains, and strict policy enforcement. In practice, DevOps teams should review high-risk pipelines immediately. Any job handling untrusted artifacts, community PRs, or experimental agentic workflows should explicitly specify `cache-mode: none` or `cache-mode: read`. Cache write privileges should be confined exclusively to baseline population jobs running on protected branches. Platform teams must also note that setting `write` or `write-only` on low-trust triggers now emits warning annotations in Actions runs, giving security auditors an actionable mechanism to catch misconfigurations before release pipelines consume tampered cache state.