Ein Pull Request läuft auf Ihrem Mac-Runner – und Sie wissen nicht, ob dort noch Dateien, Tokens oder Schlüssel aus einem früheren Job liegen.

Schnellentscheidung: Nutzen Sie einen kontrollierten, dauerhaften Mac nur für Jobs aus vertrauenswürdigen privaten Repositorys, wenn Sie den Runner-Zugriff begrenzen und den Zustand nach jedem Lauf prüfen. Für fremden Code oder Jobs mit weitreichenden Signiergeheimnissen ist eine isolierte, kurzlebige Umgebung die bessere Wahl. Das Leeren des Arbeitsverzeichnisses allein schafft keine Sicherheitsisolation.

Diese Woche: Prüfen Sie zuerst, welche Workflows Ihren selbst gehosteten Runner erreichen und welche Secrets ihre Jobs erhalten. Trennen Sie danach gewöhnliche Builds von Signier- und Veröffentlichungsjobs.

Dieser Beitrag richtet sich an unabhängige iOS- und macOS-Entwickler, die zwischen Wiederverwendung und Wartungsaufwand abwägen.
Kleine Teams finden Kriterien, um tägliche Builds und Veröffentlichungen mit unterschiedlichen Berechtigungen auszuführen.
Verantwortliche für Release-Automatisierung können damit die Risiken durch Schlüssel und zurückbleibende Zustände auf einem dauerhaften Host prüfen.

01

GitHub Actions macOS Runner: dauerhaft oder temporär?

Die passende Wahl richtet sich nicht zuerst nach der Build-Dauer, sondern nach dem Code, der auf dem Runner ausgeführt wird, und den Berechtigungen, die dieser Job erhält. Ein dauerhafter Host kann für eng begrenzte, vertrauenswürdige Aufgaben passen. Sobald externe Beiträge oder weitreichende Zugangsdaten ins Spiel kommen, sollten Sie die Umgebung stärker isolieren oder den betreffenden Workflow dort gar nicht ausführen.

Einsatzfall Dauerhafter Mac Isolierte, kurzlebige Umgebung Entscheidung
Vertrauenswürdige Änderungen aus einem privaten Repository Einfacher wiederzuverwenden; Host und Arbeitsverzeichnisse müssen überwacht und bereinigt werden Mehr Einrichtungs- und Wiederherstellungsaufwand; Zustände lassen sich nach einem Lauf verwerfen Dauerhaft ist vertretbar, wenn Zugriff, Secrets und Hostzustand begrenzt und überprüft sind
Pull Request aus einem Fork oder mit nicht geprüftem Code Risiko, dass der Job den Runner oder erreichbare Zugangsdaten beeinflusst Begrenzterer Lebenszyklus, sofern die Umgebung tatsächlich neu erstellt und nach dem Job entfernt wird Nicht auf einem dauerhaft verwendeten Host ausführen
Signieren und Veröffentlichen Schlüssel und Keychain können ein dauerhaftes Angriffsziel werden Besser trennbar, wenn Zugangsdaten nur im geschützten Release-Job bereitgestellt werden Veröffentlichung als eigenen, stark beschränkten Ablauf gestalten
Fehlerdiagnose und Wiederholung Lokale Zustände können die Suche erleichtern, aber auch alte Dateien verbergen Flüchtige Umgebung erschwert die spätere Analyse, wenn Protokolle nicht separat gesichert werden Protokolle und Ergebnisse getrennt sichern; daraus keine Sicherheitsgarantie ableiten

Die Tabelle ist keine Aussage, dass eine Variante grundsätzlich sicher sei. Ein kurzlebiger Runner hilft nur, wenn der Host tatsächlich für den Auftrag bereitgestellt und danach zuverlässig entfernt wird. Ein dauerhaft erreichbarer Mac wird nicht dadurch isoliert, dass ein Workflow ein Arbeitsverzeichnis löscht.

02

Vertrauenswürdige Builds auf einem dauerhaften Mac begrenzen

