GitHub Actions Cache Isolation: Community Insights for Secure Software Management

Enhancing GitHub Actions Cache Security: Community Weighs In on New Controls

The efficiency of GitHub Actions Cache is undeniable, but it comes with a critical security vulnerability: cache poisoning. In a recent GitHub Community discussion, "Help Us Improve GitHub Actions Cache Isolation 🔧," GitHub acknowledged a significant challenge: untrusted workflows can write to shared cache namespaces, potentially influencing trusted builds like release pipelines without detection by existing attestations. This poses a substantial risk to software supply chain integrity and demands robust solutions for any diligent software manager.

GitHub's Proposed Solution: `cache-mode`

To address this, GitHub is exploring a new cache-mode setting, configurable at both the workflow and job levels. This declarative control aims to reduce cache poisoning risk while maintaining current default behavior. The proposed values are:

• write: Both restore and save operations are permitted (current default).
• read: Restore is allowed, but save operations are rejected by the cache service.
• none: No cache access whatsoever.

Key properties include defaulting to write for backward compatibility, job-level overrides, and enforcement by the cache service itself, making it impossible for actions or scripts to bypass. Runtime signals like job['cache-mode'] and ACTIONS_CACHE_MODE will also be exposed to aid action authors in adapting.

Example: Secure Release Workflow

A common scenario involves a trusted release job explicitly opting into write mode while other workflows remain read-only:

name: Release
on: 
  push:
    branches: [main]
  workflow_dispatch:
# Default the workflow to read only...
cache-mode: read
jobs:
  build:
    runs-on: ubuntu-latest
    # ...but allow the release build to populate the cache.
    cache-mode: write
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run build
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Community Feedback: Enhancing Control and Visibility

The community's response highlighted several critical areas for improvement:

• Admin-Level Controls: A strong consensus emerged for repository or organization-level default cache-mode settings, configurable via API. This is crucial for a software manager to enforce security policies across an entire codebase or organization.
• Finer Granularity: Suggestions included separating "restore" and "save" semantics explicitly, proposing modes like read, write (save only), read-write, and none to offer more nuanced control over cache authority.
• Cache Provenance: A significant demand for visibility into which workflow created a cache, which branch populated it, and its trust context. Exposing this metadata in logs, the UI, API, and even Sigstore transparency logs would be invaluable for debugging, auditing, and SLSA compliance.
• Naming: Alternatives like cache, caching, cache-permission, or cache-access were suggested to improve clarity and avoid syntax awkwardness.
• Urgency: Several contributors stressed the immediate need for these security enhancements, emphasizing that such vulnerabilities should have been addressed "yesterday."

Addressing Software Management Concerns

For a software manager, these proposed changes and community feedback are vital. The ability to declaratively control cache access reduces the attack surface, prevents untrusted code from influencing critical builds, and strengthens the overall software supply chain. Features like organization-wide policies and cache provenance directly empower managers to audit CI/CD behavior, ensure compliance with security standards like SLSA, and make informed trust decisions about published artifacts. This proactive approach to cache isolation is a significant step towards more secure and predictable CI/CD pipelines.

Looking Ahead

While Phase 1 focuses on workflow and job-level controls, GitHub acknowledges the need for broader administrative policy controls (Phase 2). The community's active participation underscores the importance of getting this right, ensuring that GitHub Actions Cache remains a powerful performance tool without compromising security.