Referenz zur sicheren Verwendung

Hier finden Sie Informationen zu bewährten Methoden für die Sicherheit, wenn Sie Workflows schreiben und Sicherheitsfeatures verwenden GitHub Actions .

Schreiben von Workflows

Verwenden Sie Geheimnisse für vertrauliche Informationen

Da es mehrere Möglichkeiten gibt, einen Geheimniswert zu transformieren, kann keine automatische Bearbeitung garantiert werden. Halte dich an die folgenden Best Practices, um Risiken im Zusammenhang mit Geheimnissen zu begrenzen.

Prinzip der geringsten Rechte
- Alle Benutzer mit Schreibzugriff auf dein Repository verfügen über Lesezugriff auf alle Geheimnisse, die in deinem Repository konfiguriert sind. Aus diesem Grund solltest du sicherstellen, dass die in Workflows verwendeten Anmeldeinformationen über die geringsten erforderlichen Berechtigungen verfügen.
- Aktionen können GITHUB_TOKEN verwenden, indem sie über den github.token-Kontext darauf zugreifen. Weitere Informationen finden Sie unter Kontextreferenz. Aus diesem Grund solltest du sicherstellen, dass GITHUB_TOKEN die geringsten erforderlichen Berechtigungen erteilt werden. Es ist eine gute Sicherheitsvorkehrung, die Standardeinstellung der Berechtigung für GITHUB_TOKEN auf lediglich Lesezugriff für Repository-Inhalte festzulegen. Die Berechtigungen können dann nach Bedarf für einzelne Aufträge in der Workflowdatei erhöht werden. Weitere Informationen finden Sie unter Verwenden von GITHUB_TOKEN für die Authentifizierung in Workflows.
Maskieren vertraulicher Daten
- Vertrauliche Daten sollten niemals als Klartext in Workflowdateien gespeichert werden. Maskieren Sie alle vertraulichen Informationen, die nicht geheim GitHub sind, indem Sie ::add-mask::VALUEverwenden. Dadurch wird der Wert als geheim behandelt und aus den Protokollen herausgenommen. Weitere Informationen zum Maskieren von Daten findest du unter Workflow commands for GitHub Actions (Workflowbefehle für GitHub Actions).
Löschen und Rotieren von offengelegten Geheimnissen
- Die Schwärzung von Geheimnissen wird von Ihren Workflow-Runnern durchgeführt. Das bedeutet, dass ein Geheimnis nur dann unkenntlich gemacht wird, wenn es im Rahmen einer Aufgabe verwendet wurde und für den Runner zugänglich ist. Wenn ein nicht zensiertes Secret an ein Workflow-Ausführungsprotokoll gesendet wird, solltest du das Protokoll löschen und das Secret rotieren. Informationen zum Löschen von Protokollen findest du unter Verwenden von Workflowausführungsprotokollen.
Verwende niemals strukturierte Daten als Geheimnis
- Bei strukturierten Daten können bei der Bearbeitung des Geheimnisses innerhalb von Protokollen Fehler auftreten. Der Grund dafür ist, dass die Bearbeitung weitgehend davon abhängig ist, dass eine exakte Übereinstimmung für den spezifischen geheimen Wert gefunden wird. Verwende z. B. keinen JSON-, XML-, YAML- oder ähnlichen Block, um einen geheimen Wert zu kapseln, da die Wahrscheinlichkeit, dass die Geheimnisse ordnungsgemäß geschützt werden, dadurch erheblich sinkt. Erstelle stattdessen einzelne Geheimnisse für jeden vertraulichen Wert.
Registriere alle Geheimnisse, die in Workflows verwendet werden
- Wenn ein Geheimnis verwendet wird, um einen anderen vertraulichen Wert innerhalb eines Workflows zu generieren, sollte dieser generierte Wert formal als Geheimnis registriert werden. So wird er redigiert, falls er jemals in den Logs erscheint. Wenn du z. B. einen privaten Schlüssel zum Generieren eines signierten JWT für den Zugriff auf eine Web-API verwendest, musst du das JWT als Geheimnis registrieren, sonst wird es nicht redigiert, wenn es in einer Protokollausgabe erscheint.
- Die Registrierung von Geheimnissen gilt auch für jegliche Art von Transformation/Codierung. Wenn dein Geheimnis transformiert wird (z. B. bei der Base64- oder URL-Codierung), musst du auch den neuen Wert als geheim registrieren.
Überprüfe, wie Geheimnisse verarbeitet werden
- Du solltest prüfen, wie Geheimnisse verwendet werden, um sicherzustellen, dass sie wie erwartet gehandhabt werden. Überprüfe dazu im Quellcode des Repositorys, das den Workflow ausführt, alle Aktionen, die im Workflow verwendet werden. Stelle z. B. sicher, dass vertrauliche Informationen nicht an unbeabsichtigte Hosts gesendet werden oder explizit in der Protokollausgabe ausgegeben werden.
- Sieh dir die Ausführungsprotokolle für deinen Workflow an, nachdem du gültige/ungültige Eingaben getestet hast, und überprüfe, ob Geheimnisse ordnungsgemäß bearbeitet bzw. nicht angezeigt werden. Es ist nicht immer offensichtlich, wie ein aufgerufener Befehl oder ein aufgerufenes Tool Fehler an STDOUT und STDERR sendet. So ist es möglich, dass Geheimnisse in Fehlerprotokollen erscheinen. Daher empfiehlt es sich, die Workflowprotokolle nach dem Testen gültiger und ungültiger Eingaben manuell zu überprüfen. Informationen zur Bereinigung von Workflowprotokollen, die unbeabsichtigt vertrauliche Daten enthalten können, findest du unter Verwenden von Workflowausführungsprotokollen.
Überprüfe und rotiere registrierte Geheimnisse
- Überprüfe die registrierten Geheimnisse regelmäßig, um sicherzustellen, dass sie noch erforderlich sind. Entferne diejenigen, die nicht mehr benötigt werden.
- Rotiere Geheimnisse regelmäßig, um das Zeitfenster zu verringern, in dem ein kompromittiertes Geheimnis gültig ist.
Lege gegebenenfalls fest, dass beim Zugriff auf Geheimnisse eine Überprüfung erforderlich ist
- Sie können erforderliche Prüfer verwenden, um Umgebungsgeheimnisse zu schützen. Ein Workflow-Auftrag kann nicht auf Umgebungsgeheimnisse zugreifen, bis ein Prüfer die Genehmigung erteilt hat. Weitere Informationen zum Speichern von Geheimnissen in Umgebungen oder zum Festlegen von erforderlichen Überprüfungen für Umgebungen findest du unter Verwenden von Geheimnissen in GitHub-Aktionen und Verwalten von Umgebungen für die Bereitstellung.

