Translated ['src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-

src/pentesting-ci-cd/gitblit-security/README.md

@@ -0,0 +1,21 @@
+# Gitblit Безпека
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Що таке Gitblit
+
+Gitblit — це self‑hosted Git server, написаний на Java. Він може працювати як standalone JAR або в servlet containers і має вбудований SSH service (Apache MINA SSHD) для Git over SSH.
+
+## Теми
+
+- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#ref}}
+gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
+{{#endref}}
+
+## Посилання
+
+- [Gitblit project](https://gitblit.com/)
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md

@@ -0,0 +1,107 @@
+# Gitblit Вбудований обхід автентифікації SSH (CVE-2024-28080)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Коротко
+
+CVE-2024-28080 — це обхід автентифікації у вбудованому SSH-сервісі Gitblit через некоректне оброблення стану сесії при інтеграції з Apache MINA SSHD. Якщо обліковий запис користувача має принаймні один зареєстрований публічний SSH-ключ, атакувальник, який знає ім'я користувача та будь-який з його публічних ключів, може аутентифікуватися без приватного ключа і без пароля.
+
+- Вразливі: Gitblit < 1.10.0 (спостерігалося на 1.9.3)
+- Виправлено: 1.10.0
+- Умови для експлуатації:
+  - Git over SSH ввімкнено на інстанції
+  - Обліковий запис жертви має принаймні один зареєстрований публічний SSH-ключ у Gitblit
+  - Атакувальник знає ім'я користувача жертви та один з його публічних ключів (часто доступний, наприклад, https://github.com/<username>.keys)
+
+## Коренева причина (state leaks between SSH methods)
+
+У RFC 4252 public‑key authentication проходить у два етапи: сервер спочатку перевіряє, чи наданий public key прийнятний для username, і лише після challenge/response з підписом аутентифікує користувача. У MINA SSHD PublickeyAuthenticator викликається двічі: при прийнятті ключа (ще без підпису) і пізніше, коли клієнт повертає підпис.
+
+PublickeyAuthenticator у Gitblit мутував контекст сесії під час першого, до-підписного виклику, прив'язавши автентифікований UserModel до сесії та повернувши true ("key acceptable"). Коли автентифікація пізніше відкотилася до пароля, PasswordAuthenticator покладався на цей змінений стан сесії і короткозамикався, повернувши true без перевірки пароля. В результаті будь-який пароль (включно з порожнім) приймався після попередньої public‑key "acceptance" для того ж користувача.
+
+Загальний хибний потік:
+
+1) Клієнт пропонує username + public key (ще немає підпису)  
+2) Сервер визнає ключ таким, що належить користувачу, передчасно прив'язує користувача до сесії, повертає true ("acceptable")  
+3) Клієнт не може підписати (немає private key), тому автентифікація відкотилася до пароля  
+4) Password auth бачить, що користувач вже присутній у сесії, і безумовно повертає успіх
+
+## Покрокова експлуатація
+
+- Зберіть ім'я користувача жертви та один з його public keys:
+  - GitHub надає public keys за адресою https://github.com/<username>.keys
+  - Публічні сервери часто публікують authorized_keys
+- Налаштуйте OpenSSH так, щоб він передавав лише public half, через що генерація підпису зазнає невдачі, примушуючи відкат до пароля, при цьому все ще тригеруючи шлях прийняття public‑key на сервері.
+
+Example SSH client config (no private key available):
+```sshconfig
+# ~/.ssh/config
+Host gitblit-target
+HostName <host-or-ip>
+User <victim-username>
+PubkeyAuthentication yes
+PreferredAuthentications publickey,password
+IdentitiesOnly yes
+IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
+```
+Підключіться та натисніть Enter у запиті пароля (або введіть будь-який рядок):
+```bash
+ssh gitblit-target
+# or Git over SSH
+GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
+```
+Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state.
+
+Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
+
+## Impact
+
+- Повне видавання себе за будь‑якого користувача Gitblit, у якого є принаймні один зареєстрований SSH public key
+- Read/write access to repositories per victim’s permissions (source exfiltration, unauthorized pushes, supply‑chain risks)
+- Можливий адміністративний вплив при цілеспрямованій атакі на admin‑аккаунт
+- Pure network exploit; no brute force or private key required
+
+## Detection ideas
+
+- Перегляньте SSH logs на предмет послідовностей, де publickey спроба супроводжується успішною password authentication з порожнім або дуже коротким паролем
+- Шукайте потоки: publickey method пропонує неподтримуваний/непідходящий ключ, після чого одразу слідує успішна password authentication для того ж username
+
+## Mitigations
+
+- Upgrade to Gitblit v1.10.0+
+- До оновлення:
+- Disable Git over SSH on Gitblit, or
+- Обмежте мережевий доступ до SSH service, and
+- Monitor for suspicious patterns described above
+- Змініть/скасуйте облікові дані користувачів, якщо підозрюється compromise
+
+## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+
+Pattern: Якщо public‑key authenticator на сервері мутує стан користувача/сесії під час pre‑signature "key acceptable" фази, і інші authenticators (наприклад, password) довіряють цьому стану, то можна обійти автентифікацію шляхом:
+
+- Presenting a legitimate public key for the target user (no private key)
+- Forcing the client to fail signing so the server falls back to password
+- Supplying any password while the password authenticator short‑circuits on leaked state
+
+Practical tips:
+
+- Public key harvesting at scale: збирайте public keys з поширених джерел, таких як https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
+- Forcing signature failure (client‑side): вкажіть IdentityFile лише на .pub, встановіть IdentitiesOnly yes, залиште PreferredAuthentications так, щоб включав publickey, а потім password
+- MINA SSHD integration pitfalls:
+- PublickeyAuthenticator.authenticate(...) не повинен прив’язувати стан користувача/сесії до тих пір, поки post‑signature verification шлях не підтвердить підпис
+- PasswordAuthenticator.authenticate(...) не повинен робити висновок про успіх на основі будь‑якого стану, зміненого під час попереднього, неповного методу автентифікації
+
+Related protocol/design notes and literature:
+- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
+- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
+
+## References
+
+- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
+- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)
+- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/)
+- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html)
+- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252)
+
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Methodology
+# Pentesting CI/CD Методологія
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,99 +6,102 @@
 
 ## VCS
 
