Ist ein selbst gehosteter Mac-Runner für GitHub Actions sicher? Abnahmeliste 2026

Ein PR-Build läuft auf demselben Mac wie Ihre Veröffentlichungsaufgabe, und Sie wissen nicht, welche Geheimnisse er erreichen kann.

Schnellste Lösung: Verwenden Sie einen selbst gehosteten Mac-Runner für iOS-Builds nur, wenn Sie nicht vertrauenswürdige PRs, Runner- und Token-Rechte sowie Signaturschlüssel voneinander trennen und die Bereinigung nach jedem Auftrag nachweisen können. Private Repositories oder eine Umgebungsfreigabe sind allein kein Sicherheitsnachweis. Können Sie Codeprüfung und signierte Veröffentlichung nicht isolieren, darf dieser Runner keine produktiven Veröffentlichungsgeheimnisse erhalten.

Für unabhängige Entwickler, die GitHub Actions mit einem selbst gehosteten Mac verbinden möchten, bietet diese Abnahmeliste konkrete Prüfpunkte für Auslöser und Runner-Zugriff.
Kleine Teams mit Signatur- und Veröffentlichungsgeheimnissen können damit deren Zugriffsbereich kontrollieren.
Verantwortliche für mehrere Repositories sehen, ob eine gemeinsam genutzte Maschine für produktive Aufgaben vertretbar ist.

Die Freigabe hängt von fünf getrennten Vertrauensgrenzen ab

„Mac“ beschreibt das Betriebssystem und die Hardware, nicht den Sicherheitszustand einer CI-Umgebung. Entscheidend ist, wer Code ausführen lassen kann, welche Berechtigungen der Workflow besitzt, welche Runner der Auftrag erreicht und ob private Schlüssel während der Aufgabe verfügbar sind. GitHub weist darauf hin, dass selbst gehostete Runner durch nicht vertrauenswürdigen Workflow-Code gefährdet werden können; die Sicherheitsempfehlungen für GitHub Actions sind deshalb der Ausgangspunkt, nicht die Annahme, ein eigener Rechner sei automatisch sicher.

Bewerten Sie diese Grenzen getrennt:

• Codevertrauen: Wer darf Änderungen einreichen, und welcher Commit wird tatsächlich ausgeführt?
• Workflowvertrauen: Wer darf den Workflow verändern oder auslösen, und mit welchen Token-Rechten läuft er?
• Hostisolation: Kann ein Auftrag Daten, Schlüsselbundzustände oder Dateien eines vorherigen Auftrags erreichen?
• Signaturschutz: Welche Veröffentlichungsaufgabe kann Zertifikat und privaten Schlüssel verwenden?
• Runner-Zugriff: Welche Repositories, Teams und Workflows dürfen die Maschine auswählen?

Ein grüner Build beantwortet keine dieser Fragen. Er belegt zunächst nur, dass ein Auftrag unter den aktuellen Bedingungen erfolgreich beendet wurde. Für die Freigabe müssen Sie die Konfiguration und die tatsächliche Ausführung nachvollziehbar prüfen.

Nicht vertrauenswürdige Pull Requests ohne Veröffentlichungszugriff

Öffentliche Pull Requests können sinnvolle Build- und Testaufgaben auslösen. Der sichere Ansatz besteht jedoch nicht darin, PR-Code auf einem produktiven Runner laufen zu lassen und darauf zu hoffen, dass Geheimnisse verborgen bleiben. Legen Sie einen Prüfpfad fest, in dem fremde Änderungen weder Signaturschlüssel noch App-Store-Zugangsdaten oder einen Runner mit Zugriff auf solche Daten erreichen.

Prüfen Sie dazu den Auslöser und den ausgeführten Quellstand gemeinsam. Die Übersicht der GitHub-Workflow-Ereignisse unterscheidet die Ereignisse, die einen Workflow starten. Ein Ereignisname allein genügt aber nicht als Sicherheitsprüfung: Sie müssen auch feststellen, welcher Commit ausgecheckt wird, welche Berechtigungen angewendet werden und ob der Auftrag an eine Maschine mit Veröffentlichungszugriff gelangt.

