diff --git a/src/pentesting-ci-cd/argocd-security.md b/src/pentesting-ci-cd/argocd-security.md
new file mode 100644
index 000000000..9a6510821
--- /dev/null
+++ b/src/pentesting-ci-cd/argocd-security.md
@@ -0,0 +1,219 @@
+# Argo CD Security
+
+{{#include ../banners/hacktricks-training.md}}
+
+## Basiese Inligting
+
+[Argo CD](https://argo-cd.readthedocs.io/) is 'n GitOps continuous delivery platform vir Kubernetes. Dit monitor Git repositories, render Kubernetes manifests met tools soos Helm, Kustomize, Jsonnet of config management plugins, en reconcile die live cluster state met die desired state wat in Git gestoor is.
+
+Vanuit 'n attacker perspektief, behandel Argo CD as 'n **deployment engine met Kubernetes credentials**. 'n Nuttige Argo CD compromise kan lei tot:
+
+- Access to private Git repositories en repository credentials.
+- Access to Kubernetes cluster secrets wat deur Argo CD gebruik word.
+- Manifest generation code execution in `argocd-repo-server`.
+- Unauthorized Kubernetes object deployment deur trusted Git repositories, Argo CD applications, of cache manipulation.
+
+## Architecture & Interesting Components
+
+Common Kubernetes objects and services:
+```bash
+kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd'
+kubectl get applications,appprojects,applicationsets -A 2>/dev/null
+kubectl get secrets,configmaps -n argocd 2>/dev/null
+kubectl get networkpolicy -n argocd 2>/dev/null
+```
+Interessante dienste:
+
+- **`argocd-server`**: publieke API, web UI, CLI API, authentication en authorization.
+- **`argocd-application-controller`**: vergelyk desired en live state, en pas dan resources toe op Kubernetes.
+- **`argocd-repo-server`**: kloon repositories, cache Git data, en run Helm/Kustomize/Jsonnet/plugins om manifests te genereer. Die standaard gRPC-poort is **8081**.
+- **`argocd-redis`**: cache vir application, manifest en Git reference data. Die standaard Redis-poort is **6379**.
+- **`argocd-applicationset-controller`**: genereer Argo CD `Application` objects uit generators soos Git, SCM, clusters en pull requests.
+
+From a compromised pod or internal network segment, check internal reachability:
+```bash
+nc -vz <argocd-server> 443
+nc -vz <argocd-repo-server> 8081
+nc -vz <argocd-redis> 6379
+```
+## Public API / UI Attacks
+
+As jy Argo CD credentials of ’n blootgestelde instance het, begin met die normale API surface:
+```bash
+argocd login <argocd-server>
+argocd account get-user-info
+argocd account list
+argocd proj list
+argocd app list
+argocd repo list
+argocd cluster list
+argocd admin settings rbac can <subject> <action> <resource> <object>
+```
+Nuttige aanvalspaaie:
+
+- **Application write access**: wysig `source.repoURL`, `source.path`, Helm values, Kustomize options, plugin settings of sync options sodat Argo CD attacker-controlled manifests deploy.
+- **Project misconfiguration**: `AppProject` objects kan breë `sourceRepos`, breë `destinations`, onveilige `clusterResourceWhitelist`, of swak namespace-beperkings toelaat.
+- **Repository credential abuse**: repository secrets, GitHub App credentials, SSH keys en tokens kan toelaat om na trusted repos te push of malicious dependencies by te voeg.
+- **Cluster credential abuse**: cluster secrets kan bearer tokens of exec-provider configuration bevat wat deur Argo CD gebruik word om in target clusters in te deploy.
+- **Local admin / project tokens**: long-lived Argo CD tokens kan via die API hergebruik word tensy hulle revoked of expired is.
+
+Enumereer configuration vanaf Kubernetes wanneer jy cluster read access het:
+```bash
+kubectl get applications.argoproj.io -A -o yaml
+kubectl get appprojects.argoproj.io -A -o yaml
+kubectl get applicationsets.argoproj.io -A -o yaml
+kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey'
+kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml
+```
+## Trusted Git Repository Abuse
+
+As jy kan push na 'n repository wat deur Argo CD vertrou word, kan jy gewoonlik beïnvloed wat gedeply word. Die impak hang af van die `AppProject` grense en die service account permissions wat deur die application controller gebruik word.
+
+Algemene payload-liggings:
+
+- Raw Kubernetes YAML onder 'n application pad.
+- Helm chart templates en `values.yaml`.
+- Kustomize overlays, remote bases en generators.
+- Jsonnet of config management plugin input.
+- ApplicationSet generator files wat `Application` objects skep of opdateer.
+
+Kontroleer of die app automated sync, pruning, self-heal, sync windows of manual approvals gebruik:
+```bash
+kubectl get applications.argoproj.io -A \
+-o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server'
+```
+## Direkte `argocd-repo-server` Misbruik
+
+Moenie aanvaar dat die publieke Argo CD API die enigste aanvaloppervlak is nie. Interne Argo CD-komponente kommunikeer met `argocd-repo-server` oor gRPC. As arbitrêre pods repo-server kan bereik, kan aanvaller-beheerde interne requests kontroles omseil wat normaalweg deur `argocd-server` afgedwing word.
+
+Praktiese kontroles:
+```bash
+kubectl get svc -n argocd argocd-repo-server -o yaml
+kubectl get endpoints -n argocd argocd-repo-server -o wide
+nc -vz <argocd-repo-server> 8081
+```
+Interessante tekens:
+
+- Die repo-server gRPC-endpoint is bereikbaar vanaf nie-Argo CD pods.
+- NetworkPolicies ontbreek of laat net allow-list egress toe sonder om ingress te deny.
+- Die repo-server het toegang tot custom config management plugins, decryption tools, of repository content van multiple tenants.
+- Redis is bereikbaar vanaf nie-Argo CD pods, wat cache-inspection of tampering moontlik maak as credentials beskikbaar is of nie vereis word nie.
+
+## Unauthenticated Repo-Server RCE via Kustomize Options
+
+In Julie 2026 het Synacktiv 'n unauthenticated code execution chain in Argo CD se `repo-server` bekendgemaak wanneer 'n attacker die interne gRPC service kan bereik. Die attack misbruik direkte toegang tot `/repository.RepoServerService/GenerateManifest` en attacker-controlled `KustomizeOptions`.
+
+Die gevaarlike primitive is om repo-server te forseer om attacker-controlled repository content te clone en Kustomize met Helm support te laat loop:
+```bash
+kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
+```
+Minimale kwaadwillige Kustomize-invoer wat nodig is om Helm-verwerking te trigger:
+```yaml
+helmCharts:
+- name: pwn
+version: 0.0.1
+```
+Hoekom dit werk:
+
+- `argocd-repo-server` kloon die repository voor rendering.
+- `--helm-command ./payload.sh` los relatief op tot die gekloonde repository.
+- Code execution vereis nie shell metakarakter-inspuiting as die attacker die gerenderde repository en Kustomize build opsies kan beheer nie.
+
+Ten tyde van Synacktiv se 1 Julie 2026 disclosure, het hulle berig dat die issue geen amptelike fix of CVE gehad het nie. Behandel dit eers as 'n network-exposure issue: exploitation vereis reachability na die interne repo-server gRPC port.
+
+## Redis Cache Poisoning om Manifests te Deploy
+
+Ná code execution in `argocd-repo-server`, of ná direkte toegang tot Redis met geldige credentials, inspekteer Redis-backed cache entries. Argo CD stoor algemeen gzip-gekomprimeerde JSON values.
+
+Interessante key prefixes:
+```text
+mfst|...       # cached rendered manifests
+git-refs|...   # Git branch/ref to commit mappings
+app|...        # application resource/cache data
+cluster|...    # cluster cache information
+```
+Die cache poisoning attack wat deur Synacktiv beskryf word, misbruik twee stukke state:
+
+1. Wysig die relevante `mfst|...` manifest cache entry om ’n attacker-controlled Kubernetes manifest in te sluit.
+2. Wysig die verwante `git-refs|...` mapping sodat Argo CD glo die branch het geskuif en dan terug reconcile na die cached revision.
+
+Impact:
+
+- Met Auto Sync geaktiveer, kan Argo CD die poisoned cached manifest outomaties toepas.
+- Sonder Auto Sync kan die payload steeds toegepas word wanneer ’n user die application handmatig sync.
+- Die finale impact word beperk deur die target application's destination en die Kubernetes permissions wat vir Argo CD beskikbaar is.
+
+## ApplicationSet Attacks
+
+ApplicationSet is veral sensitief omdat dit `Application` objects skep of update vanaf generator output.
+
+Review:
+```bash
+kubectl get applicationsets.argoproj.io -A -o yaml
+kubectl get appprojects.argoproj.io -A -o yaml
+```
+Interessante patrone:
+
+- Git generators wat aanvaller-skryfbare lêers lees wat app-name, paths, projects of destinations beheer.
+- Pull request generators vir publieke repositories waar onbetroubare bydraers gegenereerde applications kan beïnvloed.
+- Template fields wat breë destination clusters/namespaces toelaat.
+- AppProjects wat `sourceRepos: ["*"]` of breë `destinations` toelaat.
+- Gegenereerde applications wat automated sync en pruning erf.
+
+## Post-Exploitation
+
+Vanuit ’n Argo CD pod shell, prioritiseer:
+```bash
+env
+cat /proc/1/environ 2>/dev/null | tr '\0' '\n'
+find /var/run/secrets /app/config -type f -maxdepth 4 2>/dev/null
+mount | grep -E 'secret|token|config'
+```
+Nuttige doelwitte:
+
+- Steel `REDIS_PASSWORD` of Redis TLS/client materiaal.
+- Onttrek repository credentials uit gemonteerde secrets of Argo CD Kubernetes secrets.
+- Identifiseer cluster credentials wat deur Argo CD gebruik word.
+- Lees gegenereerde manifests en plugin output wat geïnjecteerde secrets kan insluit.
+- Kyk of custom plugins, SOPS, Helm secrets, Vault plugins of cloud CLIs decryption keys en cloud credentials blootstel.
+
+## Detection & Hardening
+
+Belangrike kontroles:
+
+- Beperk `argocd-repo-server` poort **8081** en Redis poort **6379** met NetworkPolicies sodat net verwagte Argo CD-komponente daarna kan reik.
+- In Helm deployments, verifieer dat network policies werklik geskep word. Argo CD Helm chart values het histories component network policy creation verstek na disabled.
+- Hou `argocd-server` as die geverifieerde toegangspunt. Interne dienste moet nie vanaf arbitrêre workloads bereikbaar wees nie.
+- Deaktiveer ongebruikte config management tools en plugins.
+- Beperk `AppProject` `sourceRepos`, `destinations`, namespace permissions en cluster-scoped resources.
+- Vermy die stoor van breë repository credentials waar 'n laag-geprivilegieerde Argo CD user hergebruik daarvan kan veroorsaak.
+- Monitor repo-server requests, Kustomize build options, plugin executions, Redis writes en onverwagte toegang tot `mfst|` / `git-refs|` keys.
+- Roteer Argo CD local users, project tokens, repository credentials en cluster credentials ná compromise.
+
+Nuttige commands:
+```bash
+kubectl get networkpolicy -n argocd
+kubectl get networkpolicy -A | grep -i argocd
+kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null
+kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null
+```
+## Static Analysis Note: Typed API Requests in CodeQL
+
+Vir Go services wat gRPC/REST handlers gebruik, kan default CodeQL remote sources flows mis nadat raw input in typed request objects ge-unmarshal is. ’n Nuttige model vir Argo CD-style services is:
+
+- Receiver type soos `Server` of `Service`.
+- Eerste parameter is `context.Context`.
+- Tweede parameter is ’n typed request object.
+
+Model daardie tweede parameter as ’n remote source en voeg custom sinks vir `exec.Command` / `exec.CommandContext` arguments by. Dit help om flows van internal API request fields na command execution helpers te vind.
+
+## References
+
+- [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql)
+- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/)
+- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/)
+- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/)
+- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml)
+- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/)
+- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md)
+- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md)
diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
index e746b4ac3..7f9ac8f76 100644
--- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
+++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
@@ -1,4 +1,4 @@
-# Pentesting CI/CD Metodologie
+# Pentesting CI/CD Methodologie
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,7 +6,7 @@
 
 ## 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 **Version Control System**, hierdie stelsels laat ontwikkelaars toe om **hul bronkode te bestuur**. Die mees algemene een is **git** en jy sal gewoonlik maatskappye vind wat dit gebruik in een van die volgende **platforms**:
 
 - Github
 - Gitlab