-VCS означає **Систему Контролю Версій**, ця система дозволяє розробникам **керувати своїм вихідним кодом**. Найбільш поширеною є **git**, і ви зазвичай знайдете компанії, які використовують його на одній з наступних **платформ**:
+VCS означає **систему контролю версій**, ця система дозволяє розробникам **керувати своїм вихідним кодом**. Найпоширеніша — **git**, і зазвичай компанії використовують її на одній з наступних **платформ**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
-- Хмарні провайдери (вони пропонують свої власні платформи VCS)
+- Gitblit
+- Провайдери хмар (вони пропонують власні VCS платформи)
+
 
 ## CI/CD Pipelines
 
-CI/CD пайплайни дозволяють розробникам **автоматизувати виконання коду** для різних цілей, включаючи створення, тестування та розгортання додатків. Ці автоматизовані робочі процеси **ініціюються конкретними діями**, такими як пуші коду, запити на злиття або заплановані завдання. Вони корисні для спрощення процесу від розробки до виробництва.
+CI/CD pipelines дозволяють розробникам **автоматизувати виконання коду** для різних цілей, включаючи збірку, тестування та розгортання додатків. Ці автоматизовані робочі процеси **тригеряться певними діями**, такими як push коду, pull request або заплановані завдання. Вони корисні для оптимізації процесу від розробки до продакшну.
 
-Однак ці системи потрібно **виконувати десь** і зазвичай з **привілейованими обліковими даними для розгортання коду або доступу до чутливої інформації**.
+Однак ці системи потрібно **дещо запускати десь**, і зазвичай з **привілейованими обліковими даними для деплою коду або доступу до чутливої інформації**.
 
-## VCS Pentesting Methodology
+## VCS Pentesting Методологія
 
 > [!NOTE]
-> Навіть якщо деякі платформи VCS дозволяють створювати пайплайни, у цьому розділі ми будемо аналізувати лише потенційні атаки на контроль вихідного коду.
+> Навіть якщо деякі VCS платформи дозволяють створювати pipelines для цього розділу, ми будемо аналізувати лише потенційні атаки на контроль над вихідним кодом.
 
-Платформи, які містять вихідний код вашого проекту, містять чутливу інформацію, і людям потрібно бути дуже обережними з правами, наданими всередині цієї платформи. Ось деякі поширені проблеми на платформах VCS, які зловмисник може зловживати:
+Платформи, що містять вихідний код вашого проєкту, містять чутливу інформацію, і потрібно дуже ретельно ставитися до прав, що надаються в цій платформі. Ось деякі поширені проблеми на VCS платформах, які може використати зловмисник:
 
