GitHub Actions cache permissions

A dependency cache improves build speed by reusing files across jobs and workflow runs. That same persistence can cross security boundaries. If a lower-trust job can save content under a key later restored by a trusted release, the cache becomes a route for unreviewed data to influence code that handles deployment credentials or production artefacts.

GitHub protects low-trust triggers with a read-only default, but an explicit write or write-only declaration can override that protection. GitHub adds a workflow warning when write access is granted to a low-trust event. The warning is useful, although the design review still belongs to the team because only the team knows which code runs, which cache keys overlap and what authority the later job holds.

Cache poisoning is not limited to the cache action itself. Package-manager integrations, setup actions and reusable workflows can use the Actions cache on behalf of the job. A sound review starts with the effective permission and every consumer of cached state, not only the most visible YAML step.

Start by classifying each job. A validation job for an external contribution may need a read-only dependency cache, or no shared cache when the restored data could affect sensitive analysis. A trusted main-branch build may need read and write access so it can publish a cache for later runs. A producer that should never consume earlier state can use write-only, although that design still needs unique and predictable cache keys.

Keep cache authority separate from repository and deployment authority. A job that can deploy production should not automatically receive cache write access merely because both activities happen after a merge. Splitting build, verification and release stages makes it easier to prove where untrusted content stops and which stage creates the artefact that reaches production.

Reusable workflows deserve explicit contracts. The caller should grant the maximum cache access that the shared workflow may use, while the called workflow documents which jobs restore or save. This prevents a future edit to the shared workflow from silently broadening cache behaviour across every repository that calls it.

Inventory current cache users before adding policy. Record workflow triggers, reusable workflow calls, cache actions, package-manager caching and the keys shared between branches or events. Then map the effective default GitHub currently provides. This exposes workflows that already rely on write access without stating it and low-trust jobs that should remain restore-only.

Introduce cache-mode in stages. Start with jobs where the correct permission is unambiguous, then inspect workflow logs for skipped restores or saves. GitHub treats a blocked restore as a cache miss and a blocked save as an informational event, so a workflow can stay green while build time or cache freshness changes. Operational validation must therefore include timing and cache behaviour, not only the final status.

After the rollout, test the trust boundary with representative pull requests and main-branch releases. Confirm that untrusted runs cannot save to caches consumed by privileged jobs, that reusable workflows inherit the intended ceiling and that a cache miss still produces a complete build. Document the exception process for any job that needs broader access so later convenience changes do not quietly weaken the release path.