@@ -18,39 +18,39 @@ VCS staan vir **Version Control System**, hierdie stelsels laat ontwikkelaars to
 
 ## CI/CD Pipelines
 
-CI/CD pipelines stel ontwikkelaars in staat om die **uitvoering van code** te outomatiseer vir verskeie doeleindes, insluitend die bou, toets en ontplooiing van applications. Hierdie geoutomatiseerde workflows word **geaktiveer deur spesifieke aksies**, soos code pushes, pull requests, of geskeduleerde take. Hulle is nuttig om die proses van ontwikkeling na production te stroomlyn.
+CI/CD pipelines stel ontwikkelaars in staat om die **uitvoering van code te outomatiseer** vir verskeie doeleindes, insluitend bou, toets en ontplooi van toepassings. Hierdie geoutomatiseerde workflows word **geaktiveer deur spesifieke aksies**, soos code pushes, pull requests, of geskeduleerde take. Hulle is nuttig om die proses van ontwikkeling na produksie te stroomlyn.
 
-Hierdie systems moet egter **iewers uitgevoer word** en gewoonlik met **geprivilegieerde credentials om code te ontplooi of toegang tot sensitiewe information te verkry**.
+Hierdie stelsels moet egter **iewers uitgevoer word** en gewoonlik met **geprivilegieerde credentials om code te ontplooi of toegang tot sensitiewe inligting te verkry**.
 
