GitHub Actions: cache-mode steuert Lese- und Schreibrechte

Ein Build-Cache bewahrt beispielsweise heruntergeladene Abhängigkeiten oder erzeugte Dateien für den nächsten Lauf auf. Das spart Zeit. Es bedeutet aber auch: Ein Workflow legt Material ab, das ein anderer Workflow später wiederverwenden könnte.

GitHub stellt diesen Zugriff seit dem 10. September als YAML-gesteuerte Einstellung bereit. Der neue Schlüssel cache-mode ist für alle GitHub-Tarife allgemein verfügbar und lässt sich für einen ganzen Workflow oder einen einzelnen Job setzen.

Vier Werte stehen zur Verfügung:

Modus	Wiederherstellen	Speichern
`read`	ja	nein
`write`	ja	ja
`write-only`	nein	ja
`none`	nein	nein

Eine Vorgabe am Job überschreibt die Einstellung des Workflows. Bei einem wiederverwendbaren Workflow bleibt die Grenze dagegen erhalten. Ein solcher Workflow ist eine zentral abgelegte GitHub-Actions-Definition, die andere Workflows über einen Job aufrufen können. Der aufgerufene Workflow kann nicht mehr Cache-Zugriff erhalten, als sein Aufrufer besitzt. Berechtigungen sollen schließlich nicht durch einen Seiteneingang wachsen.

Ein Pull-Request-Workflow darf lesen, aber nichts hinterlassen

Dieses Minimalgerüst entspricht der von GitHub dokumentierten Syntax. Der Pull-Request-Workflow kann einen vorhandenen npm-Cache wiederherstellen, aber keinen neuen Cache speichern:

on:
  pull_request:

cache-mode: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/cache@v4
        with:
          path: ~/.npm
          key: npm-$

Versucht ein Schritt trotzdem zu speichern, bricht der Lauf nicht ab. GitHub protokolliert den unterbundenen Zugriff lediglich als Information. Das ist angenehm für die CI, aber leicht zu übersehen: Wer die Umstellung prüft, sollte deshalb auch die Logs lesen und nicht nur nach einem grünen Haken schauen.

Warum ein Cache zur Lieferkette gehört

Beim Cache-Poisoning bringt ein wenig vertrauenswürdiger Lauf manipulierte Dateien unter einem Cache-Schlüssel unter. Ein späterer, vertrauenswürdiger Build stellt diesen Cache wieder her und verwendet daraus etwa Werkzeuge, Abhängigkeiten oder erzeugte Artefakte. Der Angriff erfolgt dann zeitversetzt: Der gefährliche Lauf schreibt, der privilegierte Lauf führt aus.

cache-mode: read unterbindet für den betreffenden Lauf das Speichern in den GitHub-Actions-Cache. Der Pull-Request-Workflow darf von einem bereits vorhandenen Cache profitieren, aber keinen eigenen Inhalt für spätere Läufe dort hinterlassen. none sperrt zusätzlich das Wiederherstellen. Beide Einstellungen begrenzen damit einen möglichen Schreibpfad; sie prüfen jedoch weder vorhandene Caches noch andere Cache-Systeme. Schlüsselwahl, getrennte Vertrauensbereiche und reproduzierbare Builds bleiben relevant.

Besondere Vorsicht gilt für pull_request_target. Dieses GitHub-Actions-Ereignis wird durch Aktivitäten an einem Pull Request ausgelöst, führt den Workflow aber im Kontext des Zielbranches statt des vorgeschlagenen Quellbranches aus. GitHub behandelt solche niedrig vertrauenswürdigen Auslöser standardmäßig als nur lesend. Wer dort ausdrücklich write oder write-only setzt, kann die sichere Cache-Voreinstellung wieder aufheben. GitHub blendet dafür eine Warnannotation ein; sie stoppt den Lauf nicht und verhindert das Schreiben nicht.

Was jetzt sinnvoll ist

Bestehende Workflows funktionieren ohne Änderung weiter und behalten ihre auslöserabhängigen Voreinstellungen. Eine hektische Migration ist daher nicht nötig. Ein kurzer Rechte-Check lohnt sich trotzdem:

Workflows mit actions/cache oder eingebautem Dependency-Caching erfassen.
Pull-Request-Prüfungen auf read oder, wenn kein Cache nötig ist, auf none setzen.
Schreibrechte nur vertrauenswürdigen Push- oder Veröffentlichungsjobs geben.
Job-Ausnahmen und aufgerufene wiederverwendbare Workflows mitprüfen.
Nach der Änderung die Protokolle auf übersprungene Cache-Zugriffe kontrollieren.

Der Gewinn ist klein, aber konkret: Schnelle Builds bleiben schnell, während nicht jeder Lauf etwas für die Zukunft hinterlassen darf.

Quellen

GitHub Changelog: Control GitHub Actions cache access with cache-mode, 10. September 2026
GitHub Docs: Workflow syntax for cache-mode, abgerufen am 12. September 2026

Quellenstand: 12. September 2026.