GitHub Actions Adds 'cache-mode' to Neutralize Supply Chain Cache Poisoning Risks

GitHub has made cache-mode generally available across all plans for GitHub Actions, introducing declarative, server-side enforcement of cache access permissions. Workflows and individual jobs can now explicitly define their cache access level using four distinct modes: read (restores cache but prevents saves), write (allows restores and saves), write-only (allows saves but prevents restores), and none (blocks all cache access). Settings defined at the job level override workflow-level declarations, and access restrictions are strictly enforced by the backend cache service across callers and reusable workflows. Furthermore, attempting to grant write permissions on low-trust events such as pull_request_target triggers a warning annotation in the workflow run logs. For DevOps, platform, and security engineering teams, shared cache storage has historically posed a significant supply chain vulnerability: cache poisoning. In typical CI/CD environments, untrusted pull requests or compromised build dependencies could overwrite cached artifacts or package registries, subsequently executing malicious payloads in downstream release jobs. Previously, mitigating this required clumsy workarounds, such as disabling caching altogether on untrusted triggers or crafting custom script logic. With cache-mode, least-privilege access becomes granular and enforceable at the job boundary, enabling developers to safely restore dependencies in evaluation steps without giving untrusted processes permission to write back to the shared repository cache. This release aligns directly with GitHub's broader 2026 supply chain security roadmap, which emphasizes shifting CI/CD systems toward deterministic execution, tightly scoped credentials, and strict policy boundaries. As software delivery pipelines increasingly become the primary attack surface for supply chain compromises, platform providers are moving beyond standard API token scopes to isolate runtime operational resources like runners, workflow contexts, and build caches. Enforcing cache isolation at the platform service layer mirrors Zero Trust architecture principles applied directly to ephemeral pipeline execution. In practice, platform teams should immediately audit existing workflow templates and configure least-privilege defaults across shared pipelines. Test and linting jobs handling third-party pull request code should be locked down to cache-mode: read or none. Upstream build-and-publish jobs on protected branches can retain write access, while preliminary artifact seeding jobs can leverage write-only. Crucially, because reusable workflows inherit caller constraints and cannot elevate privileges beyond what the invoking workflow allows, organizations can establish standardized security baselines across hundreds of repositories without impeding developer productivity.