Wir veröffentlichen regelmäßig Aktualisierungen unserer Dokumentation, und die Übersetzung dieser Seite ist möglicherweise noch nicht abgeschlossen. Aktuelle Informationen findest du in der englischsprachigen Dokumentation.
In diesem Leitfaden wird erläutert, wie du die Sicherheitshärtung für bestimmte GitHub Actions-Features konfigurierst.
Wenn du noch nicht mit den Konzepten von GitHub Actions vertraut bist, findest du unter Grundlegendes zu GitHub Actions weitere Informationen.
Verwenden von Geheimnissen
Vertrauliche Werte sollten niemals als Klartext in Workflowdateien, sondern als Geheimnisse gespeichert werden. Geheimnisse können auf Organisations-, Repository- oder Umgebungsebene konfiguriert werden und ermöglichen das Speichern vertraulicher Informationen in GitHub AE.
Damit die Geheimnisse verschlüsselt werden, bevor sie GitHub AE erreichen, werden versiegelte libsodium-Felder verwendet.
Dieser Schritt erfolgt, wenn das Geheimnis über die Benutzeroberfläche oder über die REST-API übermittelt wird. Durch diese clientseitige Verschlüsselung lassen sich die Risiken im Zusammenhang mit der versehentlichen Protokollierung (z. B. Ausnahmeprotokolle und Anforderungsprotokolle) innerhalb der GitHub AE-Infrastruktur minimieren.
Sobald das Geheimnis hochgeladen wurde, ist GitHub AE in der Lage, das Geheimnis zu entschlüsseln, damit es in die Workflowlaufzeit eingefügt werden kann. Zum Verhindern einer versehentlichen Offenlegung verwendet GitHub AE einen Mechanismus, der versucht, Geheimnisse zu bearbeiten, die in Ausführungsprotokollen erscheinen. Bei diesem Bearbeitungsschritt wird nach exakten Übereinstimmungen für konfigurierte Geheimnisse sowie nach gemeinsamen Codierungen der Werte (z. B. Base64) gesucht. Da es jedoch mehrere Möglichkeiten gibt, einen geheimen Wert zu transformieren, kann diese Bearbeitung nicht garantiert werden.
Aus diesem Grund solltest du mithilfe bestimmter proaktiver Schritte und bewährter Methoden sicherstellen, dass Geheimnisse bearbeitetet werden und weitere Risiken im Zusammenhang mit Geheimnissen gemindert werden: 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. kein JSON-, XML-, YAML- oder ein ähnliches Blob, um einen geheimen Wert zu kapseln, da die Wahrscheinlichkeit, dass die Geheimnisse ordnungsgemäß bearbeitet 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 in einem Workflow zu generieren, sollte dieser generierte Wert formal als geheim registriert werden, damit er in Protokollen gegebenenfalls bearbeitet wird. 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. Anderenfalls wird das Token nicht bearbeitet, 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 überprüfen, ob Geheimnisse wie erwartet verwendet 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.
Verwende Anmeldeinformationen mit minimalen Berechtigungen Stelle sicher, dass die in Workflows verwendeten Anmeldeinformationen über den geringsten erforderlichen Umfang an Berechtigungen verfügen, und beachte, dass Benutzer*innen mit Schreibzugriff auf dein Repository auch über Lesezugriff auf alle Geheimnisse verfügen, die in deinem Repository konfiguriert sind. Aktionen können GITHUB_TOKEN verwenden, indem sie über den github.token-Kontext darauf zugreifen.
Aus diesem Grund solltest du sicherstellen, dass GITHUB_TOKEN die geringsten erforderlichen Berechtigungen erteilt werden.
Es empfiehlt sich, als Standardberechtigung für GITHUB_TOKEN lediglich Lesezugriff auf Repositoryinhalte festzulegen. Die Berechtigungen können dann nach Bedarf für einzelne Aufträge in der Workflowdatei erhöht werden. Weitere Informationen findest du unter Automatic token authentication. Überprüfe und rotiere registrierte Geheimnisse Überprüfe die registrierten Geheimnisse regelmäßig, um sicherzustellen, dass sie noch erforderlich sind. Entferne Geheimnisse, 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 Du kannst festlegen, dass eine Genehmigung durch einen Prüfer erforderlich ist, um Umgebungsgeheimnisse zu schützen.
So kann ein Workflowauftrag erst dann auf Umgebungsgeheimnisse zugreifen, nachdem ein Prüfer die entsprechende Genehmigung erteilt hat.
**Warnung**: Alle Benutzer*innen 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.
Verwenden von CODEOWNERS zum Überwachen von Änderungen Mithilfe des Features CODEOWNERS kannst du steuern, wie Änderungen an deinen Workflowdateien vorgenommen werden.
Wenn alle deine Workflowdateien z. B. in .github/workflows gespeichert sind, kannst du dieses Verzeichnis der Codebesitzerliste hinzufügen, damit alle vorgeschlagenen Änderungen an diesen Dateien zuerst von einem benannten Prüfer genehmigt werden müssen.
Informationen zum Risiko der Skripteinschleusung Beim Erstellen von Workflows, benutzerdefinierten Aktionen und zusammengesetzten Aktionen solltest du immer überprüfen, ob dein Code gegebenenfalls nicht vertrauenswürdige Eingaben von Angreifer*innen ausführen kann.
Dies kann passieren, wenn Angreifer*innen bösartige Befehle und Skripts zu einem Kontext hinzufügen.
Bei der Ausführung deines Workflows werden diese Zeichenfolgen möglicherweise als Code interpretiert, der dann im Runner ausgeführt wird.
Angreifer*innen können dem github-Kontext eigene bösartige Inhalte hinzufügen, die als potenziell nicht vertrauenswürdige Eingaben behandelt werden sollten. Diese Kontexte enden üblicherweise auf body, default_branch, email, head_ref, label, message, name, page_name,ref und title. Beispiel: github.event.issue.title oder github.event.pull_request.body
Du solltest sicherstellen, dass diese Werte nicht direkt in Workflows, Aktionen, API-Aufrufen oder an anderen Stellen eingefügt werden, an denen sie als ausführbarer Code interpretiert werden können. Indem du denselben defensiven Programmieransatz wie bei anderem privilegiertem Anwendungscode verwendest, kannst du zur Sicherheitshärtung bei der Verwendung von GitHub Actions beitragen. Informationen zu möglichen Schritten, die Angreifer*innen ausführen können, findest du unter .
Darüber hinaus gibt es weitere weniger offensichtliche Quellen für potenziell nicht vertrauenswürdige Eingaben. Dazu zählen z. B. Verzweigungsnamen und E-Mail-Adressen, die in Bezug auf ihre zulässigen Inhalte ziemlich flexibel sein können. zzz";echo${IFS}"hello";# ist beispielsweise ein zulässiger Verzweigungsname, der ein möglicher Angriffsvektor für ein Zielrepository wäre. In den folgenden Abschnitten wird erläutert, wie du das Risiko der Skripteinschleusung verringern kannst.
Beispiel für einen Angriff durch Skripteinschleusung Ein Angriff durch Skripteinschleusung kann direkt innerhalb des Inlineskripts eines Workflows auftreten.
Im folgenden Beispiel verwendet eine Aktion einen Ausdruck, um die Gültigkeit eines Pull Request-Titels zu testen. Dies geht jedoch mit dem Risiko der Skripteinschleusung einher:
Bei diesem Beispiel besteht das Risiko der Skripteinschleusung, da der Befehl run innerhalb eines temporären Shellskripts im Runner ausgeführt wird.
Vor der Ausführung des Shellskripts werden die Ausdrücke innerhalb von ${{ }} ausgewertet und anschließend durch die resultierenden Werte ersetzt. Bei diesem Vorgang besteht die Möglichkeit, dass Shellbefehle eingeschleust werden.
- name: Check PR title
run: |
title="$"
if [[ $title =~ ^octocat ]]; then
echo "PR title starts with 'octocat'"
exit 0
else
echo "PR title did not start with 'octocat'"
exit 1
fi
Angreifer*innen könnten einen Pull Request mit dem Titel a"; ls $GITHUB_WORKSPACE" erstellen, um Befehle in diesem Workflow einzuschleusen:
Beispiel für die Skripteinschleusung im Titel eines Pull Requests In diesem Beispiel wird die title="${{ github.event.pull_request.title }}"-Anweisung mithilfe des Zeichens " unterbrochen, damit der Befehl ls im Runner ausgeführt werden kann.
Die Ausgabe des Befehls ls erscheint im Protokoll:
Bewährte Methoden zum Verhindern von Angriffen durch Skripteinschleusung Es gibt verschiedene Ansätze, um das Risiko der Skripteinschleusung zu verhindern:
Bei dieser empfohlenen Vorgehensweise erstellst du eine 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:
Verwenden einer Zwischenumgebungsvariable
Bei Inlineskripts sollte der Wert des Ausdrucks auf eine Zwischenumgebungsvariable festgelegt werden, um nicht vertrauenswürdige Eingaben zu verhindern.
uses: fakeaction/checktitle@v3
with:
title: $
Im folgenden Beispiel wird Bash verwendet, um den github.event.pull_request.title-Wert als Umgebungsvariable zu verarbeiten:
In diesem Beispiel ist der Versuch der Skripteinschleusung nicht erfolgreich:
Beispiel für eine nicht erfolgreiche Skripteinschleusung
- name: Check PR title
env:
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
Bei dieser Vorgehensweise wird der Wert des ${{ github.event.issue.title }}-Ausdrucks im Arbeitsspeicher gespeichert und als Variable verwendet. Es findet keine Interaktion mit dem Skriptgenerierungsprozess statt.
Darüber hinaus solltest du gegebenenfalls Shellvariablen mit doppelten Anführungszeichen verwenden, um eine Wortteilung zu vermeiden. Dies ist jedoch eine der vielen allgemeinen Empfehlungen zum Schreiben von Shellskripts, die nicht speziell für GitHub Actions gilt.