Bewährte Methoden zum Verhindern von Angriffen durch Skripteinschleusung

Empfohlene Ansätze zum Verringern des Risikos der Skripteinschleusung in deinen Workflows:

Verwenden einer Aktion anstelle eines Inlineskripts

Bei dieser empfohlenen Vorgehensweise erstellen Sie eine JavaScript-Aktion, die den Kontextwert als Argument verarbeitet. Da der Kontextwert bei diesem Ansatz nicht zum Generieren eines Shellskripts verwendet wird, sondern stattdessen als Argument an die Aktion übergeben wird, wird das Risiko der Skripteinschleusung minimiert:

uses: fakeaction/checktitle@v3
with:
  title: ${{ github.event.pull_request.title }}

Verwenden einer Zwischenumgebungsvariablen

Bei Inlineskripts sollte der Wert des Ausdrucks auf eine Zwischenumgebungsvariable festgelegt werden, um nicht vertrauenswürdige Eingaben zu verhindern. Im folgenden Beispiel wird Bash verwendet, um den github.event.pull_request.title-Wert als Umgebungsvariable zu verarbeiten:

      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

In diesem Beispiel ist die versuchte Skripteinschleusung nicht erfolgreich, was in den folgenden Zeilen im Protokoll angegeben wird:

   env:
     TITLE: a"; ls $GITHUB_WORKSPACE"
PR title did not start with 'octocat'

Bei diesem Ansatz wird der Wert des Ausdrucks ${{ github.event.pull_request.title }} im Arbeitsspeicher gespeichert und als Variable verwendet, und er interagiert nicht mit dem Skriptgenerierungsprozess. Darüber hinaus sollten Sie die Verwendung doppelter Anführungszeichen-Shellvariablen in Betracht ziehen, um das Teilen von Wörtern zu vermeiden. Dies ist jedoch eine der vielen allgemeinen Empfehlungen zum Schreiben von Shellskripts und ist nicht spezifisch für GitHub Actions.

Einschränken von Berechtigungen für Token

Du solltest die zugewiesenen Berechtigungen einschränken, um das Risiko offengelegter Token zu mindern. Weitere Informationen finden Sie unter Verwenden von GITHUB_TOKEN für die Authentifizierung in Workflows.

Minimieren der Risiken beim Auschecken nicht vertrauenswürdigen Codes

Ähnlich wie Angriffe mit Einschleusung von Skripten können nicht vertrauenswürdige Pull-Request-Inhalte, die die Verarbeitung von Aktionen automatisch auslösen, ebenfalls ein Sicherheitsrisiko darstellen. Die Workflow-Trigger pull_request_target und workflow_run können, wenn sie zusammen mit dem Auschecken eines nicht vertrauenswürdigen Pull-Requests verwendet werden, das Repository potenziellen Sicherheitsrisiken aussetzen. Diese Workflows sind privilegiert. Das bedeutet, dass sie denselben Cache des Hauptbranch mit weiteren privilegierten Workflow-Triggern teilen und möglicherweise Schreibzugriff auf Repositories sowie Zugriff auf referenzierte Secrets haben. Diese Sicherheitsrisiken können ausgenutzt werden, um ein Repository zu übernehmen.

