Ein Pull Request kann den Mac-CI-Cache erreichen, obwohl sein Code nicht vertrauenswürdig ist.

Schnellste Lösung: Setzen Sie GitHub Actions cache-mode pro Workflow oder Job auf die tatsächlich benötigte Berechtigung; die Job-Einstellung hat Vorrang, und Sie müssen die Wirkung anhand des Laufs prüfen.

Dieser Leitfaden richtet sich an Entwickler, die Mac-CI-Caches pflegen und Zugriffe je Aufgabe trennen müssen.
Sicherheitsverantwortliche finden Kriterien zur Begrenzung wenig vertrauenswürdiger Ereignisse.
Plattformteams erhalten eine prüfbare Vorgehensweise für mehrere Apple-Projekte und wiederverwendbare Workflows.

Berechtigungsumfang statt pauschalem Schreibzugriff

GitHub Actions cache-mode steuert, ob ein Workflow Cache-Einträge wiederherstellen, speichern oder auf den Cache verzichten darf. Die Funktion ist laut GitHubs Ankündigung zur Kontrolle des Cache-Zugriffs mit cache-mode für alle Pläne verfügbar. Für Mac CI ist das wichtig, weil mehrere Aufgaben denselben Cache nutzen können, obwohl sie unterschiedliche Vertrauensstufen haben: Ein interner Build, ein externer Pull Request und ein geplanter Release-Lauf sollten nicht automatisch dieselben Rechte erhalten.

Welche Cache-Berechtigungen bietet GitHub Actions cache-mode? Für die Entscheidung sind drei Zugriffsmuster relevant: nur wiederherstellen, wiederherstellen und speichern oder den Cache-Zugriff deaktivieren. Ordnen Sie jedem Job eines davon zu, statt Schreibzugriff als allgemeine Voreinstellung für alle Workflows zu behandeln. Die konkreten Werte und ihre Einordnung sollten Sie gegen die jeweils aktuelle offizielle GitHub-Dokumentation zur Workflow-Syntax prüfen.

Auswahl Geeignet, wenn … Sicherheitsbewertung Nachweis im Lauf
Nur Cache lesen ein Job vorhandene Abhängigkeiten nutzen soll, aber keinen gemeinsamen Cache verändern darf Gute Wahl für Builds aus weniger vertrauenswürdigen Änderungen, sofern der vorhandene Cache für diesen Zweck geeignet ist Der Lauf stellt einen Eintrag wieder her; ein Speicherversuch wird nicht als erfolgreicher Schreibzugriff gewertet
Cache lesen und schreiben ein vertrauenswürdiger Job einen Cache aufbauen oder aktualisieren muss Bedingt geeignet; Schreibzugriff vergrößert die möglichen Folgen eines kompromittierten oder manipulierten Jobs Protokoll und Cache-Verwaltung zeigen, ob ein Eintrag gespeichert wurde
Kein Cache-Zugriff ein Job ohne Cache auskommen muss oder dessen Zugriff nicht ausreichend begründet ist Engste Begrenzung, aber mit möglichen zusätzlichen Download- und Laufzeitkosten Der Lauf verwendet und speichert keinen Cache

Die Bewertung in der Tabelle ist eine Entscheidungshilfe, keine Garantie für vollständige Workflow-Sicherheit. Ein Cache-Eintrag kann außerdem durch Schlüssel, Gültigkeitsbereich und Zugriffskontext beeinflusst werden. GitHub beschreibt in den Sicherheitshinweisen zum Abhängigkeits-Caching, weshalb Cache-Inhalte als sicherheitsrelevante Eingabe zu behandeln sind.

Entscheidungsregel: Wenn ein Job lediglich bestehende Abhängigkeiten nutzen muss, geben Sie ihm Leserechte. Wenn er einen Cache erzeugen oder aktualisieren muss, erlauben Sie Schreiben nur nach Prüfung des Codes und des Auslösers. Wenn Sie den Bedarf nicht belegen können, schalten Sie den Zugriff für diesen Job ab und beobachten Sie, ob der Build weiterhin korrekt funktioniert.

Rechte nach Aufgaben und Vertrauensniveau

Ein Cache-Treffer sagt aus, dass ein passender Eintrag gefunden wurde. Er sagt nicht aus, ob der Job diesen Eintrag hätte schreiben dürfen. Umgekehrt beweist ein erfolgreicher Xcode-Build nicht, dass der Workflow die vorgesehene Berechtigungsgrenze eingehalten hat. Deshalb müssen Sie mindestens drei Ergebnisse getrennt bewerten: Wiederherstellung, Speicherung und Build-Ausgang.

