Translated ['src/pentesting-ci-cd/gitblit-security/README.md', 'src/pent

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

@@ -0,0 +1,21 @@
+# Gitblit Sekuriteit
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Wat is Gitblit
+
+Gitblit is 'n self-hosted Git-bediener geskryf in Java. Dit kan as 'n standalone JAR of in servlet containers loop en verskaf 'n ingebedde SSH-diens (Apache MINA SSHD) vir Git oor SSH.
+
+## Onderwerpe
+
+- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#ref}}
+gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
+{{#endref}}
+
+## Verwysings
+
+- [Gitblit-projek](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 Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Opsomming
+
+CVE-2024-28080 is 'n verifikasie-omseiling in Gitblit se embedded SSH-diens weens verkeerde sessie‑toestand hantering wanneer dit met Apache MINA SSHD geïntegreer word. As 'n gebruikersrekening ten minste een SSH publieke sleutel geregistreer het, kan 'n aanvaller wat die gebruikersnaam en enigeen van daardie gebruiker se publieke sleutels ken, outentikeer sonder die privaat sleutel en sonder die wagwoord.
+
+- Affected: Gitblit < 1.10.0 (observed on 1.9.3)
+- Fixed: 1.10.0
+- Vereistes om te benut:
+- Git over SSH aangeskakel op die instance
+- Slagoffer rekening het ten minste een SSH publieke sleutel in Gitblit geregistreer
+- Aanvaller ken slagoffer se gebruikersnaam en een van hul publieke sleutels (vaak opspoorbaar, bv. https://github.com/<username>.keys)
+
+## Oorsaak (state leaks tussen SSH-metodes)
+
+In RFC 4252 verloop publieke‑sleutel‑verifikasie in twee fases: die bediener kontroleer eers of 'n verskafte publieke sleutel aanvaarbaar is vir 'n gebruikersnaam, en eers ná 'n challenge/response met 'n handtekening verifikasie word die gebruiker geauthentiseer. In MINA SSHD word die PublickeyAuthenticator twee keer aangeroep: by sleutel‑aanvaarding (nog geen handtekening nie) en later nadat die kliënt 'n handtekening teruggekeer het.
+
+Gitblit se PublickeyAuthenticator het die sessie‑konteks gemuteer tydens die eerste, voor‑handtekening oproep deur die geauthentikeerde UserModel aan die sessie te bind en true terug te gee ("key acceptable"). Wanneer verifikasie later na wagwoord terugval, het die PasswordAuthenticator daardie gemuteerde sessie‑toestand vertrou en kortgesluit, en true teruggegee sonder om die wagwoord te valideer. Gevolglik is enige wagwoord (insluitend leë) aanvaar ná 'n vorige publieke‑sleutel "aanvaarding" vir dieselfde gebruiker.
+
+Hoëvlak foutiewe vloei:
+
+1) Kliënt bied gebruikersnaam + publieke sleutel aan (nog geen handtekening nie)
+2) Bediener herken die sleutel as deel van die gebruiker en heg voortydig die gebruiker aan die sessie, gee true terug ("aanvaarbaar")
+3) Kliënt kan nie teken nie (geen privaat sleutel), so verifikasie val terug na wagwoord
+4) Wagwoordverifikasie sien 'n gebruiker reeds in die sessie en gee onvoorwaardelik sukses terug
+
+## Stap‑vir‑stap uitbuiting
+
+- Versamel 'n slagoffer se gebruikersnaam en een van hul publieke sleutels:
+- GitHub openbaar publieke sleutels by https://github.com/<username>.keys
+- Publieke bedieners openbaar dikwels authorized_keys
+- Konfigureer OpenSSH om slegs die publieke helfte voor te sit sodat handtekeninggenerasie misluk, wat 'n terugval na wagwoord afdwing terwyl dit steeds die publieke‑sleutel aanvaardingspad op die bediener aktiveer.
+
+Voorbeeld SSH kliënt konfigurasie (geen privaat sleutel beskikbaar):
+```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)
+```
+Verbind en druk Enter by die wagwoordprompt (of tik enige tekenreeks):
+```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 slaag omdat die vroeëre public‑key‑fase die sessie na 'n geverifieerde gebruiker verander het, en password auth vertrou verkeerdelik daardie toestand.
+
+Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
+
+## Impact
+
+- Volledige identiteitsbedrog van enige Gitblit‑gebruiker met ten minste een geregistreerde SSH public key
+- Lees/skryf‑toegang tot repositories volgens die slagoffer se regte (bron‑exfiltrasie, ongemagtigde pushes, supply‑chain‑risiko's)
+- Potensiële administratiewe impak as 'n admin‑gebruiker geteiken word
+- Suiwer netwerk‑exploit; geen brute force of private key benodig nie
+
+## Detection ideas
+
+- Hersien SSH‑logs vir reekse waar 'n publickey‑poging gevolg word deur 'n suksesvolle password‑authentikasie met 'n leë of baie kort wagwoord
+- Soek vir vloei: publickey‑metode wat onondersteunde/nie‑ooreenstemmende sleutelmateriaal aanbied, gevolg deur 'n onmiddellike password‑sukses vir dieselfde gebruikersnaam
+
+## Mitigations
+
+- Upgrade to Gitblit v1.10.0+
+- Until upgraded:
+- Disable Git over SSH on Gitblit, or
+- Restrict network access to the SSH service, and
+- Monitor for suspicious patterns described above
+- Rotate affected user credentials if compromise is suspected
+
+## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+
+Patroon: As 'n bediener se public‑key authenticator die gebruiker/sessie‑toestand verander tydens die pre‑signature "key acceptable" fase en ander authenticators (bv. password) daardie toestand vertrou, kan jy verifikasie omseil deur:
+
+- Voorsien 'n geldige public key vir die teiken‑gebruiker (geen private key nie)
+- Verplig die kliënt om ondertekening te laat misluk sodat die bediener op password terugval
+- Verskaf enige password terwyl die password authenticator kort‑sluiting maak op leaked state
+
+Praktiese wenke:
+
+- Public key harvesting at scale: trek public keys uit algemene bronne soos https://github.com/<username>.keys, organisasiedirektore, spanbladsye, leaked authorized_keys
+- Forcing signature failure (client‑side): wys IdentityFile slegs na die .pub, stel IdentitiesOnly yes, hou PreferredAuthentications om publickey en dan password in te sluit
+- MINA SSHD integrasie valkuils:
+- PublickeyAuthenticator.authenticate(...) moet nie gebruiker/sessie‑toestand heg nie totdat die post‑signature verifikasie‑pad die handtekening bevestig
+- PasswordAuthenticator.authenticate(...) moet nie sukses aflei uit enige toestand wat tydens 'n vorige, onvolledige authentication‑metode verander is nie
+
+Gekoppelde protokol/ontwerp notas en literatuur:
+- SSH userauth‑protokol: RFC 4252 (publickey‑metode is 'n twee‑stadium proses)
+- Historiese besprekings oor vroeë aanvaarding‑orakels en auth‑races, bv. CVE‑2016‑20012‑gesprekke oor OpenSSH‑gedrag
+
+## 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 Metodologie
+# Pentesting CI/CD Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,99 +6,102 @@
 
 ## VCS
 
-VCS staan vir **Version Control System**, hierdie stelsels laat ontwikkelaars toe om **hulle bronkode te bestuur**. Die mees algemene een is **git** en jy sal gewoonlik maatskappye vind wat dit gebruik in een van die volgende **platforms**:
+VCS staan vir weergawebeheerstelsel (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
-- Wolkverskaffers (hulle bied hul eie VCS-platforms aan)
+- Gitblit
+- Cloud providers (they offer their own VCS platforms)
 
-## CI/CD Pypelines
 
-CI/CD pypelines stel ontwikkelaars in staat om **die uitvoering van kode te outomatiseer** vir verskeie doeleindes, insluitend bou, toets en ontplooi van toepassings. Hierdie geoutomatiseerde werksvloei word **geaktiveer deur spesifieke aksies**, soos kode stoot, trek versoeke, of geskeduleerde take. Hulle is nuttig om die proses van ontwikkeling na produksie te stroomlyn.
+## CI/CD Pipelines
 
-Egter, hierdie stelsels moet **ergens uitgevoer word** en gewoonlik met **bevoorregte akrediteer om kode te ontplooi of toegang tot sensitiewe inligting te verkry**.
+CI/CD pipelines stel ontwikkelaars in staat om die uitvoering van kode te outomatiseer vir verskeie doeleindes, insluitende build, testing en deployment van toepassings. Hierdie geoutomatiseerde workflows word **getrigger deur spesifieke aksies**, soos code pushes, pull requests, of geskeduleerde take. Hulle help om die proses van development na production te stroomlyn.
 
-## VCS Pentesting Metodologie
+Hierdie stelsels moet egter **eers ergens uitgevoer word** en gewoonlik met **bevoorregte credentials om kode te deploy of sensitiewe inligting te bereik**.
+
+## VCS Pentesting Methodology
 
 > [!NOTE]
-> Alhoewel sommige VCS-platforms toelaat om pypelines te skep, gaan ons in hierdie afdeling slegs potensiële aanvalle op die beheer van die bronkode analiseer.
+> 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.
 
-Platforms wat die bronkode van jou projek bevat, bevat sensitiewe inligting en mense moet baie versigtig wees met die toestemmings wat binne hierdie platform toegestaan word. Dit is 'n paar algemene probleme oor VCS-platforms wat 'n aanvaller kan misbruik:
+Platforms wat die bronkode van jou projek bevat huisves sensitiewe inligting en mense moet baie versigtig wees met die permissies wat binne hierdie platform toegestaan word. Dit is 'n paar algemene probleme oor VCS platforms wat 'n aanvaller kan misbruik:
 
-- **Leaks**: As jou kode lekkasies in die verbintenisse bevat en die aanvaller toegang tot die repo kan verkry (omdat dit publiek is of omdat hy toegang het), kan hy die lekkasies ontdek.
+- **Leaks**: As jou kode leak(s) in die commits bevat en die aanvaller toegang tot die repo het (omdat dit public is of omdat hy toegang het), kan hy die leak(s) ontdek.
-- **Toegang**: As 'n aanvaller **toegang tot 'n rekening binne die VCS-platform** kan verkry, kan hy **meer sigbaarheid en toestemmings** verkry.
+- **Access**: As 'n aanvaller **toegang tot 'n rekening binne die VCS platform** kan kry, kan hy **meer sigbaarheid en permissies** verkry.
-- **Registrasie**: Sommige platforms sal net eksterne gebruikers toelaat om 'n rekening te skep.
+- **Register**: Sommige platforms sal net toelaat dat eksterne gebruikers 'n rekening skep.
-- **SSO**: Sommige platforms sal nie gebruikers toelaat om te registreer nie, maar sal enigeen toelaat om toegang te verkry met 'n geldige SSO (so 'n aanvaller kan sy github-rekening gebruik om in te gaan byvoorbeeld).
+- **SSO**: Sommige platforms sal gebruikers nie toelaat om te registreer nie, maar sal enigiemand met 'n geldige SSO toegang gee (sodat 'n aanvaller byvoorbeeld sy github-rekening kan gebruik om in te gaan).
-- **Akrediteer**: Gebruikersnaam+Pwd, persoonlike tokens, ssh sleutels, Oauth tokens, koekies... daar is verskeie tipes tokens wat 'n gebruiker kan steel om op een of ander manier toegang tot 'n repo te verkry.
+- **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-sigtbare geheime nie, kan 'n **aanvaller dit misbruik**.
+- **Webhooks**: VCS platforms laat toe om webhooks te genereer. As hulle **nie beskerm** is met nie-sigbare secrets nie, **kan 'n aanvaller dit misbruik**.
-- As daar geen geheim is nie, kan die aanvaller die webhook van die derdeparty-platform misbruik.
+- As geen geheim (secret) in plek 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.
+- As die secret in die URL is, gebeur dieselfde en die aanvaller het ook die secret.
-- **Kode kompromie:** As 'n kwaadwillige akteur 'n soort **skryf** toegang oor die repos het, kan hy probeer om **kwaadwillige kode in te spuit**. Om suksesvol te wees, mag hy moet **tak beskermings omseil**. Hierdie aksies kan met verskillende doelwitte in gedagte uitgevoer word:
+- **Code compromise:** As 'n kwaadwillige akteur sekere vorme van **write** toegang oor die repos het, kan hy probeer om **malscode in te inspuit**. Om suksesvol te wees kan hy nodig hê om **branch protections te omseil**. Hierdie aksies kan met verskillende doelwitte uitgevoer word:
-- Kompromitteer die hooftak om **produksie te kompromitteer**.
+  - Kompromiseer die main branch om **production te kompromitteer**.
-- Kompromitteer die hoof (of ander takke) om **ontwikkelaars se masjiene te kompromitteer** (aangesien hulle gewoonlik toets, terraform of ander dinge binne die repo op hul masjiene uitvoer).
+  - Kompromiseer die main (of ander branches) om **ontwikkelaars se masjiene te kompromitteer** (aangesien hulle gewoonlik tests, terraform of ander dinge vanuit die repo op hul masjiene uitvoer).
-- **Kompromitteer die pypeline** (kyk na die volgende afdeling).
+- **Compromise the pipeline** (kyk volgende afdeling)
 
-## Pypelines Pentesting Metodologie
+## Pipelines Pentesting Methodology
 
-Die mees algemene manier om 'n pypeline te definieer, is deur 'n **CI-konfigurasie lêer wat in die repo gehos is** te gebruik. Hierdie lêer beskryf die volgorde van uitgevoerde take, toestande wat die vloei beïnvloed, en bouomgewinginstellings.\
+Die mees algemene manier om 'n pipeline te definieer, is deur 'n **CI configuration file gehost in die repository** te gebruik 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 wat onder .github/workflows geleë is. Wanneer geaktiveer, **trek die pypeline-taak die kode** van die geselekteerde bron (bv. verbintenis / tak), en **voert die opdragte wat in die CI-konfigurasie lêer gespesifiseer is** teen daardie kode uit.
+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, die pipeline job **pulls the code** van die gekose bron (bv. commit / branch), en **voer die opdragte wat in die CI configuration file gespesifiseer is uit** teen daardie kode.
 
-Daarom is die uiteindelike doel van die aanvaller om op een of ander manier **daardie konfigurasie lêers** of die **opdragte wat hulle uitvoer** te **kompromitteer**.
+Dus is die uiteindelike doel van die aanvaller om op een of ander manier daardie configuration files of die opdragte wat hulle uitvoer, te **kompromiseer**.
 
-### PPE - Gevulde Pypeline Uitvoering
+### PPE - Poisoned Pipeline Execution
 
-Die Gevulde Pypeline Uitvoering (PPE) pad misbruik toestemmings in 'n SCM-repo om 'n CI-pypeline te manipuleer en skadelike opdragte uit te voer. Gebruikers met die nodige toestemmings kan CI-konfigurasie lêers of ander lêers wat deur die pypeline-taak gebruik word, wysig om kwaadwillige opdragte in te sluit. Dit "vervuil" die CI-pypeline, wat lei tot die uitvoering van hierdie kwaadwillige opdragte.
+Die Poisoned Pipeline Execution (PPE) pad misbruik permissies in 'n SCM repository om 'n CI pipeline te manipuleer en skadelike opdragte uit te voer. Gebruikers met die nodige permissies kan CI configuration files 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 daardie kwaadwillige opdragte.
 
 Vir 'n kwaadwillige akteur om suksesvol 'n PPE-aanval uit te voer, moet hy in staat wees om:
 
-- **Skryf toegang tot die VCS-platform** te hê, aangesien pypelines gewoonlik geaktiveer word wanneer 'n stoot of 'n trek versoek uitgevoer word. (Kyk na die VCS pentesting metodologie vir 'n opsomming van maniere om toegang te verkry).
+- Skryf toegang tot die VCS platform te hê, aangesien pipelines gewoonlik getrigger word wanneer 'n push of 'n pull request uitgevoer word. (Kyk die VCS pentesting methodology vir 'n opsomming van maniere om toegang te kry).
-- Let daarop dat soms 'n **eksterne PR as "skryf toegang" tel**.
+- Let daarop dat soms 'n **eksterne PR as "write access" beskou kan word**.
-- Selfs as hy skryf toestemmings het, moet hy seker wees dat hy die **CI konfigurasie lêer of ander lêers waarop die konfigurasie staatmaak** kan **wysig**.
+- Selfs as hy write permissions het, moet hy seker maak dat hy die **CI config file of ander lêers waarvan die config afhanklik is, kan wysig**.
-- Hiervoor mag hy moet in staat wees om **tak beskermings om te seil**.
+- Hiervoor mag hy nodig hê om **branch protections te omseil**.
 
-Daar is 3 PPE geure:
+Daar is 3 PPE-variante:
 
-- **D-PPE**: 'n **Direkte PPE** aanval vind plaas wanneer die akteur die **CI konfigurasie** lêer wat gaan uitgevoer word, **wysig**.
+- **D-PPE**: 'n **Direct PPE**-aanval vind plaas wanneer die akteur die **CI config** lêer wysig wat uitgevoer gaan word.
-- **I-DDE**: 'n **Indirekte PPE** aanval vind plaas wanneer die akteur 'n **lêer** wat die CI konfigurasie lêer wat gaan uitgevoer word, **afhang** van, **wysig** (soos 'n make-lêer of 'n terraform konfigurasie).
+- **I-DDE**: 'n **Indirect PPE**-aanval vind plaas wanneer die akteur 'n **lêer** wysig waarop die CI config lêer staatmaak (soos 'n make file of 'n terraform config).
-- **Publieke PPE of 3PE**: In sommige gevalle kan die pypelines **geaktiveer word deur gebruikers wat nie skryf toegang in die repo het nie** (en wat dalk nie eens deel van die org is nie) omdat hulle 'n PR kan stuur.
+- **Public PPE or 3PE**: In sommige gevalle kan die pipelines **getrigger word deur gebruikers wat nie write access in die repo het nie** (en wat dalk nie eens deel van die org is nie) omdat hulle 'n PR kan stuur.
-- **3PE Opdrag Inspuiting**: Gewoonlik sal CI/CD pypelines **omgewing veranderlikes stel** met **inligting oor die PR**. As daardie waarde deur 'n aanvaller beheer kan word (soos die titel van die PR) en **gebruik** word in 'n **gevaarlike plek** (soos die uitvoering van **sh opdragte**), kan 'n aanvaller **opdragte daar in spuit**.
+- **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 **gebruik** word op 'n **gevaarlike plek** (soos om **sh commands** uit te voer), kan 'n aanvaller **opdragte daarin injekteer**.
 
-### Exploitatie Voordele
+### Exploitation Benefits
 
-Om die 3 geure te ken om 'n pypeline te vervuil, laat ons kyk wat 'n aanvaller kan verkry na 'n suksesvolle uitbuiting:
+Met die kennis van die 3 variante om 'n pipeline te vergiftig, kom ons kyk wat 'n aanvaller na 'n suksesvolle exploit kan bekom:
 
-- **Geheime**: Soos voorheen genoem, vereis pypelines **bevoegdhede** vir hul take (om die kode te verkry, dit te bou, dit te ontplooi...) en hierdie bevoegdhede word gewoonlik **in geheime toegestaan**. Hierdie geheime is gewoonlik toeganklik via **omgewing veranderlikes of lêers binne die stelsel**. Daarom sal 'n aanvaller altyd probeer om soveel geheime as moontlik te eksfiltreer.
+- **Secrets**: Soos voorheen genoem, benodig pipelines **privileges** vir hul jobs (kode retrieve, build, deploy …) en hierdie privileges word gewoonlik **geberg as secrets**. 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 te exfiltrate.
-- Afhangende van die pypeline platform mag die aanvaller **die geheime in die konfigurasie moet spesifiseer**. Dit beteken dat as die aanvaller nie die CI konfigurasie pypeline kan wysig nie (**I-PPE** byvoorbeeld), kan hy **slegs die geheime wat daardie pypeline het, eksfiltreer**.
+- Afhangend van die pipeline platform mag die aanvaller **die secrets in die config moet spesifiseer**. Dit beteken dat as die aanvaller die CI configuration pipeline nie kan wysig nie (**I-PPE** byvoorbeeld), hy **slegs die secrets kan exfiltrate wat daardie pipeline het**.
-- **Berekening**: Die kode word iewers uitgevoer, afhangende van waar dit uitgevoer word, mag 'n aanvaller in staat wees om verder te pivot.
+- **Computation**: Die kode word iewers uitgevoer; afhangend waar dit uitgevoer word, kan 'n aanvaller verder kan pivoteer.
-- **On-premises**: As die pypelines op plek uitgevoer word, mag 'n aanvaller eindig in 'n **interne netwerk met toegang tot meer hulpbronne**.
+- **On-Premises**: As die pipelines on-premises uitgevoer word, kan 'n aanvaller in 'n **interne netwerk met toegang tot meer hulpbronne** eindig.
-- **Wolk**: Die aanvaller kan toegang verkry tot **ander masjiene in die wolk** maar kan ook **geheime** IAM rolle/dienste rekeninge **tokens** van dit eksfiltreer om **verdere toegang binne die wolk** te verkry.
+- **Cloud**: Die aanvaller kan toegang tot **ander masjiene in die cloud** kry, maar kan ook IAM roles/service accounts **tokens** exfiltrate om **verdere toegang binne die cloud** te verkry.
-- **Platforms masjien**: Soms sal die take binne die **pypelines platform masjiene** uitgevoer word, wat gewoonlik binne 'n wolk met **geen verdere toegang** is.
+- **Platforms machine**: Soms sal die jobs binne die **pipelines platform masjiene** uitgevoer word, wat gewoonlik binne 'n cloud sit met **geen addisionele toegang nie**.
-- **Kies dit:** Soms sal die **pypelines platform verskeie masjiene geconfigureer hê** en as jy die **CI konfigurasie lêer kan wysig**, kan jy **aan dui waar jy die kwaadwillige kode wil uitvoer**. In hierdie situasie sal 'n aanvaller waarskynlik 'n omgekeerde skulp op elke moontlike masjien uitvoer om te probeer om dit verder te exploiteer.
+- **Select it:** Soms het die **pipelines platform verskeie masjiene gekonfigureer** en as jy die **CI configuration file** kan wysig, kan jy **indikeer waar jy die kwaadwillige kode wil laat loop**. In daardie geval sal 'n aanvaller waarskynlik 'n reverse shell op elke moontlike masjien probeer laat loop om verdere eksploitasie te probeer.
-- **Kompromitteer produksie**: As jy binne die pypeline is en die finale weergawe daaruit gebou en ontplooi word, kan jy **die kode wat in produksie gaan loop, kompromitteer**.
+- **Compromise production**: As jy in die pipeline is en die finale weergawe daar gebou en deployed word, kan jy die kode wat uiteindelik in production sal loop, **kompromiseer**.
 
-## Meer relevante inligting
+## More relevant info
 
-### Gereedskap & CIS Benchmark
+### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is 'n oopbron gereedskap vir die oudit van jou sagteware voorsieningsketting stap vir sekuriteits nakoming 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 kode tyd in ontplooi tyd kan onthul.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is 'n open-source hulpmiddel om jou software supply chain stack te oudit vir sekuriteitskompliance gebaseer op die 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 kode tyd tot deploy tyd kan openbaar.
 
-### Top 10 CI/CD Sekuriteitsrisiko's
+### 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/)
 
-### Laboratoriums
+### Labs
 
-- Op elke platform wat jy plaaslik kan uitvoer, sal jy vind 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 vind hoe om dit lokaal te loods sodat jy dit kan konfigureer soos jy wil toets.
-- Gitea + Jenkins laboratorium: [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)
 
-### Outomatiese Gereedskap
+### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is 'n statiese kode analise gereedskap vir infrastruktuur-as-kode.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is 'n static code analysis tool vir infrastructure-as-code.
 
-## Verwysings
+## 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}}