-- **Leaks**: Якщо ваш код містить витоки в комітах, і зловмисник може отримати доступ до репозиторію (оскільки він є публічним або тому, що у нього є доступ), він може виявити витоки.
-- **Access**: Якщо зловмисник може **отримати доступ до облікового запису всередині платформи VCS**, він може отримати **більшу видимість і права**.
-- **Register**: Деякі платформи дозволяють зовнішнім користувачам створювати обліковий запис.
-- **SSO**: Деякі платформи не дозволяють користувачам реєструватися, але дозволяють будь-кому отримати доступ з дійсним SSO (тому зловмисник може використовувати свій обліковий запис github для входу, наприклад).
-- **Credentials**: Ім'я користувача + пароль, особисті токени, ssh ключі, Oauth токени, куки... є кілька видів токенів, які користувач може вкрасти, щоб отримати доступ до репозиторію.
-- **Webhooks**: Платформи VCS дозволяють генерувати вебхуки. Якщо вони **не захищені** невидимими секретами, **зловмисник може зловживати ними**.
-- Якщо секрету немає, зловмисник може зловживати вебхуком третьої сторони.
-- Якщо секрет у URL, те ж саме відбувається, і зловмисник також має секрет.
-- **Code compromise:** Якщо зловмисник має якийсь вид **доступу на запис** до репозиторіїв, він може спробувати **впровадити шкідливий код**. Щоб досягти успіху, йому може знадобитися **обійти захист гілок**. Ці дії можуть бути виконані з різними цілями на увазі:
-- Скомпрометувати основну гілку, щоб **скомпрометувати виробництво**.
-- Скомпрометувати основну (або інші гілки), щоб **скомпрометувати машини розробників** (оскільки вони зазвичай виконують тести, terraform або інші речі всередині репозиторію на своїх машинах).
-- **Скомпрометувати пайплайн** (перевірте наступний розділ).
+- **Leaks**: Якщо ваш код містить leak у комітах і нападник може отримати доступ до репозиторію (бо він публічний або бо він має доступ), він може виявити ці leak.
+- **Access**: Якщо нападник може **отримати доступ до облікового запису в VCS платформі**, він може здобути **більше видимості та прав**.
+- **Register**: Деякі платформи просто дозволяють зовнішнім користувачам створювати обліковий запис.
+- **SSO**: Деякі платформи не дозволяють реєстрацію, але дозволяють будь-кому увійти через дійсний SSO (тому нападник, наприклад, може використати свій github акаунт для входу).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... існує кілька типів токенів, які користувач може вкрасти, щоб у такий чи інший спосіб отримати доступ до репо.
+- **Webhooks**: VCS платформи дозволяють генерувати webhooks. Якщо вони **не захищені** невидимими секретами, **нападник може ними зловживати**.
+- Якщо секрету немає, нападник може зловживати webhook третьої сторони.
+- Якщо секрет знаходиться в URL, трапляється те саме і нападник також отримує секрет.
+- **Code compromise:** Якщо зловмисник має якийсь рівень **запису (write)** у репозиторіях, він може спробувати **інжектувати шкідливий код**. Щоб бути успішним, йому може знадобитися **обійти branch protections**. Ці дії можуть виконуватися з різними цілями:
+  - Скомпрометувати main branch, щоб **скомпрометувати production**.
+  - Скомпрометувати main (або інші branch) щоб **скомпрометувати машини розробників** (оскільки вони зазвичай виконують тести, terraform чи інше всередині репо на своїх машинах).
+- **Compromise the pipeline** (див. наступний розділ)
 
-## Pipelines Pentesting Methodology
+## Pipelines Pentesting Методологія
 
-Найпоширеніший спосіб визначити пайплайн - це використання **файлу конфігурації CI, розміщеного в репозиторії**, який будує пайплайн. Цей файл описує порядок виконуваних завдань, умови, які впливають на потік, і налаштування середовища збірки.\
-Ці файли зазвичай мають послідовну назву та формат, наприклад — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) та YAML файли GitHub Actions, розташовані під .github/workflows. Коли пайплайн ініціюється, завдання пайплайна **витягує код** з вибраного джерела (наприклад, коміт / гілка) і **виконує команди, зазначені у файлі конфігурації CI** проти цього коду.
+Найпоширеніший спосіб визначити pipeline — використати **CI configuration file, розміщений в репозиторії**, який збирається. Цей файл описує порядок виконуваних jobs, умови, що впливають на потік, та налаштування середовища збірки.\
+Ці файли зазвичай мають усталені імена й формати, наприклад — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), та GitHub Actions YAML файли в .github/workflows. Коли pipeline тригериться, job **забирає код** з обраного джерела (наприклад commit / branch) і **виконує команди, вказані в CI конфігураційному файлі**, над цим кодом.
 