-## VCS Pentesting Methodology
+## VCS Pentesting Methodologie
 
 > [!NOTE]
-> Al laat sommige VCS platforms toe om pipelines vir hierdie afdeling te skep, gaan ons net potensiële attacks teen die beheer van die bronkode ontleed.
+> Selfs al laat sommige VCS platforms toe om pipelines vir hierdie afdeling te skep, gaan ons slegs potensiële aanvalle op die beheer van die bronkode analiseer.
 
-Platforms wat die bronkode van jou project bevat, bevat sensitiewe information en mense moet baie versigtig wees met die permissions wat binne hierdie platform toegestaan word. Hierdie is sommige algemene problems oor VCS platforms wat attackers kan misbruik:
+Platforms wat die bronkode van jou projek bevat, bevat sensitiewe inligting en mense moet baie versigtig wees met die permissions wat binne hierdie platform toegeken word. Dit is van die algemene probleme oor VCS platforms wat 'n attacker kan misbruik:
 
-- **Leaks**: As jou code leaks in die commits bevat en die attacker toegang tot die repo kan kry (omdat dit public is of omdat hy toegang het), kan hy die leaks ontdek.
-- **Access**: As 'n attacker **toegang tot 'n account binne die VCS platform kan verkry** kan hy **meer visibility en permissions** kry.
-- **Register**: Sommige platforms sal net eksterne users toelaat om 'n account te skep.
-- **SSO**: Sommige platforms sal users nie toelaat om te registreer nie, maar sal enigiemand toelaat om met 'n geldige SSO toegang te verkry (so 'n attacker kan byvoorbeeld sy github account gebruik om in te gaan).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... daar is verskeie soort tokens wat 'n user kan steel om op een of ander manier toegang tot 'n repo te verkry.
-- **Webhooks**: VCS platforms laat toe om webhooks te genereer. As hulle **nie beskerm** word met nie-sigbare secrets nie, kan 'n **attacker hulle misbruik**.
-- As geen secret in plek is nie, kan die attacker die webhook van die third party platform misbruik
+- **Leaks**: As jou code leaks in die commits bevat en die attacker kan toegang kry tot die repo (omdat dit publiek is of omdat hy toegang het), kan hy die leaks ontdek.
+- **Access**: As 'n attacker **toegang tot 'n account binne die VCS platform** kan kry, kan hy **meer sigbaarheid en permissions** verkry.
+- **Register**: Sommige platforms sal bloot toelaat dat eksterne users 'n account skep.
+- **SSO**: Sommige platforms sal nie users toelaat om te registreer nie, maar sal wel enigiemand toelaat om toegang te verkry met 'n geldige SSO (so 'n attacker kan byvoorbeeld sy github account gebruik om in te gaan).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... daar is verskeie soorte tokens wat 'n user kan steel om op een of ander manier toegang tot 'n repo te verkry.
+- **Webhooks**: VCS platforms laat toe om webhooks te genereer. As hulle **nie beskerm** word met nie-sigbare secrets nie, kan 'n **attacker dit misbruik**.
+- As geen secret in plek is nie, kan die attacker die webhook van die derdeparty-platform misbruik
 - As die secret in die URL is, gebeur dieselfde en die attacker het ook die secret