Besondere Aufmerksamkeit verlangt pull_request_target. GitHub beschreibt in der Anleitung zur sicheren Verwendung von pull_request_target, dass dieser Auslöser mit erhöhten Berechtigungen und Zugriff auf Geheimnisse verbunden sein kann. Wird damit nicht vertrauenswürdiger PR-Code ausgeführt oder ausgecheckt, kann aus einer Prüfaufgabe ein Weg zu privilegiertem Zugriff werden. Verwenden Sie diesen Auslöser daher nicht als bequemen Ersatz für eine getrennte PR-Validierung.

Auch ein privates Repository ist kein pauschaler Sicherheitsbeleg. Prüfen Sie, wer Schreibrechte besitzt und ob diese Personen Änderungen an Workflows vornehmen können. Ebenso wenig ersetzt eine Freigabe in einer GitHub-Umgebung die Trennung: Sie kann einen Schritt kontrollieren, beweist aber nicht, dass ein anderer Workflow, ein anderes Ereignis oder ein anderer Codepfad keine Geheimnisse erreicht.

Prüfpunkt: Wenn ein PR-Auftrag auf demselben dauerhaft verfügbaren Host wie eine signierte Veröffentlichung läuft, müssen Sie belegen, dass weder Schlüssel noch vertrauliche Rückstände erreichbar sind. Fehlt dieser Nachweis, gehört der PR-Auftrag auf einen getrennten Runner ohne Veröffentlichungsgeheimnisse.

Vertrauenswürdige Builds mit eng begrenzten Rechten

Auch ein Build aus einem vertrauenswürdigen Branch benötigt nur die Rechte, die seine konkreten Schritte verlangen. Prüfen Sie die permissions-Angaben im Workflow und vergleichen Sie sie mit den Tätigkeiten des Auftrags: Quellcode lesen, Status melden, Artefakte hochladen oder eine Veröffentlichung anstoßen. Die Dokumentation zur Workflow-Syntax und zu Berechtigungen erläutert, wie Sie die Rechte des GITHUB_TOKEN festlegen. Lassen Sie nicht mehr Berechtigungen bestehen, nur weil ein breiteres Set einen bestehenden Workflow bequem am Laufen hält.

Kontrollieren Sie außerdem die verwendeten Actions. Stellen Sie fest, aus welcher Quelle sie stammen, ob der Workflow die erwartete Version aufruft und ob Änderungen an diesen Abhängigkeiten geprüft werden. Ein Drittanbieter-Schritt wird Teil Ihrer Vertrauenskette, sobald er im Auftrag ausgeführt wird. Halten Sie daher fest, welche Actions auf signaturfähigen Runnern laufen und ob deren Wartung und Versionsfestlegung zu Ihrer Risikoeinschätzung passen.

Prüfen Sie parallel, wer die Maschine tatsächlich einplanen kann. GitHub beschreibt in seiner Dokumentation zur Runner-Zugriffsverwaltung die Steuerung des Zugriffs auf selbst gehostete Runner. Vergleichen Sie die dort eingerichteten Repository- und Gruppenrechte mit Ihren tatsächlichen Release-Workflows. Ein enger Token schützt nicht, wenn ein nicht zuständiges Repository dennoch einen Auftrag auf einem Host mit lokal verfügbaren Schlüsseln starten darf.

Für eine belastbare iOS-CI-Sicherheit dokumentieren Sie deshalb mindestens zwei getrennte Belege: die im Workflow sichtbaren Token- und Action-Rechte sowie die in GitHub gesetzten Runner-Zugriffsregeln. „Build erfolgreich“ ist kein Ersatz für beides.

Signaturaufgaben und private Schlüssel

Eine iOS-Veröffentlichung braucht oft Zugriff auf Signaturmaterial, eine normale Kompilierung dagegen nicht zwingend. Trennen Sie Aufgaben, statt dieselben Geheimnisse jeder Build-Stufe bereitzustellen. Erfassen Sie Zertifikat, zugehörigen privaten Schlüssel und App-Store-Zugangsdaten einzeln: Welcher Workflow verwendet jedes Element, in welchem Schritt und mit welcher Reichweite?