-Отже, остаточною метою зловмисника є якимось чином **скомпрометувати ці файли конфігурації** або **команди, які вони виконують**.
+Отже кінцева мета нападника — якимось чином **скомпрометувати ці конфігураційні файли** або **команди, які вони виконують**.
 
 ### PPE - Poisoned Pipeline Execution
 
-Шлях Poisoned Pipeline Execution (PPE) експлуатує права в репозиторії SCM для маніпуляції CI пайплайном і виконання шкідливих команд. Користувачі з необхідними правами можуть змінювати файли конфігурації CI або інші файли, які використовуються завданням пайплайна, щоб включити шкідливі команди. Це "отруює" CI пайплайн, що призводить до виконання цих шкідливих команд.
+The Poisoned Pipeline Execution (PPE) path exploits permissions in an SCM repository to manipulate a CI pipeline and execute harmful commands. Users with the necessary permissions can modify CI configuration files or other files used by the pipeline job to include malicious commands. This "poisons" the CI pipeline, leading to the execution of these malicious commands.
 
-Щоб зловмисник успішно виконав атаку PPE, йому потрібно:
+For a malicious actor to be successful performing a PPE attack he needs to be able to:
 
-- Мати **доступ на запис до платформи VCS**, оскільки зазвичай пайплайни ініціюються, коли виконується пуш або запит на злиття. (Перевірте методологію пентестингу VCS для підсумку способів отримання доступу).
-- Зверніть увагу, що іноді **зовнішній PR вважається "доступом на запис"**.
-- Навіть якщо у нього є права на запис, йому потрібно бути впевненим, що він може **змінити файл конфігурації CI або інші файли, на які покладається конфігурація**.
-- Для цього йому може знадобитися мати можливість **обійти захист гілок**.
+- Have **write access to the VCS platform**, as usually pipelines are triggered when a push or a pull request is performed. (Check the VCS pentesting methodology for a summary of ways to get access).
+- Note that sometimes an **external PR count as "write access"**.
+- Even if he has write permissions, he needs to be sure he can **modify the CI config file or other files the config is relying on**.
+- For this, he might need to be able to **bypass branch protections**.
 
-Існує 3 варіанти PPE:
+There are 3 PPE flavours:
 
-- **D-PPE**: Атака **Direct PPE** відбувається, коли зловмисник **змінює файл конфігурації CI**, який буде виконано.
-- **I-DDE**: Атака **Indirect PPE** відбувається, коли зловмисник **змінює** **файл**, на який **посилається** файл конфігурації CI, що буде виконано (наприклад, файл make або конфігурацію terraform).
-- **Public PPE або 3PE**: У деяких випадках пайплайни можуть бути **ініційовані користувачами, які не мають доступу на запис у репозиторії** (і які можуть навіть не бути частиною організації), оскільки вони можуть надіслати PR.
-- **3PE Command Injection**: Зазвичай CI/CD пайплайни **встановлюють змінні середовища** з **інформацією про PR**. Якщо це значення може контролюватися зловмисником (наприклад, заголовок PR) і **використовується** в **небезпечному місці** (наприклад, виконуючи **sh команди**), зловмисник може **впроваджувати команди туди**.
+- **D-PPE**: A **Direct PPE** attack occurs when the actor **modifies the CI config** file that is going to be executed.
+- **I-DDE**: An **Indirect PPE** attack occurs when the actor **modifies** a **file** the CI config file that is going to be executed **relays on** (like a make file or a terraform config).
+- **Public PPE or 3PE**: In some cases the pipelines can be **triggered by users that doesn't have write access in the repo** (and that might not even be part of the org) because they can send a PR.
+- **3PE Command Injection**: Usually, CI/CD pipelines will **set environment variables** with **information about the PR**. If that value can be controlled by an attacker (like the title of the PR) and is **used** in a **dangerous place** (like executing **sh commands**), an attacker might **inject commands in there**.
 
 ### Exploitation Benefits
 
-Знаючи 3 варіанти отруєння пайплайна, давайте перевіримо, що зловмисник може отримати після успішної експлуатації:
+Knowing the 3 flavours to poison a pipeline, lets check what an attacker could obtain after a successful exploitation:
 