Weitere Informationen zu diesen Triggern, ihrer Verwendung und den damit verbundenen Risiken findest du Ereignisse zum Auslösen von Workflows und Ereignisse zum Auslösen von Workflows.

Weitere Beispiele und Hinweise zu den Risiken des Auscheckens nicht vertrauenswürdigen Codes finden Sie unter Verhindern von pwn-Anforderungen von GitHub Security Lab sowie in der Dangerous-Workflow-Dokumentation von OpenSSF Scorecard.

Ausführliche Hinweise dazu, ob pull_request_target verwendet werden soll, wie diese Workflows gehärtet werden können und wie der actions/checkout-Schutz deaktiviert werden kann, finden Sie unter Sichere Verwendung von pull_request_target.

Bewährte Methoden

Vermeide die Verwendung des Workflowtriggers pull_request_target, wenn dieser nicht erforderlich ist. Zur Trennung von Berechtigungen zwischen Workflows ist workflow_run ein besserer Trigger. Verwende diese Workflowtrigger nur, wenn der Workflow tatsächlich den privilegierten Kontext benötigt.
Vermeide die Verwendung der Workflowtrigger pull_request_target und workflow_run mit nicht vertrauenswürdigen Pull Requests oder Codeinhalten. Workflows, die diese Trigger verwenden, dürfen nicht vertrauenswürdigen Code nicht explizit auschecken, einschließlich aus Pull-Request-Forks oder Repositorys, die du nicht kontrollierst. Workflows, die bei workflow_run ausgelöst werden, sollten Artefakte vorsichtig behandeln, die aus anderen Workflows hochgeladen wurden.
CodeQL kann potenziell anfällige GitHub Actions Workflows scannen und erkennen. Sie können das Standardsetup für das Repository konfigurieren und sicherstellen, dass die GitHub Actions Überprüfung aktiviert ist. Weitere Informationen finden Sie unter Konfigurieren des Standardsetups für das Code-Scanning.
OpenSSF Scorecards können Ihnen helfen, potenziell anfällige Workflows zusammen mit anderen Sicherheitsrisiken bei der Verwendung GitHub Actionszu identifizieren. Weitere Informationen findest du unter Verwenden von OpenSSF Scorecards zum Schützen von Workflowabhängigkeiten weiter unten in diesem Artikel.

Verwenden von Drittanbieteraktionen

Die einzelnen Aufträge in einem Workflow können mit anderen Aufträgen interagieren (und diese kompromittieren). Beispiel: Ein Auftrag, der die von einem späteren Auftrag verwendeten Umgebungsvariablen abfragt, Dateien in ein freigegebenes Verzeichnis schreibt, das von einem späteren Auftrag verarbeitet wird, oder sogar direkt mit dem Docker-Socket interagiert, andere ausgeführte Container überprüft und Befehle in diesen Containern ausführt.

Eine einzelne kompromittierte Aktion in einem Workflow kann also große Auswirkungen haben, da diese kompromittierte Aktion Zugriff auf alle Geheimnisse hat, die in deinem Repository konfiguriert sind. Außerdem kann diese Aktion gegebenenfalls GITHUB_TOKEN verwenden, um Inhalte in das Repository zu schreiben. Folglich besteht ein erhebliches Risiko bei Beschaffungsaktionen aus Repositorys von Drittanbietern auf GitHub. Informationen zu möglichen Schritten, die ein Angreifer ausführen kann, findest du unter Referenz zur sicheren Verwendung.

Du kannst dieses Risiko verringern, indem du die folgenden bewährten Methoden anwendest:

Anheften von Aktionen an einen Commit-SHA mit voller Länge

Das Anheften einer Aktion an einen Commit-SHA mit voller Länge ist derzeit die einzige Möglichkeit, eine Aktion als unveränderliche Version zu verwenden. Durch das Anheften an einen bestimmten SHA wird das Risiko von Angriffen verringert, bei denen eine Hintertür zum Repository der Aktion hinzugefügt wird. Der Grund dafür ist, dass in diesem Fall eine SHA-1-Kollision für eine gültige Git-Objektpayload generiert werden müsste. Wenn du einen SHA auswählen, solltest du überprüfen, ob er aus dem Repository der Aktion und nicht aus einem Repositoryfork stammt.

Ein Beispiel für die Verwendung eines Commit-SHA mit voller Länge in einem Workflow findest du unter Verwenden von vordefinierten Bausteinen im Workflow.

GitHub bietet Richtlinien auf Repository-, Organisations- und Unternehmens- an, um Aktionen an eine Commit-SHA in voller Länge anzuheften: * Informationen zum Konfigurieren der Richtlinie auf Repositoryebene findest du unter Einstellung der GitHub Actions für ein Repository verwalten. * Informationen zum Konfigurieren der Richtlinie auf Organisationsebene findest du unter

In diesem Artikel