Legen Sie zunächst fest, welche Aufgaben auf den Cache zugreifen. Ein interner Build aus einem vertrauenswürdigen Zweig kann Schreibzugriff benötigen, wenn er einen aktualisierten Abhängigkeitsstand bereitstellt. Ein Prüfjob für Änderungen aus einem weniger vertrauenswürdigen Kontext kann dagegen mit Leserechten auskommen oder ganz ohne Cache laufen. Ein Veröffentlichungsjob sollte nur dann schreiben dürfen, wenn das tatsächlich zu seinem festgelegten Zweck gehört. Die GitHub-Dokumentation zur Cache-Verwaltung hilft Ihnen, vorhandene Einträge und deren Lebenszyklus zu kontrollieren.

Achtung: Ein Job mit Schreibzugriff kann nicht nur Zeit sparen. Je nach Ausführungskontext kann er auch Inhalte beeinflussen, die spätere Jobs wiederherstellen. Prüfen Sie deshalb, wer Code in den Job einbringen kann und welche Jobs den gespeicherten Cache später verwenden.

Soll ein Workflow mit pull_request_target Cache-Schreibrechte erhalten? Nicht ohne eine konkrete Begründung und eine Prüfung der ausgeführten Schritte. Bei diesem Ereignis können Berechtigungen und vertrauenswürdiger Workflow-Code zusammentreffen, während der zu prüfende Pull Request von außen stammt. Wenn der Workflow dort nicht vertrauenswürdigen Code ausführt und zugleich in einen später wiederverwendeten Cache schreiben kann, entsteht ein Risiko für Cache-Poisoning. GitHubs Sicherheitshinweise zu pull_request_target warnen ausdrücklich vor unsicherer Verwendung dieses Ereignisses.

Gehen Sie bei einem solchen Workflow in dieser Reihenfolge vor:

  1. Lesen Sie den Auslöser und bestimmen Sie, ob der Lauf Code aus dem Pull Request ausführt.
  2. Ermitteln Sie, ob der Job Cache-Inhalte nur wiederherstellt oder auch speichern kann.
  3. Entfernen Sie Schreibzugriff, wenn der Job nicht vertrauenswürdigen Code verarbeitet und keine zwingende Schreibaufgabe hat.
  4. Prüfen Sie, ob ein nachgelagerter Build denselben Cache-Bereich wiederverwendet.
  5. Führen Sie den Workflow mit einem repräsentativen Ereignis aus und kontrollieren Sie Protokoll sowie Ergebnis.

Wenn Ihr Workflow aus Sicherheitsgründen keinen Cache verwenden sollte, ist ein langsamerer Lauf gegenüber einem nicht begründeten Schreibzugriff die bessere Abwägung. Halten Sie fest, welche Aufgabe durch die Einschränkung langsamer wird und weshalb die zusätzliche Isolation erforderlich ist.

Vorrang der Job-Einstellung

Eine auf Workflow-Ebene gesetzte Berechtigung kann eine allgemeine Ausgangsregel darstellen. Der konkrete Job benötigt jedoch oft eine engere oder ausdrücklich abweichende Einstellung. GitHub dokumentiert, dass die Einstellung auf Job-Ebene Vorrang vor derjenigen auf Workflow-Ebene hat. Das macht die Konfiguration flexibler, erhöht aber auch das Risiko, dass eine spätere Job-Änderung die beabsichtigte Grenze unbemerkt verändert. Prüfen Sie die Prioritätsregel in der Workflow-Syntax-Referenz, bevor Sie sie als Schutzmaßnahme einsetzen.

Überschreibt cache-mode auf Job-Ebene die Workflow-Einstellung? Ja: Für den betreffenden Job ist die Job-Auswahl maßgeblich. Behandeln Sie die Workflow-Einstellung deshalb nicht als Beleg dafür, dass alle Jobs dieselben Rechte besitzen. Lesen Sie die Werte auf beiden Ebenen und verifizieren Sie anschließend, was der tatsächliche Lauf getan hat.

Als Konfigurationsmuster können Sie zunächst auf Workflow-Ebene eine zurückhaltende Vorgabe setzen und nur für klar begründete Jobs eine abweichende Berechtigung festlegen. Die folgende schematische YAML-Form zeigt die Ebenen; prüfen Sie den zulässigen Schlüssel und die konkrete Schreibweise anhand der aktuellen offiziellen Syntax, bevor Sie sie übernehmen:

# Schematische Struktur: Schlüssel und Werte mit der aktuellen
# GitHub-Workflow-Syntax abgleichen.
cache-mode: read

jobs:
  build:
    cache-mode: read

  trusted-cache-refresh:
    cache-mode: read-write

Vermeiden Sie eine Konfiguration, in der eine sichere Workflow-Vorgabe zwar vorhanden ist, ein einzelner Job aber ohne dokumentierte Begründung Schreibzugriff erhält. Ergänzen Sie die Konfigurationsprüfung um eine Überprüfung des resultierenden Laufs: Ist die Wiederherstellung erfolgt? Wurde ein Speicherzugriff versucht? Wurde ein neuer Cache-Eintrag tatsächlich gespeichert? Diese Fragen beantworten unterschiedliche Teile der Prüfung.

Wiederverwendbare Workflows und Berechtigungsvererbung

Ein aufgerufener Workflow ist kein Weg, die vom aufrufenden Workflow eingeräumte Cache-Berechtigung zu umgehen. Nach GitHubs Regeln kann der wiederverwendbare Workflow keine höheren Berechtigungen erhalten, als der Aufrufer gewährt hat. Trotzdem müssen Sie beide Seiten lesen: Die Einstellung des Aufrufers begrenzt den Rahmen, während eine abweichende Einstellung im aufgerufenen Workflow beeinflussen kann, was innerhalb dieses Rahmens geschieht. Details zur Übergabe und Konfiguration finden Sie in der Dokumentation zu wiederverwendbaren Workflows.

Erbt ein wiederverwendbarer Workflow die Cache-Rechte des Aufrufers? Der Aufrufer setzt die Obergrenze: Der wiederverwendbare Workflow kann nicht mehr Cache-Berechtigung erhalten, als ihm von dort eingeräumt wird. Prüfen Sie dennoch die Konfiguration des aufgerufenen Workflows und die tatsächlichen Laufprotokolle. Eine dokumentierte Grenze ersetzt nicht die Prüfung, ob der aufgerufene Workflow innerhalb dieser Grenze unnötig weitreichend konfiguriert ist.

Für die Abnahme halten Sie pro aufrufendem Workflow und wiederverwendbarem Workflow fest:

  • Welche Cache-Berechtigung der Aufrufer einräumt.
  • Welche Einstellung der aufgerufene Workflow verwendet.
  • Welche Jobs tatsächlich wiederherstellen oder speichern.
  • Ob ein Aufruf aus einem weniger vertrauenswürdigen Kontext möglich ist.
  • Welcher Testlauf belegt, dass keine höhere Berechtigung entsteht.

Hinweis: Cache-Rechte sind nur ein Teil der Absicherung. Prüfen Sie daneben Token-Berechtigungen, verwendete Actions, Geheimnisse und die Ausführung nicht vertrauenswürdigen Codes. GitHubs Leitfaden zur sicheren Verwendung von Actions behandelt diese weiteren Schutzbereiche.

Nachweis im Protokoll und Bewertung

Legen Sie für jeden Test fest, welche Beobachtung als bestanden gilt. Ein Cache-Treffer allein reicht nicht: Er kann bei einer unpassenden Rechtevergabe trotzdem auftreten. Ebenso ist ein fehlender Treffer kein Beweis, dass Schreibzugriff verhindert wurde. Entscheidend sind die konkrete Konfiguration und die Ausgaben für Wiederherstellung und Speicherung.

Verwenden Sie für die Prüfung eine getrennte Bewertung:

  • Wiederherstellung: Hat der Job einen passenden Cache gesucht und gegebenenfalls wiederhergestellt?
  • Speicherung: Hat er versucht, einen Cache-Eintrag anzulegen oder zu aktualisieren, und war das gemäß seiner Berechtigung möglich?
  • Build: War der Xcode-Build erfolgreich, unabhängig davon, ob der Cache getroffen wurde?
  • Berechtigungsnachweis: Stimmen Workflow- und Job-Einstellungen mit der beabsichtigten Freigabe überein?
  • Risikobehandlung: Sind Auslöser mit geringerem Vertrauen ohne unnötige Schreibrechte konfiguriert?