-- **Secrets**: Як вже згадувалося раніше, пайплайни вимагають **привілеїв** для своїх завдань (отримання коду, його збірка, розгортання...) і ці привілеї зазвичай **надаються в секретах**. Ці секрети зазвичай доступні через **змінні середовища або файли всередині системи**. Тому зловмисник завжди намагатиметься ексфільтрувати якомога більше секретів.
-- Залежно від платформи пайплайна зловмисник **може знадобитися вказати секрети в конфігурації**. Це означає, що якщо зловмисник не може змінити конфігурацію CI пайплайна (**I-PPE**, наприклад), він може **лише ексфільтрувати секрети, які має цей пайплайн**.
-- **Computation**: Код виконується десь, залежно від того, де він виконується, зловмисник може мати можливість подальшого переміщення.
-- **On-Premises**: Якщо пайплайни виконуються на місці, зловмисник може опинитися в **внутрішній мережі з доступом до більшої кількості ресурсів**.
-- **Cloud**: Зловмисник може отримати доступ до **інших машин у хмарі**, але також може **ексфільтрувати** токени IAM ролей/облікових записів **для отримання подальшого доступу всередині хмари**.
-- **Platforms machine**: Іноді завдання виконуються всередині **машин платформи пайплайнів**, які зазвичай знаходяться в хмарі з **без додаткового доступу**.
-- **Select it:** Іноді **платформа пайплайнів має налаштовані кілька машин**, і якщо ви можете **змінити файл конфігурації CI**, ви можете **вказати, де хочете виконати шкідливий код**. У цій ситуації зловмисник, ймовірно, запустить зворотний шелл на кожній можливій машині, щоб спробувати подальше експлуатувати її.
-- **Compromise production**: Якщо ви знаходитесь всередині пайплайна, і фінальна версія будується та розгортається з нього, ви можете **скомпрометувати код, який буде виконуватися в виробництві**.
+- **Secrets**: Як згадувалося раніше, pipelines вимагають **привілеїв** для своїх job-ів (отримати код, зібрати його, задеплоїти тощо), і ці привілеї зазвичай **надаються у вигляді секретів**. Ці секрети зазвичай доступні через **env variables або файли всередині системи**. Тому нападник завжди буде намагатися ексфільтрувати якомога більше секретів.
+- Залежно від платформи pipeline, нападнику **може знадобитися вказати секрети в конфігу**. Це означає, що якщо нападник не може модифікувати CI конфігурацію pipeline (наприклад I-PPE), він може **експфільтрувати лише ті секрети, які має цей pipeline**.
+- **Computation**: Код виконується десь; залежно від того, де він виконується, нападник може мати можливість пересунутися далі.
+- **On-Premises**: Якщо pipelines виконуються on-premises, нападник може опинитися в **внутрішній мережі з доступом до додаткових ресурсів**.
+- **Cloud**: Нападник може отримати доступ до **інших машин у хмарі**, а також може **ексфільтрувати** токени IAM ролей/сервісних акаунтів, щоб здобути **подальший доступ у хмарі**.
+- **Platforms machine**: Іноді job-и виконуються на **машинах платформи pipeline**, які зазвичай знаходяться в хмарі й не мають додаткового доступу.
+- **Select it:** Іноді **платформа pipeline має декілька типів машин**, і якщо ви можете **модифікувати CI конфігураційний файл**, ви можете **вказати, де запускати шкідливий код**. У цьому випадку нападник, ймовірно, запустить зворотний шелл на кожній можливій машині, щоб спробувати розширити експлуатацію.
+- **Compromise production**: Якщо ви всередині pipeline і фінальна версія будується та задеплоюється звідти, ви можете **скомпрометувати код, який потрапить у production**.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) - це інструмент з відкритим кодом для аудиту вашого стеку постачання програмного забезпечення на предмет відповідності безпеці на основі нового [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Аудит зосереджується на всьому процесі SDLC, де він може виявити ризики від часу коду до часу розгортання.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.
 
 ### Top 10 CI/CD Security Risk
 
-Перегляньте цю цікаву статтю про топ-10 ризиків CI/CD відповідно до Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- На кожній платформі, яку ви можете запустити локально, ви знайдете, як запустити її локально, щоб ви могли налаштувати її на свій розсуд для тестування.
-- Лабораторія Gitea + Jenkins: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- На кожній платформі, яку ви можете запускати локально, ви знайдете інструкції, як її запустити локально, щоб налаштувати її на тестування.
+- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** - це інструмент статичного аналізу коду для інфраструктури як коду.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** — це інструмент статичного аналізу коду для infrastructure-as-code.
 
 ## References
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
 
+
 {{#include ../banners/hacktricks-training.md}}