GitHub Actions pull_request_target-Standardregeln: Wie prüfen Sie Mac CI? 2026

Behandeln Sie die Ankündigung nicht als globale Abschaltung des Ereignisses. GitHub hat die Workflow Execution Protections am 17.09.2026 allgemein verfügbar gemacht. Für öffentliche Repositories ohne anwendbare Ereignisrichtlinie ist zunächst ein Bewertungsmodus vorgesehen; die automatische Durchsetzung ist für den 02.12.2026 angekündigt. Private und interne Repositories fallen nicht unter diese öffentliche Standardregel. Diese Angaben sind im Changelog zur Verfügbarkeit und zum Zeitplan dokumentiert.

Ermitteln Sie zuerst, welche Repositories tatsächlich öffentlich sind und welche Richtlinien dort bereits gelten. Eine Organisation kann öffentliche und private Repositories nebeneinander verwalten. Die Sichtbarkeit eines einzelnen Projekts sagt nicht aus, ob für seine Workflows eine passende Ereignisrichtlinie aktiv ist. Prüfen Sie deshalb die effektive Konfiguration je Repository, statt eine Organisationsannahme ungeprüft auf alle Projekte zu übertragen.

Legen Sie eine Arbeitsliste aller Workflows an, die pull_request_target verwenden. Notieren Sie Repository, Dateipfad, Zweck, Auslöser, verantwortliches Team und Verwendungszweck der Zugangsdaten. Unterscheiden Sie dabei beispielsweise einen Workflow, der nur Metadaten eines Pull Requests verarbeitet, von einem, der auf einem Mac Runner Code baut oder Signiermaterial erreichen kann. Diese Unterscheidung ist für die spätere Freigabe entscheidend.

GitHub beschreibt die steuerbaren Ereignisrichtlinien und ihre Verwaltung in der Dokumentation zu Actions-Richtlinien. Vergleichen Sie die Richtlinie, die für das jeweilige Repository wirksam ist, mit der Workflow-Datei. Die bloße Existenz einer Richtlinie in einer Organisation belegt nicht, dass sie für den fraglichen Workflow die beabsichtigte Wirkung hat.

Der Bewertungsmodus soll sichtbar machen, welche Ausführungen von der vorgesehenen Richtlinie betroffen sein könnten. Er ist nicht mit einer aktiven Blockierung gleichzusetzen. Behandeln Sie einen Eintrag in GitHub Actions Insights deshalb als Anlass zur Untersuchung und nicht als Nachweis, dass GitHub den Lauf bereits verhindert oder dass der Workflow sicher ist.

Ordnen Sie die Beobachtungen mindestens drei Dingen zu: dem Repository, der konkreten Workflow-Datei und einer verantwortlichen Person oder Gruppe. Ergänzen Sie den zugehörigen Pull-Request-Auslöser, die Herkunft des geprüften Codes und die benötigten Berechtigungen. Die Dokumentation zu Actions-Nutzungsmetriken und Insights beschreibt, wo Sie die verfügbaren Nutzungsdaten einsehen können. Welche Angaben Sie für die Freigabeentscheidung benötigen, sollten Sie zusätzlich in Ihrem eigenen Prüfprotokoll festhalten.

Ein einzelner unauffälliger Abruf ist keine belastbare Aussage über künftige Ausführungen. Prüfen Sie, ob Ihre Erhebung die relevanten Repositories und Workflow-Dateien umfasst und ob während des Beobachtungszeitraums überhaupt passende Pull Requests aufgetreten sind. Dokumentieren Sie, welche Bereiche nicht geprüft werden konnten. So vermeiden Sie, dass „kein Treffer“ versehentlich als „kein Risiko“ in eine Freigabe eingeht.

Nutzen Sie die Ergebnisse gezielt:

• [ ] Betroffene oder potenziell betroffene Ereignisse mit dem Repository-Bestand abgeglichen.
• [ ] Workflow-Dateien und zuständige Teams identifiziert.
• [ ] Unklare, nicht beobachtete oder nicht zuordenbare Ergebnisse markiert.
• [ ] Nächste Prüfung festgelegt, falls sich Repository-Sichtbarkeit oder Richtlinien ändern.

