GitHub-Actions-Workflows absichern: Actions per SHA anheften, Tokens nach dem Prinzip der geringsten Rechte, nicht vertrauenswürdige Eingaben

Ziel

Ein Workflow, dessen Verhalten sich nicht durch eine dritte Partei ändern lässt, die eine neue Action-Version veröffentlicht, dessen Token keinen Code oder Tags pushen kann, ausser ein Job braucht das ausdrücklich, und dessen Skripte sich nicht durch einen präparierten Pull-Request-Titel kapern lassen.

Voraussetzungen

Schreibzugriff auf die Workflow-Dateien und Einstellungen des Repositorys; eine Liste jeder uses:-Referenz in .github/workflows.

Schritte

1. Jede uses: owner/action@v4-Referenz durch den vollständigen, 40-stelligen Commit-SHA ersetzen und den Tag als Kommentar (# v4.2.1) beibehalten. Die zitierte Referenz zur sicheren Nutzung hält fest, dass das Anheften an einen vollständigen Commit-SHA derzeit die einzige Möglichkeit ist, eine Action als unveränderliches Release zu verwenden, und dass geprüft werden sollte, ob der SHA tatsächlich aus dem Repository der Action stammt und nicht aus einem Fork. Neue SHAs sollte ein Bot für Abhängigkeits-Updates per Pull Request vorschlagen.
2. permissions: contents: read auf oberster Ebene jedes Workflows setzen. Gemäss der zitierten Workflow-Syntax setzt die Angabe einer beliebigen Berechtigung alle nicht angegebenen auf none; packages: write oder id-token: write einzeln bei dem Job ergänzen, der veröffentlicht.
3. Event-Daten als nicht vertrauenswürdig behandeln: ${{ github.event.pull_request.title }} oder einen Branch-Namen nie direkt in ein run:-Skript schreiben. Stattdessen über eine env:-Variable übergeben und in der Shell mit "$TITLE" referenzieren, oder die Logik in eine Action auslagern, die den Wert als Argument erhält – so wie es die Referenz zur sicheren Nutzung empfiehlt.
4. In pull_request_target- oder workflow_run-Workflows keinen Pull-Request-Code auschecken; die zitierte Referenz merkt an, dass diese Trigger auch für Forks mit Schreibzugriff auf das Repository und mit Secrets laufen. Muss ein privilegierter Schritt Fork-Inhalte lesen, diesen in einen unprivilegierten Workflow aufteilen, der ein Artefakt hochlädt, und einen privilegierten, der es konsumiert, ohne es auszuführen.
5. Deployment-Secrets in Environments mit erforderlichen Prüfern (Required Reviewers) ablegen, sodass ein Job sie erst nach Freigabe lesen kann.
6. Die Organisations- oder Repository-Richtlinie aktivieren, die SHA-Anheften erzwingt, damit eine künftige Änderung Schritt 1 nicht rückgängig machen kann.

Erwartetes Ergebnis

Jede Workflow-Datei benennt für jede Abhängigkeit genau definierten Code, gewährt dem Token nur das, was ein Job braucht, und enthält keine Shell-Zeile, die von Angreifern kontrollierbare Strings zusammensetzt.

Grenzen und Prüfbasis

Das Anheften per SHA friert Bugfixes ebenso ein wie Backdoors; ohne automatisierte Update-Vorschläge verkommt es zu veralteten Actions. Wiederverwendbare Workflows und zusammengesetzte (composite) Actions bringen eigene uses:-Zeilen mit, die intern ebenfalls angeheftet werden müssen. Die Anleitung folgt der zitierten GitHub-Dokumentation.