Apple erläutert, dass eine Signieridentität aus dem Zertifikat und dem dazugehörigen privaten Schlüssel besteht. Maßgeblich ist Apples Dokumentation zum Teilen von Signaturzertifikaten im Team. Daraus folgt für die Runner-Abnahme: Ein öffentliches Zertifikat allein ist nicht gleichbedeutend mit dem vollständigen Schutz der Identität. Der private Schlüssel ist besonders zu schützen, und der Zugriff darauf gehört in den engsten notwendigen Veröffentlichungsablauf.

Prüfen Sie nicht nur die Speicherung, sondern auch den gesamten Lebenszyklus während und nach der Aufgabe:

• Wird ein Schlüsselbund für den Auftrag geöffnet, und wird er danach wieder geschlossen oder entfernt?
• Können Diagnoseausgaben, Shell-Traces oder Fehlerprotokolle vertrauliche Werte enthalten?
• Werden temporäre Dateien oder Exportdateien im Arbeitsverzeichnis hinterlassen?
• Können hochgeladene Artefakte oder fehlgeschlagene Build-Ausgaben private Informationen enthalten?
• Welche Personen dürfen den Workflow ändern, der die Geheimnisse abruft?

Protokollieren Sie keine echten Schlüssel, Token oder wiederverwendbaren Geheimniswerte in einem Abnahmebericht. Halten Sie stattdessen den Speicherort, den Zugriffspfad, die zuständige Aufgabe und die geprüfte Bereinigung fest. Wenn Sie keine klare Antwort geben können, sollte die betroffene Veröffentlichungsaufgabe nicht auf einen Runner mit allgemeinen PR- oder Testaufträgen gelegt werden.

FAQ zur Runner-Sicherheit

Kann ein selbst gehosteter Mac-Runner Pull Requests aus öffentlichen Repositories testen?
Ja, wenn Sie den Testpfad von Veröffentlichungsgeheimnissen und privilegierten Runnern trennen. Prüfen Sie Auslöser, ausgecheckten Commit, Token-Rechte und Hostzugriff gemeinsam. Lassen Sie nicht vertrauenswürdigen Code nicht auf einer Maschine laufen, deren lokaler Zustand oder Schlüsselbund für einen späteren Release-Auftrag verfügbar bleibt. Eine Freigabe in einer Umgebung ist dafür kein ausreichender Nachweis.

Sollten Zertifikat und privater Schlüssel für die iOS-Signierung auf dem Runner liegen?
Nur wenn ein bestimmter Veröffentlichungsauftrag sie tatsächlich benötigt. Zertifikat und zugehöriger privater Schlüssel bilden gemeinsam die Signieridentität; schützen Sie daher beide und begrenzen Sie ihre Verfügbarkeit auf diesen Auftrag. Untersuchen Sie zusätzlich Protokolle, temporäre Dateien und fehlgeschlagene Artefakte, damit Geheimnisse nicht außerhalb des vorgesehenen Zugriffspfads landen.

Ist es sicher, mehrere GitHub-Actions-Workflows auf einem Mac-Runner auszuführen?
Nicht automatisch. Wenn Workflows verschiedene Vertrauensstufen, Repositories oder Geheimnisse haben, kann die gemeinsame Maschine eine unerwünschte Verbindung zwischen ihnen schaffen. Vergleichen Sie Runner-Rechte, Workflow-Berechtigungen und den Hostzustand nach einem Auftrag. Können Sie eine Trennung oder Bereinigung nicht belegen, reduzieren Sie den gemeinsamen Zugriff oder teilen Sie die Aufgaben auf.

Wie prüfen Sie, ob nach einem Auftrag Geheimnisse auf dem Mac-Runner zurückbleiben?
Führen Sie eine nachvollziehbare Prüfung nach repräsentativen erfolgreichen und fehlgeschlagenen Aufgaben durch. Kontrollieren Sie Arbeitsbereich, Schlüsselbund, temporäre Daten, Artefakte und Protokolle und dokumentieren Sie, was tatsächlich entfernt wird. Ein entferntes Runner-Register ist kein Beweis für einen bereinigten Host: GitHub beschreibt in den Hinweisen zu selbst gehosteten Runnern auch die Grenzen und Risiken dieser Runner-Klasse.