-- **Code compromise:** As 'n kwaadwillige actor een of ander soort **write** access oor die repos het, kan hy probeer om **kwaadwillige code in te spuit**. Om suksesvol te wees, moet hy dalk **branch protections omseil**. Hierdie actions kan met verskillende goals in mid uitgevoer word:
-- Die main branch kompromitteer om **production te kompromitteer**.
-- Die main (of ander branches) kompromitteer om **developers machines te kompromitteer** (aangesien hulle gewoonlik test, terraform of ander goed binne die repo op hulle machines uitvoer).
-- **Die pipeline kompromitteer** (check volgende section)
+- **Code compromise:** As 'n kwaadwillige actor een of ander vorm van **write** access oor die repos het, kan hy probeer om **malicious code in te spuit**. Om suksesvol te wees, mag hy dalk **branch protections omseil**. Hierdie aksies kan met verskillende doeleindes in gedagte uitgevoer word:
+- Kompromitteer die main branch om **production te kompromitteer**.
+- Kompromitteer die main (of ander branches) om **ontwikkelaarsmasjiene te kompromitteer** (aangesien hulle gewoonlik test, terraform of ander dinge binne die repo op hul masjiene uitvoer).
+- **Kompromitteer die pipeline** (kyk volgende afdeling)
 
-## Pipelines Pentesting Methodology
+## Pipelines Pentesting Methodologie
 