Für ein privates Repository, in dem nur überprüfte Teammitglieder Änderungen einreichen, kann ein dauerhafter GitHub Actions selbst-hosted Runner eine wartbare Lösung sein. Er kann wiederkehrende Aufgaben für iOS- oder macOS-Builds übernehmen. GitHub weist zugleich auf die Risiken selbst gehosteter Runner hin: Ein ausgeführter Job kann auf die Umgebung des Hosts einwirken. Prüfen Sie deshalb die Sicherheitsanforderungen für selbst gehostete Runner, bevor Sie solche Jobs für nicht vertrauenswürdigen Code freigeben.

Wichtig ist die Trennung zweier Eigenschaften:

  • Der Runner-Prozess bleibt online. Das bedeutet, dass der Host für passende Jobs erreichbar ist.
  • Der Zustand nach einem Job ist eine eigene Frage. Arbeitsverzeichnis, temporäre Dateien, Caches, installierte Werkzeuge, Schlüsselbund und Protokolle müssen Sie jeweils separat prüfen.

Verwechseln Sie einen grünen Jobstatus also nicht mit einem nachweislich sauberen Host. Sehen Sie sich die Runner-Protokolle und das Arbeitsverzeichnis nach einem repräsentativen Lauf an. Kontrollieren Sie außerdem, ob zusätzliche Skripte außerhalb des Checkout-Verzeichnisses Dateien ablegen. GitHub dokumentiert die Anforderungen und den Betrieb in seiner Referenz zu selbst gehosteten Runnern.

Für dauerhafte Hosts empfiehlt sich eine enge Zugriffskontrolle. Beschränken Sie die Runner-Gruppe auf das benötigte Repository und erlauben Sie nicht automatisch allen Workflows oder Organisationsteams die Nutzung. GitHub beschreibt, wie sich der Zugriff über Runner-Gruppen und deren Berechtigungen steuern lässt. Die verfügbaren Gruppen und die tatsächliche Freigabe sollten Sie mit der Konfiguration Ihres Repositorys abgleichen.

Ein wiederverwendbarer Mac kann mehrere Jobs nacheinander übernehmen. Planen Sie denselben Runner jedoch nicht als parallele Ausführungseinheit ein: Laut Runner-Referenz von GitHub führt ein Runner jeweils einen Job aus. Benötigen Sie parallele Builds, brauchen Sie dafür zusätzliche Runner oder eine andere Ausführungsplanung. Diese Kapazitätsfrage ersetzt aber nicht die Sicherheitsentscheidung: Mehr Runner machen nicht vertrauenswürdigen Code nicht automatisch unbedenklich.

03

Pull Requests nach Herkunft und Workflow-Ereignis trennen

Bei einem Pull Request aus einem vertrauenswürdigen Teamzweig ist die Ausgangslage eine andere als bei einem Beitrag aus einem Fork. Prüfen Sie nicht nur, ob der Code „im selben Repository“ erscheint. Entscheidend sind das auslösende Ereignis, die ausgecheckte Revision, die Berechtigungen des Jobs und die Secrets, auf die er zugreifen kann.

Können externe Pull Requests auf einem selbst gehosteten Mac laufen?

Ein externer Beitrag sollte nicht einfach denselben dauerhaft verwendeten Mac erreichen wie ein vertrauenswürdiger Release-Build. Der Job führt Projektcode und möglicherweise Build-Skripte aus. Dieser Code kann versuchen, auf verfügbare Dateien oder Zugangsdaten einzuwirken. GitHub warnt ausdrücklich vor der Ausführung nicht vertrauenswürdiger Pull-Request-Inhalte auf selbst gehosteten Runnern. Lesen Sie dazu die Dokumentation zur Sicherheit bei Pull Requests und Workflow-Ereignissen.

Vergleichen Sie in Ihrer Workflow-Datei zunächst das Ereignis pull_request mit pull_request_target. Bei pull_request_target kann der Workflow in einem privilegierten Kontext ausgeführt werden. Das macht es besonders riskant, ungeprüften Pull-Request-Code auszuchecken und auszuführen. GitHub erläutert die Gefahren und Schutzmaßnahmen in der Anleitung zu pull_request_target. Verwenden Sie dieses Ereignis nicht als bequemen Weg, einem externen Beitrag Zugriff auf den produktiven Runner oder dessen Secrets zu geben.

