GitHub has added a cache-mode setting that lets you declare the exact level of cache access a workflow or job may have. By selecting read, write, write-only or none you can enforce least‑privilege access, override the built‑in defaults for low‑trust events, and propagate those limits through reusable workflows.
New cache‑mode controls
The feature is now generally available on all GitHub plans. The mode can be defined at the workflow level and overridden per job. The cache service enforces the chosen mode, and a called workflow cannot receive more access than its caller granted. For low‑trust triggers such as pull_request_target, the default switches to read unless an explicit mode is set; for trusted triggers like push, the default remains write. Declaring write or write-only on low‑trust events adds a warning annotation because it raises the risk of cache poisoning.
Why it matters for AI, cloud, DevOps, and security engineers
Cache poisoning can corrupt build artifacts, model checkpoints, or dependency layers that downstream pipelines consume. By limiting which jobs can write to the cache, teams reduce the attack surface without sacrificing the speed benefits of caching. The explicit mode also makes the security posture of CI pipelines visible in the workflow definition, which aligns with compliance and audit requirements.
Operational and security considerations
- Least‑privilege defaults: Review existing workflows to confirm they rely on the appropriate default (read for low‑trust, write for trusted) or add an explicit
cache-modeto tighten access. - Job‑level overrides: Use job‑level settings when a specific step needs to write while the rest of the workflow should remain read‑only.
- Reusable workflows: Remember that a called workflow inherits the caller’s mode; it cannot elevate its own cache permissions.
- Warning annotations: Treat any warning about write access on low‑trust events as a signal to reassess the necessity of that permission.
- Performance impact: Switching to
readornonemay reduce cache restores or saves, potentially affecting build times.
Next steps and monitoring
Adopt a review process that scans for workflows lacking an explicit cache-mode and adds the appropriate setting based on the event type. Track the warning annotations GitHub adds for low‑trust events that request write access, and treat them as actionable findings. Evaluate whether any job currently relies on implicit write permissions and decide if a redesign (e.g., separating cache‑write steps into a trusted workflow) is warranted.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Implement cache-mode declarations to enforce least‑privilege cache usage, especially on low‑trust triggers. Align job‑level overrides with the principle of minimal access, and monitor GitHub’s warning annotations as an early‑warning system for potential cache‑poisoning exposure. Updating existing pipelines now prevents accidental elevation of cache permissions and makes future security reviews more straightforward.