-Die mees algemene manier om 'n pipeline te definieer, is deur 'n **CI configuration file wat in die repository gehuisves word** wat die pipeline bou. Hierdie file beskryf die volgorde van uitgevoerde jobs, conditions wat die flow beïnvloed, en build environment settings.\
-Hierdie files het tipies 'n konsekwente naam en format, byvoorbeeld — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), en die GitHub Actions YAML files geleë onder .github/workflows. Wanneer dit geaktiveer word, **trek die pipeline job die code** van die geselekteerde source (bv. commit / branch), en **voer die commands wat in die CI configuration file gespesifiseer is uit** teen daardie code.
+Die mees algemene manier om 'n pipeline te definieer, is deur 'n **CI configuration file wat in die repository gehuisves word** wat die pipeline bou. Hierdie file beskryf die volgorde van uitgevoerde jobs, conditions wat die vloei beïnvloed, en build environment settings.\
+Hierdie files het tipies 'n konsekwente naam en formaat, byvoorbeeld — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), en die GitHub Actions YAML files wat onder .github/workflows geleë is. Wanneer dit geaktiveer word, **trek die pipeline job die code** van die geselekteerde source (bv. commit / branch), en **voer die commands uit wat in die CI configuration file gespesifiseer is** teen daardie code.
 
-Daarom is die uiteindelike goal van die attacker om op een of ander manier **daardie configuration files te kompromitteer** of die **commands wat hulle uitvoer**.
+Daarom is die uiteindelike doel van die attacker om op een of ander manier daardie **configuration files te kompromitteer** of die **commands wat hulle uitvoer**.
 
 > [!TIP]
-> Sommige hosted builders laat contributors toe om die Docker build context en Dockerfile path te kies. As die context attacker-controlled is, kan jy dit buite die repo stel (bv. "..") om host files tydens build in te lees en secrets uit te exfiltrate. Sien:
+> Sommige hosted builders laat contributors toe om die Docker build context en Dockerfile path te kies. As die context deur die attacker beheer word, kan jy dit buite die repo plaas (bv. "..") om host files tydens build in te neem en secrets te exfiltrate. Sien:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,67 +58,68 @@ Daarom is die uiteindelike goal van die attacker om op een of ander manier **daa
 
 ### PPE - Poisoned Pipeline Execution
 
-Die Poisoned Pipeline Execution (PPE) path misbruik permissions in 'n SCM repository om 'n CI pipeline te manipuleer en skadelike commands uit te voer. Users met die nodige permissions kan CI configuration files of ander files wat deur die pipeline job gebruik word, verander om kwaadwillige commands in te sluit. Dit “vergiftig” die CI pipeline, wat lei tot die uitvoering van hierdie kwaadwillige commands.
+Die Poisoned Pipeline Execution (PPE) pad misbruik permissions in 'n SCM repository om 'n CI pipeline te manipuleer en skadelike commands uit te voer. Users met die nodige permissions kan CI configuration files of ander files wat deur die pipeline job gebruik word, wysig om malicious commands in te sluit. Dit “vergiftig” die CI pipeline, wat lei tot die uitvoering van hierdie malicious commands.
 
 Vir 'n kwaadwillige actor om suksesvol 'n PPE attack uit te voer, moet hy in staat wees om:
 