Wiederverwendung und gemeinsame Runner

Ein abgeschlossener Auftrag kann Dateien, Schlüsselbundzustände, temporäre Zugangsdaten, Logs oder Build-Artefakte hinterlassen. GitHub empfiehlt, selbst gehostete Runner nicht als automatisch saubere, voneinander isolierte Umgebungen zu behandeln; relevant sind die Sicherheitsinformationen zu selbst gehosteten Runnern. Prüfen Sie deshalb die Hostbereinigung anhand Ihrer tatsächlichen Ausführungsweise und nicht nur anhand eines Status „Runner entfernt“ oder „Auftrag beendet“.

Die Abnahme muss mindestens zeigen, was nach einem Auftrag mit Arbeitsverzeichnis und temporären Dateien geschieht, wie der Schlüsselbundzustand zurückgesetzt wird, wo Artefakte und Logs liegen und ob die Maschine für den nächsten Auftrag wiederverwendet wird. Testen Sie Fehlerpfade ebenso wie erfolgreiche Builds: Ein abgebrochener Export oder ein fehlgeschlagener Signierschritt kann andere Rückstände hinterlassen als ein sauberer Abschluss.

Bei gemeinsam genutzten Runnern kommt die Frage hinzu, welche Projekte die Maschine auswählen dürfen. Ordnen Sie Repository, Team und Veröffentlichungsverantwortung den Runner-Gruppen und Zugriffsregeln zu. Ein Team, das nur Tests ausführen darf, sollte nicht allein durch gemeinsame Maschinenzuordnung Zugriff auf einen Release-Workflow oder auf dessen lokalen Zustand erhalten. Finden Sie keine überprüfbare Grenze, verkleinern Sie den Nutzerkreis oder trennen Sie die Umgebungen.

Ein temporärer Runner oder eine einmalige Registrierung kann die Lebensdauer eines Runner-Eintrags begrenzen, beweist für sich genommen aber nicht, dass darunterliegende Hardware, Datenträger und temporäre Daten bereinigt wurden. Prüfen Sie daher die Ressourcenzuweisung und den Bereinigungsmechanismus separat. Ihre Aussage über Isolation darf nicht weiter reichen als die aufgezeichneten Nachweise.

Abnahmeliste und Freigabeentscheidung

Halten Sie die Prüfung so fest, dass eine andere verantwortliche Person sie anhand der Workflow-Dateien, GitHub-Zugriffsregeln und Testprotokolle nachvollziehen kann. Markieren Sie jeden Punkt erst dann als erledigt, wenn Sie die zugehörige Konfiguration oder einen Ausführungsnachweis geprüft haben.

Prüfliste für die Produktionsfreigabe

• [ ] Auslöser und Quellstand: PR-, Branch- und Veröffentlichungsereignisse sind erfasst; für jedes Ereignis ist geprüft, welcher Commit tatsächlich ausgeführt wird.
• [ ] Keine Geheimnisse im PR-Prüfpfad: Nicht vertrauenswürdige Änderungen können weder Signaturschlüssel noch App-Store-Zugangsdaten abrufen und erreichen keinen Runner mit solchen lokal verfügbaren Geheimnissen.
• [ ] Minimale Workflow-Rechte: GITHUB_TOKEN und weitere Berechtigungen entsprechen den konkreten Arbeitsschritten; nicht benötigte Rechte sind nicht pauschal aktiviert.
• [ ] Geprüfte Actions: Quelle und verwendete Version der Actions sind nachvollziehbar; Änderungen an Abhängigkeiten werden für signaturfähige Workflows überprüft.
• [ ] Begrenzter Runner-Zugriff: Sie haben nachgewiesen, welche Repositories und Teams die Maschine einplanen dürfen und wer die zugehörigen Workflows ändern kann.
• [ ] Enger Zugriff auf Signaturmaterial: Zertifikat, privater Schlüssel und Veröffentlichungszugangsdaten sind den Aufgaben zugeordnet, die sie tatsächlich benötigen.
• [ ] Geprüfte Bereinigung: Arbeitsverzeichnis, Schlüsselbund, temporäre Dateien, Artefakte und Logs wurden nach erfolgreichen und fehlgeschlagenen Aufträgen untersucht.
• [ ] Dokumentierter Fehlerpfad: Für einen verdächtigen Auftrag ist festgelegt, wie Runner-Zugriff gesperrt, betroffene Geheimnisse geprüft und die Umgebung neu bewertet werden.
• [ ] Offene Risiken festgehalten: Nicht behobene Abweichungen sind mit verantwortlicher Person und Freigabebedingung dokumentiert.