Bewerten Sie eine Regel als bestanden, wenn Konfiguration, erwartete Berechtigung und beobachteter Lauf zusammenpassen. Markieren Sie sie als nicht bestanden, wenn ein Job trotz fehlender Begründung speichern kann oder wenn die Protokolle die erwartete Wirkung nicht erkennen lassen. Ist die Ausgabe uneindeutig, geben Sie den Workflow nicht aufgrund eines erfolgreichen Builds frei: Reduzieren Sie die Rechte vorläufig und wiederholen Sie die Prüfung mit einem kontrollierten Test.

Es gibt hier bewusst keine allgemeingültige Aussage zur Cache-Trefferquote oder zur eingesparten Build-Zeit. Solche Werte hängen unter anderem von Abhängigkeiten, Schlüsselgestaltung, Runner-Zustand und Workflow-Auslösern ab. Für eine belastbare Kosten- oder Laufzeitentscheidung brauchen Sie Ihre eigenen Protokolle unter dokumentierten Testbedingungen; ein nicht vorhandener Messwert sollte nicht durch eine Schätzung ersetzt werden.

Rollout und Audit über mehrere Repositories

Führen Sie die Regel zuerst in einem repräsentativen Repository ein, bevor Sie sie organisationsweit übernehmen. Wählen Sie dafür einen Workflow mit typischen internen Builds und mindestens einem relevanten weniger vertrauenswürdigen Auslöser. Dokumentieren Sie, welche Cache-Aufgabe jeder Job erfüllen soll und wodurch die Berechtigung begründet ist.

Ein belastbarer Rollout umfasst folgende Schritte:

  1. Erfassen Sie alle Workflow-Auslöser, Jobs und wiederverwendbaren Workflows, die Cache-Funktionen nutzen.
  2. Ordnen Sie jedem Job eine erforderliche Zugriffsstufe zu: wiederherstellen, speichern oder kein Zugriff.
  3. Setzen Sie Workflow- und Job-Einstellungen so, dass Ausnahmen sichtbar begründet sind.
  4. Testen Sie vertrauenswürdige und weniger vertrauenswürdige Auslöser getrennt.
  5. Vergleichen Sie die erwarteten Berechtigungen mit Wiederherstellungs-, Speicher- und Build-Protokollen.
  6. Halten Sie Rücknahmeweg, verantwortliches Team und Prüfbelege fest.
  7. Übertragen Sie die Regel erst nach erfolgreicher Abnahme auf weitere Repositories und kontrollieren Sie sie nach Änderungen erneut.

Diese Prüfnotizen sollten die Repository-Verantwortlichen auch über Teamwechsel hinweg verstehen können. Legen Sie deshalb nicht nur den gewählten Modus ab, sondern auch den Zweck, die getesteten Ereignisse und die erwartete Reaktion bei einem Fehlschlag. Bei personenbezogenen Daten in Protokollen oder Testartefakten sollten Sie außerdem die internen Aufbewahrungsregeln prüfen; Hinweise dazu finden Sie in der Datenschutzerklärung. Fragen zur Nutzung der SSHMac-Umgebung können Sie im Hilfezentrum klären.

Letzte Aktualisierung: 28.09.2026. Geprüft anhand der GitHub-Ankündigung zu cache-mode, der offiziellen Workflow-Syntax und der GitHub-Sicherheitsdokumentation. Änderungen an Syntax oder Standardregeln sollten vor einer Übernahme erneut geprüft werden.

Nach der Cache-Prüfung bleiben in einer Mac-CI-Umgebung weitere mögliche Schwachstellen: Ein lokaler Mac kann durch gemeinsam genutzte Nutzung oder manuelle Änderungen schwer reproduzierbar sein; ein allgemeiner Cloud-Rechner stellt nicht automatisch die benötigte macOS- und Xcode-Umgebung bereit; und ohne klare Ablage- und Aufbewahrungsregeln können Build-Artefakte außerhalb der Cache-Prüfung unkontrolliert bestehen bleiben. Wenn Sie nur für einen zeitlich begrenzten Test, eine Release-Prüfung oder die Einführung einer neuen Berechtigungsregel eine Mac-Umgebung benötigen, kann das Mieten eines Mac über SSHMac gegenüber der kurzfristigen Beschaffung eigener Hardware einfacher planbar sein. Für dauerhaft laufende, gleichbleibend hohe Last oder zwingend benötigte physische Schnittstellen ist ein eigener Mac dagegen möglicherweise geeigneter. Informieren Sie sich über die Mac-Umgebung von SSHMac, bevor Sie Ihre CI-Testumgebung festlegen.