-- **write access tot die VCS platform** te hê, aangesien pipelines gewoonlik geaktiveer word wanneer 'n push of 'n pull request uitgevoer word. (Check die VCS pentesting methodology vir 'n opsomming van maniere om toegang te verkry).
-- Let daarop dat 'n **external PR soms as "write access" tel**.
-- Selfs al het hy write permissions, moet hy seker wees hy kan **die CI config file of ander files waarop die config staatmaak, verander**.
-- Hiervoor moet hy dalk in staat wees om **branch protections te omseil**.
+- **write access tot die VCS platform** te hê, aangesien pipelines gewoonlik geaktiveer 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 **external PR as "write access" tel**.
+- Selfs al het hy write permissions, moet hy seker wees hy kan die **CI config file of ander files waarop die config steun, verander**.
+- Hiervoor moet hy dalk in staat wees om **branch protections omseil**.
 
 Daar is 3 PPE flavours:
 
-- **D-PPE**: 'n **Direct PPE** attack vind plaas wanneer die actor die CI config file wat uitgevoer gaan word, **verander**.
-- **I-DDE**: 'n **Indirect PPE** attack vind plaas wanneer die actor 'n **file** wat die CI config file wat uitgevoer gaan word **gebruik** **verander** (soos 'n make file of 'n terraform config).
-- **Public PPE or 3PE**: In sommige gevalle kan die pipelines **geaktiveer word deur users 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 Command Injection**: Gewoonlik sal CI/CD pipelines **environment variables stel** met **information oor die PR**. As daardie value deur 'n attacker beheer kan word (soos die title van die PR) en op 'n **gevaarlike plek** **gebruik** word (soos om **sh commands** uit te voer), kan 'n attacker commands daarin **injekteer**.
+- **D-PPE**: 'n **Direct PPE** attack vind plaas wanneer die actor die **CI config** file wat uitgevoer gaan word, wysig.
+- **I-DDE**: 'n **Indirect PPE** attack vind plaas wanneer die actor 'n **file** wysig waarop die CI config file wat uitgevoer gaan word **steun** (soos 'n make file of 'n terraform config).
+- **Public PPE or 3PE**: In sommige gevalle kan die pipelines geaktiveer word deur users 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 sal CI/CD pipelines **environment variables stel** met **inligting oor die PR**. As daardie waarde deur 'n attacker beheer kan word (soos die title van die PR) en **gebruik** word op 'n **gevaarlike plek** (soos die uitvoering van **sh commands**), kan 'n attacker commands daarin **inject**.
 
 ### Exploitation Benefits
 
-As jy die 3 flavours ken om 'n pipeline te vergiftig, kyk ons wat 'n attacker na suksesvolle exploitation kan verkry:
+Deur die 3 flavours te ken om 'n pipeline te poison, laat ons kyk wat 'n attacker na suksesvolle exploitation kan verkry:
 
-- **Secrets**: Soos voorheen genoem, vereis pipelines **privileges** vir hulle jobs (die code ophaal, bou, ontplooi...) en hierdie privileges word gewoonlik **in secrets toegestaan**. Hierdie secrets is gewoonlik toeganklik via **env variables of files binne die system**. Daarom sal 'n attacker altyd probeer om soveel secrets as moontlik te exfiltrate.
-- Afhangend van die pipeline platform moet die attacker **miskien die secrets in die config spesifiseer**. Dit beteken dat as die attacker nie die CI configuration pipeline kan verander nie (**I-PPE** byvoorbeeld), hy **net die secrets kan exfiltrate wat daardie pipeline het**.
+- **Secrets**: Soos vroeër genoem is, vereis pipelines **privileges** vir hul jobs (die code retrieve, dit bou, dit deploy...) en hierdie privileges word gewoonlik **in secrets toegeken**. Hierdie secrets is gewoonlik toeganklik via **env variables of files binne die system**. Daarom sal 'n attacker altyd probeer om soveel secrets as moontlik te exfiltrate.
+- Afhangend van die pipeline platform moet die attacker **dalk die secrets in die config spesifiseer**. Dit beteken dat as die attacker nie die CI configuration pipeline kan wysig nie (**I-PPE** byvoorbeeld), hy **slegs die secrets kan exfiltrate wat daardie pipeline het**.
 - **Computation**: Die code word iewers uitgevoer, afhangend van waar dit uitgevoer word, kan 'n attacker dalk verder pivot.
 - **On-Premises**: As die pipelines on premises uitgevoer word, kan 'n attacker dalk in 'n **interne network met toegang tot meer resources** beland.
-- **Cloud**: Die attacker kan toegang verkry tot **ander machines in die cloud** maar kan ook **IAM roles/service accounts tokens** daaruit exfiltrate om **verdere access binne die cloud** te verkry.
-- **Platforms machine**: Soms sal die jobs binne die **pipelines platform machines** uitgevoer word, wat gewoonlik binne 'n cloud is met **geen verdere access nie**.
-- **Select it:** Soms sal die **pipelines platform verskeie machines gekonfigureer hê** en as jy die **CI configuration file kan verander** kan jy **aandui waar jy die kwaadwillige code wil laat loop**. In hierdie situasie sal 'n attacker waarskynlik 'n reverse shell op elke moontlike machine laat loop om dit verder te probeer misbruik.
-- **Compromise production**: As jy binne die pipeline is en die finale version word daaruit gebou en ontplooi, kan jy **die code kompromitteer wat uiteindelik in production gaan loop**.
+- **Cloud**: Die attacker kan toegang kry tot **ander machines in die cloud** maar kan ook **IAM roles/service accounts tokens** daarvan exfiltrate om **verdere toegang binne die cloud** te verkry.
+- **Platforms machine**: Soms sal die jobs binne die **pipelines platform machines** uitgevoer word, wat gewoonlik binne 'n cloud is met **geen verdere access** nie.
+- **Select it:** Soms sal die **pipelines platform verskeie machines gekonfigureer hê** en as jy die **CI configuration file kan wysig**, kan jy **aandui waar jy die malicious code wil laat loop**. In hierdie situasie sal 'n attacker waarskynlik 'n reverse shell op elke moontlike machine laat loop om dit verder te probeer exploit.
+- **Compromise production**: As jy binne die pipeline was en die finale weergawe word daaruit gebou en ontplooi, kan jy **die code kompromitteer wat uiteindelik in production gaan loop**.
 
 ### Dependency & Registry Supply-Chain Abuse
 
-Om 'n CI/CD pipeline te kompromitteer of credentials daaruit te steel, kan 'n attacker van **pipeline execution** na **ecosystem-wide code execution** laat beweeg deur dependencies of release tooling te backdoor:
+Die kompromittering van 'n CI/CD pipeline of die steel van credentials daaruit kan 'n attacker laat beweeg van **pipeline execution** na **ecosystem-wide code execution** deur dependencies of release tooling te backdoor:
 
-- **Install-time code execution via package hooks**: publiseer 'n package version wat `preinstall`, `postinstall`, `prepare`, of soortgelyke hooks byvoeg sodat die payload outomaties op developer workstations en CI runners tydens dependency installation loop.
-- **Secondary execution paths**: selfs al installeer targets met `--ignore-scripts`, kan 'n kwaadwillige package steeds 'n **common CLI name** in die `bin` field registreer sodat die attacker-controlled wrapper in `PATH` gesymlink word en later uitvoer wanneer die command gebruik word.
-- **Runtime bootstrapping**: 'n klein installer kan tydens installation 'n tweede runtime of toolchain aflaai (byvoorbeeld Bun of 'n gepakte interpreter) en dan die main payload daarmee begin, wat local dependency requirements vermy.
-- **Credential harvesting from build environments**: sodra code binne CI loop, kontroleer environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs, en local tooling soos `gh auth token`. Op GitHub Actions, kyk ook vir runner-specific secrets en artifacts.
-- **Workflow injection with stolen GitHub tokens**: 'n token met **`repo` + `workflow`** permissions is genoeg om 'n branch te skep, 'n kwaadwillige file binne `.github/workflows/` te commit, dit te aktiveer, die geproduseerde artifacts/logs te versamel, en dan die tydelike branch/workflow run te verwyder om spore te verminder.
-- **Wormable registry propagation**: gesteelde npm tokens moet vir **publish** permissions en of hulle 2FA omseil, geverifieer word. As hulle dit doen, lys writable packages, laai hulle tarballs af, injecteer 'n loader soos `setup.mjs`, stel `preinstall` om dit uit te voer, verhoog die patch version, en republish. Dit verander een CI compromise in downstream auto-execution in ander environments.
+- **Install-time code execution via package hooks**: publiseer 'n package version wat `preinstall`, `postinstall`, `prepare`, of soortgelyke hooks byvoeg sodat die payload outomaties op ontwikkelaarswerkstasies en CI runners tydens dependency installation loop.
+- **Secondary execution paths**: selfs al installeer targets met `--ignore-scripts`, kan 'n malicious package steeds 'n **common CLI name** in die `bin` field registreer sodat die attacker-beheerde wrapper in `PATH` gesymlink word en later uitvoer wanneer die command gebruik word.
+- **Runtime bootstrapping**: 'n klein installer kan tydens installation 'n tweede runtime of toolchain aflaai (byvoorbeeld Bun of 'n packed interpreter) en dan die hoofpayload daarmee begin, wat plaaslike dependency requirements vermy.
+- **Credential harvesting from build environments**: sodra code binne CI loop, kyk na environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs, en local tooling soos `gh auth token`. Op GitHub Actions, kyk ook vir runner-specifieke secrets en artifacts.
+- **Workflow injection with stolen GitHub tokens**: 'n token met **`repo` + `workflow`** permissions is genoeg om 'n branch te skep, 'n malicious file binne `.github/workflows/` te commit, dit te trigger, die geproduseerde artifacts/logs te versamel, en dan die tydelike branch/workflow run te delete om spore te verminder.
+- **Wormable registry propagation**: gesteelde npm tokens moet vir **publish** permissions en of hulle 2FA omseil kan, geverifieer word. As hulle dit kan, enumerat writable packages, download hul tarballs, inject 'n loader soos `setup.mjs`, stel `preinstall` om dit uit te voer, verhoog die patch version, en republish. Dit verander een CI compromise in downstream auto-execution in ander environments.
 
 #### Practical checks during an assessment
 
-- Hersien release automation vir package-manager hooks wat by `package.json` gevoeg is, onverwante `bin` entries, of version bumps wat net die release artifact verander.
-- Kontroleer of CI langlewende registry credentials in plaintext files soos `~/.npmrc` stoor in plaas van kortlewende OIDC of trusted publishing te gebruik.
-- Verifieer of GitHub tokens wat in CI beskikbaar is workflow files kan skryf of branches/tags kan skep.
-- As 'n gekompromitteerde package vermoed word, inspekteer die gepubliseerde tarball en nie net die Git repository nie, omdat die kwaadwillige loader/runtime slegs in die gepubliseerde artifact kan bestaan.
-- Soek vir onverwante package-manager uitvoering binne CI soos `npm install` in plaas van `npm ci`, onverwante Bun downloads/execution, of nuwe workflow artifacts wat vanaf transient branches gegenereer word.
+- Review release automation vir package-manager hooks wat by `package.json` gevoeg is, onverwachte `bin` entries, of version bumps wat net die release artifact verander.
+- Check of CI langlewende registry credentials in plaintext files soos `~/.npmrc` stoor in plaas van kortlewende OIDC of trusted publishing te gebruik.
+- Verify of GitHub tokens wat in CI beskikbaar is workflow files kan write of branches/tags kan skep.
+- As 'n compromised package vermoed word, inspekteer die gepubliseerde tarball en nie net die Git repository nie, omdat die malicious loader/runtime dalk slegs in die gepubliseerde artifact bestaan.
+- Hunt vir onverwachte package-manager execution binne CI soos `npm install` in plaas van `npm ci`, onverwachte Bun downloads/execution, of nuwe workflow artifacts wat uit transient branches gegenereer word.
+- Review GitOps deployment engines ook as CI/CD targets. Argo CD-spesifieke enumerasie, repo-server abuse, en Redis cache poisoning attacks word in [Argo CD Security](argocd-security.md) gedek.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is 'n open-source tool om jou software supply chain stack vir security compliance 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 auditing fokus op die hele SDLC process, waar dit risks van code time tot deploy time kan openbaar.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is 'n open-source tool vir die ouditering van jou software supply chain stack vir security compliance 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 ouditering 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 article oor die top 10 CI/CD risks volgens Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Kyk na hierdie interessante artikel oor die top 10 CI/CD risks 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 lokaal kan laat loop sal jy vind hoe om dit plaaslik te launch sodat jy dit kan configureer soos jy wil om dit te test
+- Op elke platform wat jy plaaslik kan laat loop, sal jy vind 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