Das Risiko von pull_request_target hängt vor allem davon ab, was der Workflow ausführt und welchen Zugriff er dabei erhält. Prüfen Sie, ob er Code aus einem Fork auscheckt, Skripte daraus startet oder andere nicht vertrauenswürdige Inhalte verarbeitet. Stellen Sie dem gegenüber, welche Berechtigungen und geheimen Werte der Lauf erreichen kann. Die GitHub-Sicherheitsdokumentation zu pull_request_target erläutert, weshalb der Umgang mit nicht vertrauenswürdigem Pull-Request-Code besondere Sorgfalt verlangt.

Ein Mac Runner ist dabei nicht automatisch eine Sicherheitsgrenze. Die Hardwareeigenschaft des Hosts beantwortet weder, ob der Workflow Code eines Forks ausführt, noch ob Zugangsdaten verfügbar sind. Prüfen Sie separat, welche Repository-Berechtigungen der Lauf erhält, welche Signiermaterialien oder anderen Geheimnisse erreichbar sind und ob erzeugte Artefakte später in einem privilegierteren Job verwendet werden.

Setzen Sie Workflow-Berechtigungen so eng wie möglich. GitHub dokumentiert die Konfiguration von Berechtigungen mit permissions in der Referenz zur Workflow-Syntax. Vergleichen Sie die angeforderten Rechte mit der Aufgabe des Jobs. Wenn ein Prüfschritt nur Quellcode validieren soll, muss Ihr Prüfprotokoll erklären, weshalb dieser Schritt überhaupt Zugriff auf sensible Werte oder weitergehende Schreibrechte benötigt.

Bei selbst gehosteten Runnern ist zusätzlich der Hostbetrieb zu betrachten. Die GitHub-Hinweise zur sicheren Nutzung selbst gehosteter Runner sind ein eigener Prüfstrang; sie ersetzen keine Ereignisrichtlinie und machen einen riskanten Workflow nicht unbedenklich. Umgekehrt sagt eine Ereignisrichtlinie nicht aus, dass ein Mac-Host, seine Zugangsdaten oder seine Artefakte isoliert sind.

Für jede Workflow-Datei beantworten Sie vor einer Ausnahme diese Fragen:

• [ ] Wird Code aus einem Fork ausgecheckt oder ausgeführt?
• [ ] Welche Repository-Berechtigungen benötigt der Workflow tatsächlich?
• [ ] Kann der Lauf Signiermaterial, Geheimnisse oder andere sensible Werte erreichen?
• [ ] Werden Artefakte aus nicht vertrauenswürdigem Code später in einem privilegierten Job verarbeitet?
• [ ] Kann ein anderes Ereignis den Zweck mit engeren Rechten erfüllen?

Die folgenden Antworten betreffen die Reichweite der Richtlinie und die Auswertung. Sie ersetzen nicht die Prüfung der effektiven Richtlinien und der einzelnen Workflow-Dateien.

Welche Repositories fallen unter die Standardregel?
Die angekündigte Standardregel betrifft öffentliche Repositories ohne anwendbare Ereignisrichtlinie. Private und interne Repositories sind davon ausgenommen. Erfassen Sie bestehende Richtlinien trotzdem pro Repository; Sichtbarkeit allein entscheidet nicht, welche andere Organisations- oder Repositoryrichtlinie wirksam ist.

Wie finden Sie potenziell blockierte Mac-CI-Workflows?
Ordnen Sie die Ergebnisse aus Insights dem Repository, der Workflow-Datei und dem jeweiligen Auslöser zu. Prüfen Sie anschließend, ob der Lauf Mac-Ressourcen, Berechtigungen oder Zugangsdaten verwendet. Der Bewertungsmodus liefert einen Prüfhinweis, aber keine Bestätigung einer erfolgreichen Blockierung oder einer vollständigen Sicherheitsprüfung.