Entscheidung anhand der Prüfergebnisse

• Wenn alle Punkte belegt sind: Geben Sie den Runner für die vorgesehenen Produktionsaufgaben frei, und bewahren Sie die Nachweise zu Workflow-Rechten, Runner-Zugriff und Bereinigung auf.
• Wenn nur die Trennung der Veröffentlichungsgeheimnisse oder die Hostbereinigung offen ist: Nutzen Sie den Runner ausschließlich für Builds ohne Signaturmaterial. Verschieben Sie signierte Veröffentlichungen auf eine nachweislich getrennte Umgebung, bis die offenen Punkte geklärt sind.
• Wenn nicht vertrauenswürdiger Code einen Runner mit privaten Schlüsseln erreichen kann oder der Hostzustand unbekannt bleibt: Geben Sie den Runner nicht für produktive Veröffentlichungen frei. Begrenzen Sie den Zugriff, trennen Sie PR- und Release-Aufgaben und wiederholen Sie die Abnahme.
• Wenn mehrere Repositories unterschiedliche Vertrauensstufen haben: Teilen Sie den Runner-Zugriff nach Repository oder Veröffentlichungsverantwortung auf. Können Sie die Grenze nicht belegen, verkleinern Sie den Kreis der berechtigten Projekte oder verwenden Sie getrennte Umgebungen.

Bewerten Sie jeden Bereich mit freigegeben, eingeschränkt oder offen. Eine offene Bewertung bei PR-Trennung, privatem Schlüssel oder Hostbereinigung ist ein Stoppsignal für Veröffentlichungen mit produktiven Geheimnissen. Diese Wertung ist ein internes Abnahmeschema, keine von GitHub oder Apple vergebene Sicherheitszertifizierung.

Wenn Sie zunächst Ihre Arbeitsumgebung und den Zugriff auf einen Remote Mac prüfen möchten, können Sie die Umgebungsübersicht von VPSMAC als Ausgangspunkt für die Klärung von Bereitstellung und Zugang heranziehen. Entscheidend bleibt, dass Sie für die konkrete Umgebung eigene, überprüfbare Nachweise zu Runner-Zugriff und Bereinigung erhalten; aus einer allgemeinen Produktbeschreibung lässt sich kein Sicherheitsstatus ableiten.

Ein selbst verwalteter Mac kann hohe Anfangskosten, laufende Wartung und zusätzlichen Aufwand für Netzwerk, Updates und Hostbereinigung bedeuten. Ein gemieteter Remote Mac kann den Hardwarekauf vermeiden und ist als zeitlich begrenzte CI-Umgebung eine prüfbare Alternative, ersetzt aber weder die Trennung von PR-Code noch den Schutz der Signaturschlüssel. Wenn Sie eine solche Option erwägen, klären Sie vorab anhand der Informationen zum Mac-Knoten, welche Zugangs- und Umgebungsdetails für Ihre Abnahme tatsächlich dokumentiert sind. Für langfristige, dauerhaft hoch ausgelastete Aufgaben oder erforderliche physische Geräte kann ein eigener Mac geeigneter sein; mieten Sie nur, wenn die konkrete Laufzeit und der nachweisbare Betriebsrahmen zu Ihrem Workflow passen.