Prüfen Sie anschließend die Runner-Gruppe und ihre Repository-Freigaben. Eine Beschränkung auf einen Runner-Label-Namen ist nicht dasselbe wie eine Zugriffskontrolle: Labels helfen bei der Auswahl eines passenden Runners, sie begrenzen nicht automatisch, welche Workflows ihn verwenden dürfen. Die Dokumentation zu Runner-Gruppen erklärt, wie Gruppen als Zugriffsebene eingesetzt werden.

Begrenzen Sie außerdem die Token-Berechtigungen ausdrücklich. Die Workflow-Syntax erlaubt es, die Berechtigungen eines Jobs über permissions festzulegen; wo keine Schreibrechte benötigt werden, sollten sie nicht beiläufig gewährt werden. Die möglichen Einstellungen und ihre Wirkung finden Sie in der Referenz zur Workflow-Syntax. Kontrollieren Sie im konkreten Workflow auch, ob ein Schritt ein Secret als Umgebungsvariable erhält oder es an ein Skript weiterreicht.

04

Signierung und Veröffentlichung von alltäglichen Builds abkoppeln

Für einen gewöhnlichen Test-Build brauchen Sie nicht zwingend dieselben Berechtigungen wie für das Signieren und Hochladen einer App. Behandeln Sie die Jobs deshalb als getrennte Vertrauensbereiche. Ein Build, der nicht veröffentlicht, sollte keine Signierschlüssel, App-Store-Zugangsdaten oder langlebigen Tokens erhalten, die für einen Release nicht nötig sind.

Gehören iOS-Signierschlüssel auf einen dauerhaften Runner?

Nicht automatisch. Ein dauerhaft verwendeter Mac kann für eng kontrollierte Release-Jobs geeignet sein, aber die Bequemlichkeit eines vorhandenen Schlüsselbunds ist kein ausreichender Grund, Schlüssel allen Workflows zugänglich zu machen. Legen Sie fest, welcher Workflow den Signierschlüssel erhält, durch welches Ereignis er startet und wer die Ausführung freigeben darf.

Prüfen Sie dazu drei Ebenen:

  • Zugangsdaten: Welche Secrets werden dem Job tatsächlich übergeben? Können Build-Skripte oder Aktionen sie ausgeben oder an andere Prozesse weiterreichen?
  • Schlüsselbund: Wird die Signieridentität nur für den benötigten Schritt entsperrt? Bleibt sie nach einem fehlgeschlagenen oder abgebrochenen Job verfügbar?
  • Auslöser und Berechtigungen: Kann ein Pull Request den Release-Job erreichen, oder ist dieser auf einen kontrollierten Veröffentlichungsweg beschränkt?

Ein Schlüsselbund auf einem Mac ersetzt keine Berechtigungsprüfung. Ebenso ist eine Berechtigungseinstellung im Workflow kein Nachweis dafür, dass ein früherer Job alle lokalen Dateien oder Prozesse entfernt hat. Dokumentieren Sie deshalb, welche Jobs Zugangsdaten erhalten, und prüfen Sie diese Liste gemeinsam mit den Workflow-Dateien. Bei einer dauerhaften Maschine sollten Sie zusätzlich die Runner-Gruppe auf die dafür vorgesehenen Repositorys und Aufgaben begrenzen.

Für die Trennung von Signierung und täglichem CI-Build zählt auch die Nachvollziehbarkeit. Bewahren Sie den Workflow-Lauf, die Job-Ergebnisse und die Freigabe für den Release auf. In Diagnoseprotokollen dürfen keine privaten Schlüssel, Tokens oder Signiergeheimnisse landen. Das ist gerade für Teams wichtig, die personenbezogene oder vertrauliche Projektdaten verarbeiten: Beschränken Sie den Zugriff auf Protokolle und prüfen Sie, welche Daten Sie speichern müssen.