Was gilt für private Repositories?
Die angekündigte öffentliche Standardregel gilt nicht für private oder interne Repositories. Prüfen Sie dort dennoch die für Ihre Organisation geltenden Actions-Richtlinien. Verwechseln Sie die Nichtanwendbarkeit dieser Standardregel nicht mit einer allgemeinen Freigabe von pull_request_target oder einem Nachweis, dass der Workflow sicher konfiguriert ist.

Wie begrenzen Sie eine notwendige Ausnahme?
Begründen Sie den Bedarf für genau diesen Workflow und prüfen Sie eine Alternative mit geeigneterem Auslöser. Falls pull_request_target bleiben muss, richten Sie die Freigabe so eng wie möglich ein. Halten Sie Repository, Workflow-Datei, Rechte, Zugangsdatenbedarf und Genehmigung fest. Eine ausdrückliche Zulassung ersetzt weder die Prüfung des ausgeführten Codes noch die Prüfung des Mac Hosts.

Wenn ein Workflow auf pull_request_target angewiesen zu sein scheint, halten Sie zunächst an und prüfen Sie den Zweck. Kann ein anderes Ereignis den nötigen PR-Check ermöglichen, ohne privilegierte Workflow-Bedingungen zusammenzubringen? Lässt sich eine Aufgabe in einen nicht privilegierten Prüfjob und einen getrennten, kontrollierten Nachbereitungsschritt aufteilen? Eine Umgestaltung kann besser sein als eine weitreichende Ausnahme.

Ist das Ereignis nach der Prüfung erforderlich, richten Sie die Freigabe nur für den notwendigen Geltungsbereich ein. Berücksichtigen Sie, dass GitHub die gezielte Steuerung von Workflow-Dateien unterstützt; gleichen Sie den erlaubten Umfang daher mit dem konkreten Pfad der geprüften Datei ab. Kontrollieren Sie die aktuell dokumentierten Optionen in der Verwaltungsdokumentation für die Workflow-Ausführung, bevor Sie die Richtlinie ändern.

Eine Ausnahme sollte mindestens folgende Angaben enthalten:

• [ ] Repository und Workflow-Datei, für die sie gilt.
• [ ] Geschäftlicher oder technischer Zweck, der den Auslöser erforderlich macht.
• [ ] Codequellen, Berechtigungen und Zugangsdaten, die der Lauf erreicht.
• [ ] Genehmigende Person und verantwortliches Team.
• [ ] Bedingung, bei der die Ausnahme erneut geprüft oder entfernt wird.

Schreiben Sie in den Änderungsnachweis, welche Alternativen geprüft wurden und weshalb sie nicht ausreichen. Vermeiden Sie Sammelfreigaben für mehrere Dateien, wenn nur eine Datei den Bedarf belegt. Eine Richtlinie, die den Workflow explizit erlaubt, ist lediglich eine Steuerungsentscheidung: Sie bestätigt nicht, dass der Workflow- oder Hostbetrieb sicher ist.

Planen Sie einen kontrollierten Test, bevor Sie eine Richtlinie produktiv setzen. Prüfen Sie dabei sowohl einen erwartungsgemäß zulässigen als auch einen erwartungsgemäß abgelehnten Fall. Halten Sie für jeden Test fest, welches Repository und welche Workflow-Datei verwendet wurden, welche Richtlinie galt und was Insights beziehungsweise der Ausführungsverlauf anzeigte.

Unterscheiden Sie zwei Ergebnisse. Erstens: Hat die Ereignisrichtlinie die erwartete Ausführung zugelassen oder verhindert? Zweitens: Hat der verbleibende Mac-CI-Workflow seine Sicherheitsgrenzen eingehalten? Ein erfolgreich abgeschlossener Build beantwortet die zweite Frage nicht. Prüfen Sie Berechtigungen, Zugriff auf Signiermaterial und die Behandlung der Build-Artefakte unabhängig vom Status der Aufgabe.

