GitHub Actions Enforces Least-Privilege Cache Security With New Cache-Mode Controls

GitHub has introduced granular cache-mode controls for GitHub Actions workflows, giving engineering teams native least-privilege access management over the Actions cache at both workflow and job granularities. The feature introduces four explicit modes: `read` (permits restores while preventing saves), `write` (permits both restores and saves), `write-only` (permits saves but blocks restores), and `none` (completely denies cache access). The policy is enforced directly by GitHub’s caching service and automatically inherits down through reusable workflow hierarchies, ensuring sub-workflows cannot exceed caller-granted permissions. For DevOps practitioners and platform security engineers, CI caching represents a persistent tension between build performance and supply chain integrity. Unrestricted cache write access enables cache poisoning attacks, where an adversary crafts malicious artifacts within an untrusted context—such as a fork PR or third-party action—that subsequent privileged pipeline runs blindly restore and execute. While GitHub Actions defaults low-trust trigger events like `pull_request_target` to read-only behavior, teams previously lacked the syntax to systematically restrict cache write access on custom integration jobs or internal multi-tenant pipelines. The new `cache-mode` parameter eliminates this blind spot by turning caching permissions into an explicit, auditable security policy. This update aligns with a wider industry-wide push to harden CI/CD infrastructure following high-profile supply chain incursions targeting runner environments, shared dependencies, and build pipelines. Over the past several years, major cloud platforms and orchestration frameworks have shifted from perimeter-only defenses toward zero-trust CI/CD architectures. In these modern environments, every build stage, token scope, and caching layer must adhere to strict boundary isolation. By bringing role-based caching permissions natively into workflow syntax, GitHub Actions mirrors similar security models seen in container registry artifact isolation and modern hermetic build systems. In practice, platform teams should immediately audit their primary build workflows to define explicit cache-mode boundaries. Integration test suites and untrusted pull request validation jobs should be pinned to `read` or `none` to prevent rogue writes, while dedicated publishing and post-merge workflows should retain `write` permissions. Furthermore, teams leveraging reusable workflows can now securely enforce upstream constraints across decentralized developer repositories without risk of child workflows widening the cache attack surface.