Referenz zur sicheren Verwendung

Hier findest du Informationen zu Best Practices zur Sicherheit, wenn du Workflows schreibst und GitHub Actions-Sicherheitsfeatures verwendest.

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. Maskiere alle vertraulichen Informationen, bei denen es sich nicht um ein GitHub-Geheimnis handelt, mithilfe von ::add-mask::VALUE. 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**
  

  • Das Entfernen 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 geschwärztes Geheimnis in ein Workflow-Ausführungsprotokoll gesendet wird, sollten Sie das Protokoll löschen und das Geheimnis erneuern. Informationen zum Löschen von Protokollen findest du unter Verwenden von Workflowausführungsprotokollen.

•         **Verwende niemals strukturierte Daten als Geheimnis**
  

  • Bei strukturierten Daten kann die Geheimnisentfernung innerhalb von Protokollen fehlschlagen, da die Redaktion größtenteils davon abhängt, 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 dieser Vorgehensweise wird der Wert des ${{ github.event.pull_request.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.

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ürdiger 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 Anleitungen zu den Risiken des Auscheckens von nicht vertrauenswürdigem Code finden Sie unter Verhindern von pwn-Anforderungen von GitHub Security Lab und in der Dangerous-Workflow-Dokumentation von OpenSSF Scorecard.

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 überprüfen und erkennen. Du kannst das Standardsetup für das Repository so konfigurieren, dass GitHub Actions-Überprüfung aktiviert ist. Weitere Informationen finden Sie unter Konfigurieren des Standardsetups für das Code-Scanning.

• OpenSSF Scorecards kann dir helfen, potenziell anfällige Workflows und weitere Sicherheitsrisiken zu identifizieren, wenn du GitHub Actions verwendest. 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. Daher besteht ein erhebliches Risiko beim Bezug von Aktionen aus Drittanbieterrepositorys in 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 vollständigen Commit SHA ist derzeit die einzige Möglichkeit, eine Aktion als unveränderliche Version zu verwenden. Durch das Festlegen auf einen bestimmten SHA wird das Risiko von Angriffen verringert, da dadurch verhindert wird, dass ein Angreifer eine Hintertür zum Repository der Aktion hinzufügen kann. Hierfür müsste er eine SHA-1-Kollision für eine gültige Git-Objekt-Payload generieren. 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 der Ebene von Repository, Organisation und Unternehmen, um festzuschreiben, dass Aktionen an einen vollständigen Commit-SHA gebunden werden müssen:

  • Informationen zum Konfigurieren der Richtlinie auf Repositoryebene findest du unter Verwalten von GitHub Actions-Einstellungen für ein Repository.
  • Informationen zum Konfigurieren der Richtlinie auf Organisationsebene findest du unter GitHub Actions für deine Organisation Deaktivieren oder Einschränken.

•         **Überprüfe den Quellcode der Aktion**
  

  Stelle sicher, dass die Aktion den Inhalt deines Repositorys und deine Geheimnisse wie erwartet verarbeitet. Überprüfe beispielsweise, ob Geheimnisse nicht an unbeabsichtigte Hosts gesendet oder nicht versehentlich protokolliert werden.

•         **Hefte Aktionen nur dann an Tags, wenn du den Ersteller als vertrauenswürdig einstufst**
  

  Wenngleich das Festlegen auf einen Commit-SHA die sicherste Möglichkeit ist, ist das Angeben eines Tags bequemer und eine weit verbreitete Vorgehensweise. Wenn du ein Tag angeben möchtest, solltest du sicherstellen, dass du den Erstellern der Aktion vertraust. Der Badge für überprüfte Ersteller in GitHub Marketplace zeigt an, dass die Aktion von einem Team erstellt wurde, dessen Identität von GitHub überprüft und bestätigt wurde. Beachte, dass diese Vorgehensweise auch dann ein Risiko birgt, wenn der oder die Erstellerin als vertrauenswürdig eingestuft wird. Der Grund dafür ist, dass ein Tag verschoben oder gelöscht werden kann, wenn eine böswilliger Akteurin Zugriff auf das Repository erhält, in dem die Aktion gespeichert ist.

Wiederverwenden von Drittanbieterworkflows

Die oben beschriebenen Grundsätze für die Verwendung von Drittanbieteraktionen gelten auch für die Verwendung von Drittanbieterworkflows. Wende die oben beschriebenen bewährten Methoden auch bei Workflows an, um die Risiken bei der Wiederverwendung von Workflows zu verringern. Weitere Informationen finden Sie unter Wiederverwenden von Workflows.

Sicherheitsfeatures von GitHub

GitHub bietet viele Features, um Ihren Code sicherer zu machen. Sie können die integrierten Funktionen von GitHub verwenden, um die Aktionen zu verstehen, von denen Ihre Workflows abhängen, um sicherstellen, dass Sie über Sicherheitsrisiken in den von Ihnen genutzten Aktionen benachrichtigt werden oder um den Prozess der Aufbewahrung der Aktionen in Ihren Workflows auf dem neuesten Stand halten. Wenn Sie Aktionen veröffentlichen und beibehalten, können Sie GitHub verwenden, um mit Ihrer Community über Sicherheitsrisiken zu kommunizieren und wie Sie diese beheben können. Weitere Informationen zu Sicherheitsfeatures, die von GitHub angeboten werden, findest du unter GitHub-Sicherheitsfeatures.

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. unter .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.

Weitere Informationen finden Sie unter Informationen zu Codeinhabern.

Die Verwaltung von Berechtigungen für GitHub Actions-Einstellungen in Ihrer Organisation.

Sie können das Prinzip der geringsten Rechte für die CI/CD-Pipeline Ihrer Organisation mit GitHub Actions ausüben, indem Sie benutzerdefinierte Organisationsrollen verwalten. Eine benutzerdefinierte Organisationsrolle ist eine Möglichkeit, einer Einzelperson oder einem Team in Ihrer Organisation die Möglichkeit zu geben, bestimmte Untergruppen von Einstellungen zu kontrollieren, ohne ihnen die volle administrative Kontrolle über die Organisation und ihre Repositorys zu gewähren.

Für GitHub Actions können Sie eine der folgenden Berechtigungen für Einzelpersonen oder Teams in Ihrer Organisation aktivieren.

• Verwalten von Organisations-Action-Richtlinien: Zugriff auf alle Einstellungen auf der Seite „Allgemeine Aktionen“, mit Ausnahme von selbstgehosteten Runnereinstellungen.
• Verwalten von Organisationsrunnern und Runnergruppen: Zugriff zum Erstellen und Verwalten von GitHub-gehosteten Runnern, selbstgehosteten Runnern und Runnergruppen sowie Kontrolle, wo selbstgehostete Runner erstellt werden können.
• Organisationsaktionengeheimnisse verwalten: Zugriff zum Erstellen und Verwalten von Aktionenorganisationsgeheimnissen.
• Organisationsaktionenvariablen: Zugriff zum Erstellen und Verwalten von Aktionenorganisationsvariablen.

Weitere Informationen finden Sie unter Informationen zu benutzerdefinierten Organisationsrollen.

Verwenden von OpenID Connect für den Zugriff auf Cloudressourcen

Wenn deine GitHub Actions-Workflows auf Ressourcen eines Cloudanbieters zugreifen müssen, der OpenID Connect (OIDC) unterstützt, kannst du deine Workflows so konfigurieren, dass die Authentifizierung direkt beim Cloudanbieter erfolgt. Dadurch musst du diese Anmeldeinformationen nicht mehr als langlebige Geheimnisse speichern und profitierst zudem von weiteren Sicherheitsvorteilen. Weitere Informationen finden Sie unter OpenID Connect.

Verwenden von Dependabot version updates, um Aktionen auf dem neuesten Stand zu halten

Mithilfe von Dependabot können Sie sicherstellen, dass Verweise auf Aktionen und wiederverwendbare Workflows im Repository auf dem neuesten Stand bleiben. Aktionen werden häufig mit Fehlerkorrekturen und neuen Features aktualisiert, um automatisierte Prozesse schneller, sicherer und zuverlässiger zu machen. Dependabot vereinfachen die Verwaltung deiner Abhängigkeiten, da es dies automatisch für dich erledigt. Weitere Informationen findest du unter Deine Aktionen mit Dependabot auf dem neuesten Stand halten und Informationen zu Dependabot-Sicherheitsupdates.

Verhindern, dass GitHub Actions Pullanforderungen erstellen oder genehmigen

Du kannst zulassen oder verhindern, dass GitHub Actions-Workflows Pull Requests erstellen oder genehmigen. Wenn du Workflows oder anderen Automatisierungen erlaubst, Pull Requests zu erstellen oder zu genehmigen, könnte dies ein Sicherheitsrisiko darstellen, falls die Pull Requests ohne angemessene Aufsicht zusammengeführt werden.

Weitere Informationen zum Konfigurieren dieser Einstellung findest du unter Erzwingen von Richtlinien für GitHub Actions in deinem Unternehmen, Deaktivieren oder Einschränken von GitHub Actions für deine Organisation und Verwalten von GitHub Actions-Einstellungen für ein Repository.

Verwenden von code scanning zum Sichern von Workflows

Code scanning kann in GitHub Actions-Workflows automatisch häufige Muster mit Risiken erkennen und Verbesserungen vorschlagen. Weitere Informationen zum Aktivieren von code scanning findest du unter Konfigurieren des Standardsetups für das Code-Scanning.

Verwenden von OpenSSF-Scorecards zum Sichern von Workflowabhängigkeiten

          [Scorecards](https://github.com/ossf/scorecard) sind ein automatisiertes Sicherheitstool, mit dem Lieferkettenaktionen gekennzeichnet werden, die ein Risiko bergen. Sie können die [Scorecards-Aktion](https://github.com/marketplace/actions/ossf-scorecard-action) und [Workflowvorlagen](https://github.com/actions/starter-workflows) nutzen, um bewährte Sicherheitsmethoden anzuwenden. Nach der Konfiguration wird die Scorecards-Funktion bei Änderungen im Repository automatisch ausgeführt, und Entwickler*innen werden mithilfe der integrierten code scanning-Erfahrung auf riskante Lieferkettenpraktiken hingewiesen. Das Scorecards-Projekt führt eine Reihe von Überprüfungen aus, mit denen u. a. Angriffe durch Skripteinschleusung, Tokenberechtigungen und festgelegte Aktionen ermittelt und untersucht werden.

Härtung für GitHub-gehosteten Runner

Github-gehostete Runner für Unternehmen

Härtung für selbstgehostete Runner

In

Selbstgehostete Runner für GitHub bieten keine Garantien bezüglich der Ausführung auf kurzlebigen bereinigten virtuellen Computern und können durch nicht vertrauenswürdigen Code in einem Workflow dauerhaft kompromittiert werden.

Gehe mit Bedacht vor, wenn du selbstgehostete Runner für private oder interne Repositorys verwendest. In diesem Fall können alle Benutzerinnen, die das Repository forken und Pull Requests starten können (üblicherweise Benutzerinnen mit Lesezugriff auf das Repository), die selbstgehostete Runnerumgebung kompromittieren. Dabei kann u. a. auf Geheimnisse und das GITHUB_TOKEN zugegriffen werden, über das abhängig von den Einstellungen Schreibzugriff auf das Repository gewährt werden kann. Wenngleich der Zugriff auf Umgebungsgeheimnisse in Workflows durch die Verwendung von Umgebungen und erforderlichen Prüfungen gesteuert werden kann, werden diese Workflows nicht in einer isolierten Umgebung ausgeführt. Folglich müssen bei Ausführung in einem selbstgehosteten Runner dieselben Risiken berücksichtigt werden.

Unternehmens- und Organisationsbesitzer*innen können wählen, für welche Repositorys die Erstellung selbstgehosteter Runner auf Repositoryebene erlaubt ist. Benutzer mit der Berechtigung „Verwalten von Organisationsrunnern und Runnergruppen“ können nur auswählen, welche Repositorys selbstgehostete Runner auf Repositoryebene für Repositorys in deiner Organisation erstellen dürfen.

Weitere Informationen zu benutzerdefinierten Organisationsrollen findest du unter Informationen zu benutzerdefinierten Organisationsrollen.

Weitere Informationen findest du unter Erzwingen von Richtlinien für GitHub Actions in deinem Unternehmen und unter GitHub Actions für deine Organisation Deaktivieren oder Einschränken.

Wenn ein selbstgehosteter Runner auf Organisations- oder Unternehmensebene definiert wird, kann GitHub Workflows aus mehreren Repositorys auf demselben Runner planen. Sicherheitslücken oder Angriffe in diesen Umgebungen können also weitreichende Auswirkungen haben. Um den Umfang eines Kompromisses zu reduzieren, können Sie Grenzen setzen, indem Sie Ihre selbstgehosteten Runner in separate Gruppen organisieren. Dabei kannst du einschränken, welche Workflows, Organisationen und Repositories Zugriff auf Runnergruppen haben können. Weitere Informationen finden Sie unter Verwalten des Zugriffs auf selbstgehostete Runner mithilfe von Gruppen.

Außerdem solltest du die Umgebung der Computer des selbstgehosteten Runners berücksichtigen:

• Welche vertraulichen Informationen befinden sich auf dem Computer, der als selbstgehosteter Runner konfiguriert ist? Diese Informationen können z. B. private SSH-Schlüssel, API-Zugriffstoken usw. umfassen.
• Verfügt der Computer über Netzwerkzugriff auf vertrauliche Dienste? Dazu können z. B. Azure- oder AWS-Metadatendienste zählen. Die Menge an vertraulichen Informationen in dieser Umgebung sollte auf ein Minimum beschränkt werden. Du solltest immer bedenken, dass alle Benutzer*innen, die Workflows aufrufen können, Zugriff auf diese Umgebung haben.

Einige Kunden versuchen möglicherweise, diese Risiken zu mindern, indem sie Systeme implementieren, die den selbstgehosteten Runner nach jeder Auftragsausführung automatisch zerstören. Dieser Ansatz ist jedoch gegebenenfalls nicht so effektiv wie gewünscht, da nicht sichergestellt werden kann, dass ein selbstgehosteter Runner nur einen Auftrag ausführt. Einige Aufträge verwenden Geheimnisse als Befehlszeilenargumente, die für einen anderen Auftrag sichtbar sind, der im selben Runner ausgeführt wird (z. B. ps x -w). Folglich kann es zur Offenlegung von Geheimnissen kommen.

Verwenden von Just-In-Time-Runnern

Um die Sicherheit bei der Runnerregistrierung zu verbessern, kannst du die REST-API verwenden, um kurzlebige Just-In-Time (JIT)-Runner zu erstellen. Diese selbstgehosteten Runner führen höchstens einen Auftrag aus, bevor sie automatisch aus dem Repository, der Organisation oder dem Unternehmen entfernt werden. Weitere Informationen zum Konfigurieren von JIT-Runnern findest du unter REST-API-Endpunkte für selbst gehostete Runner.

Sobald du die Konfigurationsdatei aus der REST-API-Antwort erhalten hast, kannst du sie beim Start an den Runner übergeben.

./run.sh --jitconfig ${encoded_jit_config}

Planung Ihrer Managementstrategie für selbstgehostete Läufer

Selbstgehostete Runner können auf verschiedenen Ebenen in deiner GitHub-Hierarchie hinzugefügt werden: auf Unternehmens-, Organisations- oder Repositoryebene. Durch diese Platzierung wird festgelegt, wer einen Runner verwalten kann:

          **Zentrale Verwaltung:**

• Wenn ein zentrales Team die selbstgehosteten Runner verwalten soll, solltest du deine Runner auf der höchsten gemeinsamen Organisations- oder Unternehmensebene hinzufügen. Dadurch kann dein Team deine Runner in einer zentralen Ansicht anzeigen und verwalten.

• Wenn du nur über eine einzige Organisation verfügst, ist das Hinzufügen deiner Runner auf Organisationsebene der gleiche Ansatz. Dabei kann es jedoch zu Problemen kommen, wenn du zu einem späteren Zeitpunkt eine weitere Organisation hinzufügst.

          **Dezentrale Verwaltung:**
  

• Wenn jedes Team seine eigenen selbstgehosteten Runner verwalten wird, sollten die Runner unter der höchsten Verantwortungsebene des Teams hinzugefügt werden. Beispiel: Wenn jedes Team über eine eigene Organisation verfügt, ist es am einfachsten, die Runner ebenfalls auf Organisationsebene hinzuzufügen.

• Die Runner können auch auf Repositoryebene hinzugefügt werden. Da Runner in diesem Fall jedoch nicht von mehreren Repositorys gleichzeitig verwendet werden können, erhöht sich der Verwaltungsaufwand, und du benötigst eine größere Anzahl von Runnern.

Authentifizieren bei deinem Cloudanbieter

Wenn du GitHub Actions für die Bereitstellung bei einem Cloudanbieter verwendest oder beabsichtigst, HashiCorp Vault für die Verwaltung von Geheimnissen einzusetzen, solltest du die Verwendung von OpenID Connect in Betracht ziehen, um kurzlebige Zugriffstoken mit sorgfältig definiertem Gültigkeitsbereich für deine Workflowausführungen zu erstellen. Weitere Informationen finden Sie unter OpenID Connect.

Überwachen von GitHub Actions-Ereignissen

Du kannst das Sicherheitsprotokoll verwenden, um Aktivitäten für dein Benutzerkonto zu überwachen, und das Überwachungsprotokoll, um Aktivitäten in deiner Organisation oder deinem Unternehmen zu überwachen. Das Sicherheits- und das Überwachungsprotokoll zeichnen die Art der Aktion, den Zeitpunkt der Ausführung sowie das persönliche Konto auf, das die Aktion ausgeführt hat.

So kannst du das Überwachungsprotokoll z. B. zum Aufzeichnen des org.update_actions_secret-Ereignisses verwenden, mit dem Änderungen an Organisationsgeheimnissen nachverfolgt werden.

Die vollständige Liste der Ereignisse, die Sie im Überwachungsprotokoll für die einzelnen Kontotypen finden können, finden Sie in den folgenden Artikeln:

•         [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/security-log-events)
  

•         [AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/audit-log-events-for-your-organization)
  

Grundlegendes zu Abhängigkeiten in Ihren Workflows

Sie können die Abhängigkeitsdiagramm verwenden, um die Aktionen zu untersuchen, die die Workflows in Ihrem Repository verwenden. Das Abhängigkeitsdiagramm ist eine Zusammenfassung der in einem Repository gespeicherten Manifest- und Sperrdateien. Es erkennt auch Dateien in ./github/workflows/ als Manifeste, was bedeutet, dass alle Aktionen oder Workflows, auf die mithilfe der Syntax jobs[*].steps[*].uses oder jobs.<job_id>.uses verwiesen wird, als Abhängigkeiten geparst werden.

Die Abhängigkeitsdiagramm zeigt die folgenden Informationen zu Aktionen, die in Workflows verwendet werden:

• Das Konto oder die Organisation, das die Aktion besitzt.
• Die Workflowdatei, die auf die Aktion verweist.
• Die Version oder SHA, an die die Aktion angeheftet ist.

In dem Abhängigkeitsdiagramm werden Abhängigkeiten automatisch nach dem Sicherheitsrisikoschweregrad sortiert. Wenn eine der von Ihnen verwendeten Aktionen Sicherheitsempfehlungen enthält, werden sie oben in der Liste angezeigt. Sie können über die Abhängigkeitsdiagramm zur Empfehlung navigieren und auf Anweisungen zum Beheben der Sicherheitsanfälligkeit zugreifen.

Unternehmensbesitzer können das Abhängigkeitsdiagramm und Dependabot alerts für ein Unternehmen konfigurieren. Weitere Informationen findest du unter Aktivieren des Abhängigkeitsdiagramms für dein Unternehmen.

Sich der Sicherheitsrisiken in den von Ihnen verwendeten Aktionen bewusst sein

Für Aktionen, die auf dem Marketplace verfügbar sind, überprüft GitHub verwandte Sicherheitsempfehlungen und fügt diese Empfehlungen dann GitHub Advisory Database hinzu. Sie können die Datenbank nach Aktionen durchsuchen, die Sie verwenden, um Informationen zu vorhandenen Sicherheitsrisiken und Anweisungen zur Behebung zu finden. Verwenden Sie zum Optimieren der Suche den Filter GitHub Actions in GitHub Advisory Database.

Sie können Ihre Repositorys so einrichten, dass Sie:

• Erhalten Sie Warnungen, wenn Aktionen, die in Ihren Workflows verwendet werden, einen Sicherheitsrisikobericht erhalten. Weitere Informationen findest du unter Überwachen der Aktionen in deinen Workflows.
• Werden vor vorhandenen Empfehlungen gewarnt, wenn Sie eine Aktion in einem Workflow hinzufügen oder aktualisieren. Weitere Informationen findest du unter Überprüfen von Aktionen auf Sicherheitsrisiken in neuen oder aktualisierten Workflows.

Überwachen der Aktionen in Ihren Workflows

Sie können Dependabot verwenden, um die Aktionen in Ihren Workflows zu überwachen und Dependabot alerts zu aktivieren, um Sie zu benachrichtigen, wenn eine von Ihnen verwendete Aktion eine gemeldete Sicherheitsanfälligkeit aufweist. Dependabot führt eine Überprüfung der Standardbranch der Repositorys durch, in denen es aktiviert ist, um unsichere Abhängigkeiten zu erkennen. Dependabot generiert Dependabot alerts, wenn ein neuer Hinweis zu GitHub Advisory Database hinzugefügt wird oder wenn eine von Ihnen verwendete Aktion aktualisiert wird.

Ein Unternehmensbesitzer muss zuerst Dependabot für dein Unternehmen einrichten, bevor du Dependabot alerts für dein Repository verwalten kannst. Weitere Informationen findest du unter Aktivieren von Dependabot für dein Unternehmen.

Sie können alle offenen und geschlossenen Dependabot alerts und entsprechenden Dependabot security updates im Dependabot alerts-Reiter Ihres Repositorys sehen. Weitere Informationen findest du unter Anzeigen und Aktualisieren von Dependabot-Warnungen.

Überprüfen von Aktionen auf Sicherheitsrisiken in neuen oder aktualisierten Workflows

Wenn Sie Pull Requests öffnen, um Ihre Workflows zu aktualisieren, empfiehlt es sich, Abhängigkeitsüberprüfungen zu verwenden, um die Sicherheitswirkungen von Änderungen zu verstehen, die Sie an den von Ihnen verwendeten Aktionen vorgenommen haben. Die Abhängigkeitsüberprüfung hilft Dir, Abhängigkeitsänderungen und die Sicherheitswirkung dieser Änderungen bei jedem Pull Request zu verstehen. Sie bietet eine leicht verständliche Visualisierung von Abhängigkeitsänderungen mit Rich-Diff auf der Registerkarte „Geänderte Dateien“ eines Pull Requests. Die Abhängigkeitsüberprüfung informiert Dich über:

• Welche Abhängigkeiten hinzugefügt, entfernt oder aktualisiert wurden, sowie die Releasedaten
• Wie viele Projekte diese Komponenten verwenden
• Sicherheitsrisikodaten für diese Abhängigkeiten

Wenn Änderungen, die Sie an Ihren Workflows vorgenommen haben, als anfällig gekennzeichnet sind, können Sie es vermeiden, sie zu Ihrem Projekt hinzuzufügen oder auf eine sichere Version zu aktualisieren.

Weitere Informationen zur Abhängigkeitsbewertung findest du unter Informationen zur Abhängigkeitsüberprüfung.

„Abhängigkeitsüberprüfungsaktion“ bezieht sich auf die spezifische Aktion, die Unterschiede in einem Pull Request innerhalb des GitHub Actions-Kontext melden kann. Siehe dependency-review-action. Du kannst die Abhängigkeitsüberprüfungsaktion in deinem Repository verwenden, um Abhängigkeitsüberprüfungen bei deinen Pull Requests zu erzwingen. Die Aktion sucht nach anfälligen Versionen von Abhängigkeiten, die durch Paketversionsänderungen in Pull Requests eingeführt wurden, und warnt dich vor den damit verbundenen Sicherheitsrisiken. So erhältst du einen besseren Überblick darüber, was sich in einem Pull Request ändert, und kannst verhindern, dass deinem Repository Sicherheitsrisiken hinzugefügt werden. Weitere Informationen findest du unter Informationen zur Abhängigkeitsüberprüfung.

Aktionen in Ihren Workflows sichern und auf dem neuesten Stand halten

Mithilfe von Dependabot können Sie sicherstellen, dass Verweise auf Aktionen und wiederverwendbare Workflows im Repository auf dem neuesten Stand bleiben. Aktionen werden häufig mit Fehlerkorrekturen und neuen Features aktualisiert, um automatisierte Prozesse schneller, sicherer und zuverlässiger zu machen. Dependabot vereinfachen die Verwaltung deiner Abhängigkeiten, da es dies automatisch für dich erledigt. Weitere Informationen findest du unter Deine Aktionen mit Dependabot auf dem neuesten Stand halten und Informationen zu Dependabot-Sicherheitsupdates.

Die folgenden Features können die Aktionen in Ihren Workflows automatisch aktualisieren.

•         **Dependabot version updates** Öffnen Sie Pull Requests, um Aktionen auf die neueste Version zu aktualisieren, wenn eine neue Version veröffentlicht wird.
  

•         **Dependabot security updates** öffnen Sie Pull Requests, um Aktionen mit gemeldeten Sicherheitsrisiken auf die niedrigste erforderliche Patch-Version zu aktualisieren.
  

Weitere Informationen zum Konfigurieren von Dependabot version updates findest du unter Konfigurieren von Dependabot-Versionsupdates.

Weitere Informationen zum Konfigurieren von Dependabot security updates findest du unter Konfigurieren von Dependabot-Sicherheitsupdates.