Auch das Fehlerbild gehört zur Vorbereitung. Nach einer Richtlinienänderung kann ein erwarteter CI-Lauf ausbleiben oder ein bislang genutzter Workflow nicht mehr starten. Legen Sie fest, wer den Fehler diagnostiziert, wie die Ursache von einem Mac-Runner-Problem unterschieden wird und welche Änderung zurückgenommen werden darf. Halten Sie die erwartete Wirkung einer Rücknahme fest, damit aus einem Betriebsproblem nicht unkontrolliert eine breite Ausnahme entsteht.

Bewahren Sie als Prüfnachweis die Repository-Liste, den Stand der Richtlinie, relevante Insights-Ergebnisse, Testläufe und Ausnahmegenehmigungen auf. Wenn Sie Richtlinien zusätzlich automatisiert verwalten, gleichen Sie Konfiguration und Auswertung mit der GitHub-REST-API-Referenz zu Actions-Richtlinien ab. Verwenden Sie den API-Aufruf nicht als Ersatz für die fachliche Freigabe oder den Test der betroffenen Workflow-Datei.

Ihre Freigabeentscheidung sollte eine von drei klaren Handlungen festhalten: pull_request_target für die geprüften Workflows blockieren, für konkret benannte Workflows begrenzt zulassen oder die Entscheidung bis zur Überarbeitung aussetzen. Verknüpfen Sie die Entscheidung mit den Beobachtungen aus Insights und den Ergebnissen der kontrollierten Tests. So lässt sich später nachvollziehen, ob sich eine Richtlinie auf belastbare Informationen oder nur auf eine Annahme stützte.

Der geplante Durchsetzungstermin 02.12.2026 ist ein Prüfpunkt, kein Grund, den Status aller Unternehmens-Repositories gleichzusetzen. GitHub nennt diesen Termin für die betroffenen öffentlichen Repositories ohne anwendbare Ereignisrichtlinie. Prüfen Sie unmittelbar vor der Umsetzung die offizielle Ankündigung, insbesondere wenn sich Veröffentlichungsdatum, Anwendungsbereich oder Verhalten der Richtlinie zwischenzeitlich geändert haben.

Legen Sie eine erneute Prüfung fest, wenn sich Repository-Sichtbarkeit, Workflow-Datei, Ereignisrichtlinie, benötigte Berechtigungen oder die Nutzung von Signiermaterial ändert. Behalten Sie außerdem die Trennung zwischen Ereignisentscheidung und Hostkontrolle bei: Die eine entscheidet über den Workflow-Auslöser; die andere betrifft die Sicherheit des Mac Runners und der darauf erreichbaren Ressourcen.

Betriebshinweis: Eine grüne CI-Ausführung ist kein Nachweis dafür, dass ein Fork-Code keinen Zugriff auf sensible Daten hatte. Prüfen Sie dafür die tatsächlich verwendeten Rechte, Geheimnisse und Artefaktübergaben.

Wenn Ihr derzeitiger Ansatz alle Workflows pauschal zulässt, bleibt unklar, welche Dateien tatsächlich nötig sind; wenn Sie vorsorglich alles sperren, können legitime PR-Prüfungen ausfallen; und wenn Sie nur den erfolgreichen Build betrachten, übersehen Sie möglicherweise die Grenze zwischen nicht vertrauenswürdigem Code und Signiermaterial. Schließen Sie zuerst die Richtlinien- und Workflow-Abnahme ab. Benötigt Ihr Team danach eine eigene macOS-Ausführungsumgebung, vergleichen Sie den bestehenden Runner-Betrieb mit einer Remote-Mac-Miete anhand von Wartungsaufwand, Zugriffskontrolle und tatsächlichem Nutzungszeitraum. Einen Überblick über Remote-Mac-Umgebungen für Teams bei CALMVPS können Sie in diese Prüfung einbeziehen; für dauerhaft hohe Auslastung oder benötigte physische Schnittstellen kann ein eigener Mac geeigneter sein. Informationen zu Mac-Mietoptionen bei CALMVPS helfen beim Abgleich der verfügbaren Konditionen.