GitHub Actions Adds Granular cache-mode Controls to Mitigate Pipeline Poisoning

GitHub has officially launched a new `cache-mode` configuration setting in GitHub Actions, making fine-grained cache permissioning generally available across all plans. The feature allows engineering and security teams to apply the principle of least privilege directly to workflow and job caching routines. Organizations can now explicitly select from four discrete permission levels: `read` (permits cache restores while preventing saves), `write` (permits both restores and saves), `write-only` (permits saves while restricting restores), and `none` (completely blocks cache interaction). Job-level declarations override workflow defaults and strictly propagate down through reusable workflows, preventing called pipelines from inheriting broader permissions than intended by the caller. Additionally, GitHub Actions now surfaces an explicit warning annotation whenever write capabilities are granted to low-trust triggers like `pull_request_target`. This update matters because shared CI/CD caches have historically created lateral attack paths across development pipelines. In conventional configurations, workflows often retained unconstrained access to save and overwrite build dependencies, language package caches, and intermediate artifacts. If an attacker managed to trigger an untrusted pull request or compromise a secondary dependency step, they could tamper with cached toolchains or binaries. Subsequent production builds reusing that poisoned cache would inadvertently incorporate malicious code without altering the source repository. By enabling teams to restrict pull requests and unverified workflows to `read` or `none`, security engineers can enforce hard isolation boundaries across pipeline runs. This development fits into the broader enterprise shift toward hardened CI/CD supply chain governance. Over the past several years, prominent software supply chain incidents have demonstrated that continuous integration runners and build tooling—not just application source code—are prime targets for adversary infiltration. The industry has progressively moved away from implicit trust models, adopting strict OpenID Connect (OIDC) identity federation, signed software bills of materials (SBOMs), and SLSA build-level attestations. Hardening cache boundaries represents a natural and necessary operational continuation of this trend, treating build state as an untrusted asset that requires strict cryptographic and authorization boundaries. In practice, DevSecOps teams should immediately audit existing GitHub Actions workflow files to replace default caching behavior with explicit `cache-mode` declarations. Platform teams should set default policies that restrict fork PR workflows and linting jobs to `read` or `none`, while reserving `write` access exclusively for authenticated merge pipelines targeting default release branches. For high-assurance build steps, adopting a `write-only` paradigm for base builds alongside pinned dependency hashes ensures that artifacts are published without exposing build runners to arbitrary state injection.