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.

Verwenden von Workflowvorlagen für code scanning

Code scanning ermöglicht es, Sicherheitsrisiken zu finden, bevor sie die Produktion erreichen. GitHub bietet Workflow-Vorlagen für code scanning. Sie können die vorgeschlagenen Workflows verwenden, um Ihre Workflows zur code scanning zu erstellen, anstatt bei null zu beginnen. Der Workflow von GitHub, der CodeQL-Analyseworkflow, basiert auf CodeQL. Es stehen auch Workflowvorlagen von Drittanbietern zur Verfügung.

Weitere Informationen findest du unter Informationen zu Codescans und Konfigurieren des erweiterten Setups für das Code-Scanning.

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.

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 und Organisation, 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.

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

GitHub-gehostete Läufer ergreifen Maßnahmen zur Minimierung von Sicherheitsrisiken.

Überprüfung der Lieferkette für von GitHub gehostete Runner

Für GitHub-gehostete Runner, die aus von GitHub unterstützten Bildern erstellt werden, kannst du eine Software-Stückliste (Software Bill of Materials, SBOM) anzeigen, um zu sehen, welche Software auf dem Runner vorinstalliert war. Sie können Ihren Benutzern das SBOM zur Verfügung stellen, damit sie mit einem Schwachstellen-Scanner überprüfen können, ob im Produkt Sicherheitsrisiken vorliegen. Die SBOM kann in die Materialliste einbezogen werden, wenn Sie Artefakte erstellen, um eine umfassende Liste von allem zu erhalten, was zur Erstellung Ihrer Software beigetragen hat.

SBOMs sind für Ubuntu-, Windows- und macOS-Runner-Bilder verfügbar, die von GitHub gewartet werden. Sie finden die SBOM für Ihren Build in den Freigabe-Assets unter https://github.com/actions/runner-images/releases. Eine SBOM mit einem Dateinamen im Format sbom.IMAGE-NAME.json.zip finden Sie in den Anhängen der einzelnen Releases.

Für Bilder von Drittanbietern, z. B. die Bilder für ARM-gesteuerte Runner, findest du Details zur im Bild inkludierten Software im actions/partner-runner-images-Repository.

Verweigern des Zugriffs auf Hosts

GitHubgehostete Läufer werden mit einer etc/hosts Datei bereitgestellt, die den Netzwerkzugriff auf verschiedene Kryptowährungs-Miningpools und bösartige Websites blockiert. Hosts wie MiningMadness.com und cpu-pool.com werden an localhost umgeleitet, sodass sie kein erhebliches Sicherheitsrisiko darstellen. Weitere Informationen findest du unter Von GitHub gehostete Runner.

Härtung für selbstgehostete Runner

In GitHub gehostete Runner führen Code innerhalb von kurzlebigen, bereinigten isolierten VMs aus. Diese Art von Umgebung kann also nicht dauerhaft kompromittiert werden. Auch ist kein Zugriff auf Informationen möglich, die über die Informationen hinausgehen, die während des Bootstrap-Prozesses in dieser Umgebung platziert wurden.

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.

Folglich sollten selbstgehostete Runner praktisch nie für öffentliche Repositorys auf GitHub verwendet werden, da alle Benutzenden Pull Requests für das Repository erstellen und die Umgebung kompromittieren können. Gehe ebenfalls 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.

Organisationsbesitzer*innen können wählen, für welche Repositorys die Erstellung selbstgehosteter Runner auf Repositoryebene erlaubt ist.

Weitere Informationen findest du 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 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 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.

Der Abhängigkeitsgraph wird für öffentlichen Repositorys aktiviert, und du kannst ihn auch für private Repositorys aktivieren. Weitere Informationen zum Verwenden des Abhängigkeitsdiagramms findest du unter Untersuchen der Abhängigkeiten eines Repositorys.

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.

Du kannst Dependabot alerts für dein persönliches Konto, für ein Repository oder für eine Organisation aktivieren. Weitere Informationen findest du unter Konfigurieren von Dependabot-Warnungen.

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.

Schützen von Aktionen, die Sie erstellt haben

GitHub ermöglicht die Zusammenarbeit zwischen Personen, die Aktionen veröffentlichen und verwalten, und Meldenden von Sicherheitsrisiken, um das Schreiben von sicherem Code zu fördern. Mithilfe von Sicherheitsempfehlungen für Repositorys können Verwalter*innen von öffentlichen Repositorys ein Sicherheitsrisiko in einem Projekt privat besprechen und beheben. Nach der Zusammenarbeit an einer Lösung können Repositoryverwalter die Sicherheitsempfehlung veröffentlichen, um das Sicherheitsrisiko öffentlich für die Community des Projekts offenzulegen. Durch die Veröffentlichung von Sicherheitsempfehlungen erleichtern Repositoryverwalter ihrer Community das Aktualisieren von Paketabhängigkeiten und das Untersuchen der Auswirkungen von Sicherheitsrisiken.

Wenn Sie jemand sind, der eine Aktion pflegt, die in anderen Projekten verwendet wird, können Sie die folgenden GitHub-Features verwenden, um die Sicherheit der veröffentlichten Aktionen zu verbessern.

• Verwenden Sie die Abhängigkeitsansicht im Abhängigkeitsdiagramm, um zu sehen, welche Projekte von Ihrem Code abhängen. Wenn Sie einen Sicherheitsrisikobericht erhalten, erhalten Sie eine Vorstellung davon, mit wem Sie über die Sicherheitsanfälligkeit kommunizieren müssen und wie Sie sie beheben können. Weitere Informationen finden Sie unter Untersuchen der Abhängigkeiten eines Repositorys.
• Verwenden Sie Sicherheitsrichtlinien des Repositorys, um eine Sicherheitsempfehlung zu erstellen. Arbeiten Sie privat zusammen, um die Sicherheitsanfälligkeit in einem temporären privaten Fork zu beheben. Veröffentlichen Sie schließlich eine Sicherheitsempfehlung, um Ihre Community über die Sicherheitsanfälligkeit zu benachrichtigen, sobald ein Patch veröffentlicht wurde. Weitere Informationen findest du unter Konfigurieren der Meldung privater Sicherheitsrisiken für ein Repository und Erstellen einer Sicherheitsempfehlung für ein Repository.