05

Bereinigung ist kein Ersatz für Isolation

Ein Job sollte keine unnötigen Zustände an den nächsten Job weitergeben. Trotzdem beweist eine Bereinigung nach dem Job nicht, dass ein zuvor ausgeführter fremder Code keine anderen Veränderungen vorgenommen hat. Er kann außerhalb des erwarteten Arbeitsverzeichnisses arbeiten oder Prozesse und Konfigurationen beeinflussen. Deshalb ist „Verzeichnis gelöscht“ kein belastbarer Sicherheitsnachweis.

Was muss nach jedem Job geprüft und bereinigt werden?

Beginnen Sie mit dem tatsächlichen Ablauf Ihrer Workflows und prüfen Sie danach mindestens diese Bereiche:

  • Checkout- und Build-Verzeichnisse einschließlich projektbezogener Zwischendateien.
  • Temporäre Dateien und selbst angelegte Ablageorte außerhalb des Checkout-Pfads.
  • GitHub-Tokens, Umgebungsvariablen und sonstige Zugangsdaten, die während des Jobs verfügbar waren.
  • Schlüsselbundzustand und Signiermaterial, soweit der Job damit gearbeitet hat.
  • Prozesse, lokale Konfigurationen und Caches, deren Inhalt zwischen Aufgaben weiterverwendet werden könnte.
  • Protokolle und Testergebnisse: Speichern Sie sie so, dass Fehler analysierbar bleiben, aber Secrets und vertrauliche Daten nicht offengelegt werden.

Diese Liste ist ein Prüfrahmen, keine Garantie, die sich durch das Abhaken einzelner Dateien herstellen lässt. Für nicht vertrauenswürdigen Code sollten Sie statt einer bloßen Nachreinigung eine Umgebung wählen, die nach dem Auftrag verworfen wird, oder den Job auf diesem Runner nicht ausführen. GitHub behandelt kurzlebige Runner als Ansatz, um die Risiken persistenter selbst gehosteter Umgebungen zu reduzieren. Ob Ihre konkrete Umsetzung den Host tatsächlich zurücksetzt und entfernt, müssen Sie selbst verifizieren.

Auch kurzfristige Umgebungen benötigen eine Diagnoseplanung. Ein Runner, der nach einem Job verschwindet, bewahrt seine lokalen Protokolle nicht automatisch für eine spätere Untersuchung. Sichern Sie daher erforderliche Job-Ausgaben und Statusinformationen außerhalb des Hosts. Achten Sie beim Export darauf, dass Protokolle keine Tokens oder privaten Signierdaten enthalten. Für die Fehlersuche bietet GitHub Hinweise zu Überwachung und Fehlerbehebung bei selbst gehosteten Runnern.

06

So prüfen Sie die Wahl vor dem nächsten Release

Führen Sie die folgenden Schritte an einem repräsentativen Workflow durch, bevor Sie den Runner für die Veröffentlichung freigeben:

  1. Workflows und Auslöser erfassen. Notieren Sie für jeden Job, ob er durch einen Push, einen Pull Request, einen manuellen Aufruf oder einen Release gestartet wird. Gleichen Sie diese Ereignisse mit der offiziellen Übersicht zu Workflow-Auslösern ab.

  2. Codeherkunft festhalten. Markieren Sie, welche Jobs ausschließlich geprüfte Änderungen aus dem privaten Repository verarbeiten und welche Beiträge aus Forks oder anderen nicht vertrauenswürdigen Quellen berücksichtigen könnten.

  3. Runner-Zugriff kontrollieren. Prüfen Sie, welche Repositorys eine Runner-Gruppe nutzen dürfen und welche Workflows die passende Gruppe beziehungsweise das passende Label anfordern. Entfernen Sie Freigaben, die der Job nicht benötigt.

  4. Job-Berechtigungen reduzieren. Lesen Sie die permissions-Einstellungen und die Übergabe von Secrets Schritt für Schritt durch. Wenn ein Job weder schreiben noch signieren muss, sollte seine Konfiguration diese Aufgaben nicht unnötig ermöglichen.

  5. Einen repräsentativen Lauf beobachten. Führen Sie einen Build mit demselben Workflow-Typ aus, den Sie später dauerhaft betreiben möchten. Prüfen Sie Runner-Protokolle, Arbeitsverzeichnis und den Umgang mit temporären Dateien. Verlassen Sie sich nicht allein auf den Abschlussstatus des Jobs.

  6. Zustand nach dem Lauf nachvollziehen. Kontrollieren Sie, was der nächste Job auf dem Host vorfindet. Prüfen Sie zusätzlich, ob der vorherige Workflow Prozesse, Schlüsselbundzustände oder Dateien außerhalb des erwarteten Arbeitsbereichs hinterlassen kann.

  7. Fehlerfall und Entfernung testen. Simulieren Sie einen abgebrochenen oder fehlerhaften Lauf und klären Sie, wer den Runner wieder in einen vertrauenswürdigen Zustand versetzt. Wenn Sie eine kurzlebige Instanz verwenden, prüfen Sie, ob sie nach dem Job wirklich deregistriert und entfernt wird. GitHub beschreibt die Schritte zum Entfernen selbst gehosteter Runner.

  8. Belege getrennt sichern. Bewahren Sie Job-Ergebnis, bereinigte Diagnoseausgaben und Ihre Freigabeentscheidung so auf, dass Sie einen späteren Fehler untersuchen können. Protokollieren Sie keine privaten Schlüssel oder Tokens.

Diese Prüfung beantwortet auch die Frage nach wiederholter Nutzung: Ein dauerhafter Runner kann weitere Jobs nacheinander übernehmen. Wiederverwendung ist aber nur dann sinnvoll, wenn Sie den Zustand zwischen Jobs prüfen und den Zugriff auf die betreffenden Workflows begrenzen. Bei fremdem Code genügt es nicht, den Checkout-Ordner nach jedem Lauf zu leeren.

07

Remote Mac und Runner-Isolation getrennt bewerten

Wenn Ihr aktueller Build auf einem gemeinsam genutzten Büro-Mac läuft, entstehen oft drei konkrete Nachteile: Die Verfügbarkeit hängt von diesem Rechner ab, lokale Entwicklungs- und CI-Zustände vermischen sich, und Fehlersuche oder Schlüsselpflege fallen auf dieselbe Maschine zurück. Ein dedizierter Remote Mac kann diese Aufgaben organisatorisch von Ihrem Arbeitsplatz trennen. Er sorgt jedoch nicht von selbst dafür, dass Runner-Jobs isoliert, einmalig oder frei von zurückbleibenden Zugangsdaten sind.

Bewerten Sie deshalb zwei Entscheidungen getrennt: Erstens, wo der Mac steht und wie Sie darauf zugreifen; zweitens, welche Workflows ihn verwenden dürfen und wie dessen Zustand nach einem Job behandelt wird. Prüfen Sie vor einer Umstellung, ob die gewünschte Konfiguration und der vorgesehene Zugangsweg zu Ihrem Workflow passen. Eine Übersicht zu verfügbaren Remote-Mac-Optionen finden Sie bei VpsMesh; Angaben zu Konfigurationen und Mietbedingungen sollten Sie vor Ihrer Entscheidung direkt gegen Ihren Bedarf prüfen.

Wenn Sie nur gelegentlich einen zusätzlichen macOS-Build oder eine getrennte Release-Umgebung benötigen, kann das Mieten eines Remote Mac flexibler sein als ein weiterer dauerhaft im Büro betriebener Rechner. Für einen langfristig ausgelasteten Runner oder Aufgaben, die lokale Anschlüsse und unmittelbaren physischen Zugriff brauchen, kann ein eigener Mac die passendere Wahl bleiben. In beiden Fällen müssen Sie Runner-Gruppen, Workflow-Berechtigungen, Secrets und Bereinigung selbst festlegen: Die Hardwarewahl ersetzt keine Sicherheitsgrenze.