Translated ['src/pentesting-ci-cd/argocd-security.md', 'src/pentesting-c

src/pentesting-ci-cd/argocd-security.md

@@ -0,0 +1,219 @@
+# Argo CD Security
+
+{{#include ../banners/hacktricks-training.md}}
+
+## Basic Information
+
+[Argo CD](https://argo-cd.readthedocs.io/) ni jukwaa la GitOps la continuous delivery kwa Kubernetes. Linafuatilia Git repositories, hutoa Kubernetes manifests kwa kutumia tools kama Helm, Kustomize, Jsonnet au config management plugins, na kusawazisha hali ya cluster iliyo hai na state lengwa iliyohifadhiwa kwenye Git.
+
+Kutoka kwa mtazamo wa attacker, chukulia Argo CD kama **deployment engine yenye Kubernetes credentials**. Compromise yenye manufaa ya Argo CD inaweza kusababisha:
+
+- Access kwa private Git repositories na repository credentials.
+- Access kwa Kubernetes cluster secrets zinazotumiwa na Argo CD.
+- Manifest generation code execution katika `argocd-repo-server`.
+- Unauthorized Kubernetes object deployment kupitia trusted Git repositories, Argo CD applications, au 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
+```
+Huduma za kuvutia:
+
+- **`argocd-server`**: public API, web UI, CLI API, authentication and authorization.
+- **`argocd-application-controller`**: inalisha desired na live state, kisha inatumia resources kwa Kubernetes.
+- **`argocd-repo-server`**: ina-clone repositories, ina-cache Git data, na inaendesha Helm/Kustomize/Jsonnet/plugins kutengeneza manifests. Default gRPC port ni **8081**.
+- **`argocd-redis`**: cache kwa application, manifest na Git reference data. Default Redis port ni **6379**.
+- **`argocd-applicationset-controller`**: inazalisha Argo CD `Application` objects kutoka kwa generators kama Git, SCM, clusters na pull requests.
+
+Kutoka kwenye compromised pod au internal network segment, kagua internal reachability:
+```bash
+nc -vz <argocd-server> 443
+nc -vz <argocd-repo-server> 8081
+nc -vz <argocd-redis> 6379
+```
+## Public API / UI Mashambulizi
+
+Ikiwa una Argo CD credentials au instance iliyofichuliwa, anza na normal 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>
+```
+Njia muhimu za attack:
+
+- **Application write access**: rekebisha `source.repoURL`, `source.path`, Helm values, Kustomize options, plugin settings au sync options ili Argo CD idisploy manifests zinazodhibitiwa na attacker.
+- **Project misconfiguration**: vitu vya `AppProject` vinaweza kuruhusu `sourceRepos` pana, `destinations` pana, `clusterResourceWhitelist` isiyo salama, au vizuizi dhaifu vya namespace.
+- **Repository credential abuse**: repository secrets, GitHub App credentials, SSH keys na tokens zinaweza kuruhusu kusukuma kwenda trusted repos au kuongeza malicious dependencies.
+- **Cluster credential abuse**: cluster secrets zinaweza kuwa na bearer tokens au exec-provider configuration zinazotumiwa na Argo CD ku-deploy kwenda target clusters.
+- **Local admin / project tokens**: Argo CD tokens za muda mrefu zinaweza kutumika tena kupitia API isipokuwa zifutwe au ziishe muda wake.
+
+Enumerate configuration from Kubernetes when you have cluster read access:
+```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
+```
+## Matumizi Mabaya ya Trusted Git Repository
+
+Ukipata uwezo wa push kwenye repository inayoaminika na Argo CD, kwa kawaida unaweza kuathiri kinachotumwa. Athari hutegemea mipaka ya `AppProject` na ruhusa za service account zinazotumiwa na application controller.
+
+Sehemu za kawaida za kuweka payload:
+
+- Raw Kubernetes YAML chini ya application path.
+- Helm chart templates na `values.yaml`.
+- Kustomize overlays, remote bases na generators.
+- Jsonnet au config management plugin input.
+- ApplicationSet generator files zinazounda au kusasisha `Application` objects.
+
+Angalia kama app inatumia automated sync, pruning, self-heal, sync windows au manual approvals:
+```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'
+```
+## Matumizi mabaya ya moja kwa moja ya `argocd-repo-server`
+
+Usidhani API ya umma ya Argo CD ndiyo tu attack surface. Vipengele vya ndani vya Argo CD huwasiliana na `argocd-repo-server` kupitia gRPC. Ikiwa pods za ndani zinaweza kufikia repo-server, maombi ya ndani yanayodhibitiwa na attacker yanaweza bypass checks ambazo kawaida hutekelezwa na `argocd-server`.
+
+Ukaguzi wa vitendo:
+```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
+```
+Taarifa za kuvutia:
+
+- Endpoint ya gRPC ya repo-server inafikiwa kutoka pods zisizo za Argo CD.
+- NetworkPolicies hazipo au zinaruhusu tu egress kwa allow-list bila kuzuia ingress.
+- repo-server ina access kwa custom config management plugins, decryption tools, au repository content kutoka kwa tenants wengi.
+- Redis inafikiwa kutoka kwa pods zisizo za Argo CD, ikiruhusu inspection ya cache au tampering ikiwa credentials zinapatikana au hazihitajiki.
+
+## Unauthenticated Repo-Server RCE via Kustomize Options
+
+Mnamo Julai 2026, Synacktiv ilifichua chain ya code execution isiyo na authentication katika `repo-server` ya Argo CD wakati mshambuliaji anaweza kufikia internal gRPC service. Shambulio linatumia direct access kwa `/repository.RepoServerService/GenerateManifest` na `KustomizeOptions` zinazodhibitiwa na mshambuliaji.
+
+Primitive hatari ni kulazimisha repo-server ku-clone attacker-controlled repository content na kuendesha Kustomize na Helm support:
+```bash
+kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
+```
+Ingizo la Kustomize lenye uovu la chini kabisa linahitajika ili kuchochea usindikaji wa Helm:
+```yaml
+helmCharts:
+- name: pwn
+version: 0.0.1
+```
+Kwa nini hii inafanya kazi:
+
+- `argocd-repo-server` hu-clone repository kabla ya rendering.
+- `--helm-command ./payload.sh` hutatuliwa relative to the cloned repository.
+- Code execution haihitaji shell metacharacter injection ikiwa attacker anaweza kudhibiti repository iliyorerenderiwa na Kustomize build options.
+
+Wakati wa disclosure ya Synacktiv ya July 1, 2026, waliripoti kwamba issue hiyo haikuwa na fix rasmi wala CVE. Chukulia hili kwanza kama issue ya network-exposure: exploitation inahitaji reachability kwa internal repo-server gRPC port.
+
+## Redis Cache Poisoning to Deploy Manifests
+
+Baada ya code execution katika `argocd-repo-server`, au baada ya direct access kwa Redis na valid credentials, kagua Redis-backed cache entries. Argo CD kwa kawaida huhifadhi gzip-compressed JSON values.
+
+Interesting key prefixes:
+```text
+mfst|...       # cached rendered manifests
+git-refs|...   # Git branch/ref to commit mappings
+app|...        # application resource/cache data
+cluster|...    # cluster cache information
+```
+Shambulio la cache poisoning lililoelezewa na Synacktiv linatumia vipande viwili vya state:
+
+1. Rekebisha entry ya cache ya manifest ya `mfst|...` husika ili ijumuishe Kubernetes manifest inayodhibitiwa na mshambuliaji.
+2. Rekebisha mapping ya `git-refs|...` husika ili Argo CD iamini kuwa branch imehamia na kisha ifanye reconcile kurudi kwenye cached revision.
+
+Impact:
+
+- Ikiwa Auto Sync imewezeshwa, Argo CD inaweza kutumia poisoned cached manifest kiotomatiki.
+- Bila Auto Sync, payload bado inaweza kutumika wakati user anasynchronise application kwa mkono.
+- Impact ya mwisho inazuiliwa na destination ya application lengwa na Kubernetes permissions zinazopatikana kwa Argo CD.
+
+## ApplicationSet Attacks
+
+ApplicationSet ni nyeti hasa kwa sababu huunda au husasisha `Application` objects kutoka kwenye output ya generator.
+
+Review:
+```bash
+kubectl get applicationsets.argoproj.io -A -o yaml
+kubectl get appprojects.argoproj.io -A -o yaml
+```
+Mitindo ya kuvutia:
+
+- Git generators zinazosoma faili zinazoweza kuandikwa na mshambuliaji ambazo hudhibiti majina ya app, paths, projects au destinations.
+- Pull request generators kwa public repositories ambapo contributors wasioaminika wanaweza kuathiri applications zinazozalishwa.
+- Template fields zinazoruhusu broad destination clusters/namespaces.
+- AppProjects zinazoruhusu `sourceRepos: ["*"]` au broad `destinations`.
+- Generated applications zinazorithi automated sync na pruning.
+
+## Post-Exploitation
+
+Kutoka kwenye Argo CD pod shell, prioritize:
+```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'
+```
+Madhumuni muhimu:
+
+- Iiba `REDIS_PASSWORD` au Redis TLS/client material.
+- Toa repository credentials kutoka kwenye mounted secrets au Argo CD Kubernetes secrets.
+- Tambua cluster credentials zinazotumiwa na Argo CD.
+- Soma generated manifests na plugin output ambazo zinaweza kuwa na injected secrets.
+- Angalia kama custom plugins, SOPS, Helm secrets, Vault plugins au cloud CLIs zinafichua decryption keys na cloud credentials.
+
+## Detection & Hardening
+
+Ukaguzi muhimu:
+
+- Zuia `argocd-repo-server` port **8081** na Redis port **6379** kwa kutumia NetworkPolicies ili ni Argo CD components zinazotarajiwa pekee ziweze kuifikia.
+- Katika Helm deployments, hakikisha network policies zinaundwa kweli. Argo CD Helm chart values kihistoria zilikuwa na default ya component network policy creation kuwa disabled.
+- Weka `argocd-server` kama authenticated entry point. Internal services hazipaswi kufikiwa na arbitrary workloads.
+- Zima unused config management tools na plugins.
+- Zuia `AppProject` `sourceRepos`, `destinations`, namespace permissions na cluster-scoped resources.
+- Epuka kuhifadhi broad repository credentials mahali ambapo Argo CD user mwenye low privilege anaweza kusababisha zitumike tena.
+- Fuatilia repo-server requests, Kustomize build options, plugin executions, Redis writes na unexpected access kwenye `mfst|` / `git-refs|` keys.
+- Rotate Argo CD local users, project tokens, repository credentials na cluster credentials baada ya compromise.
+
+Useful 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
+```
+## Kumbuka ya Static Analysis: Typed API Requests katika CodeQL
+
+Kwa Go services zinazotumia gRPC/REST handlers, default CodeQL remote sources zinaweza kukosa flows mara raw input inapokuwa imeshafanywa unmarshal kuwa typed request objects. Mfano unaofaa kwa huduma za Argo CD-style ni:
+
+- Receiver type kama `Server` au `Service`.
+- Kigezo cha kwanza ni `context.Context`.
+- Kigezo cha pili ni typed request object.
+
+Model hiyo kigezo cha pili kama remote source na ongeza custom sinks kwa argument za `exec.Command` / `exec.CommandContext`. Hii husaidia kupata flows kutoka kwenye internal API request fields kwenda kwenye command execution helpers.
+
+## 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)

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

@@ -1,4 +1,4 @@
-# Mbinu ya Pentesting ya CI/CD
+# Pentesting CI/CD Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,51 +6,51 @@
 
 ## VCS
 
-VCS inasimama kwa **Version Control System**, mfumo huu unaruhusu watengenezaji **kusimamia source code yao**. Ya kawaida zaidi ni **git** na kwa kawaida utapata makampuni yakitumia moja ya **platforms** zifuatazo:
+VCS inasimamia **Version Control System**, mifumo hii inaruhusu developers **kusimamia source code yao**. Ya kawaida zaidi ni **git** na kwa kawaida utaona kampuni zikitumia kwenye mojawapo ya **platforms** zifuatazo:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (wanatoa platforms zao wenyewe za VCS)
+- Cloud providers (wanatoa VCS platforms zao wenyewe)
 
 
 ## CI/CD Pipelines
 
-CI/CD pipelines huwawezesha watengenezaji **ku-automate utekelezaji wa code** kwa madhumuni mbalimbali, ikiwemo kuijenga, kui-test, na kui-deploy applications. Workflows hizi za kiotomatiki **huchochewa na actions mahususi**, kama code pushes, pull requests, au kazi zilizopangwa. Ni muhimu kwa kurahisisha mchakato kutoka development hadi production.
+CI/CD pipelines huwawezesha developers **ku-automate utekelezaji wa code** kwa madhumuni mbalimbali, ikiwemo kujenga, kupima, na deploy applications. Workflow hizi za otomatiki **huchochewa na actions maalum**, kama code pushes, pull requests, au scheduled tasks. Ni muhimu kwa kurahisisha mchakato kutoka development hadi production.
 
-Hata hivyo, mifumo hii inahitaji **kutekelezwa mahali fulani** na kwa kawaida kwa **privileged credentials** ili ku-deploy code au kufikia taarifa nyeti.
+Hata hivyo, mifumo hii inahitaji **kutekelezwa mahali fulani** na kwa kawaida kwa **privileged credentials ili deploy code au kufikia taarifa nyeti**.
 
-## Mbinu ya Pentesting ya VCS
+## VCS Pentesting Methodology
 
 > [!NOTE]
-> Hata kama baadhi ya platforms za VCS huruhusu kuunda pipelines kwa sehemu hii tutaichambua tu mashambulizi yanayowezekana dhidi ya udhibiti wa source code.
+> Hata kama baadhi ya VCS platforms huruhusu kuunda pipelines kwa sehemu hii tutaangalia tu attacks zinazowezekana dhidi ya control ya source code.
 
-Platforms zinazohifadhi source code ya project yako zina taarifa nyeti na watu wanahitaji kuwa waangalifu sana na permissions zinazotolewa ndani ya platform hii. Haya ni baadhi ya matatizo ya kawaida katika platforms za VCS ambayo attacker anaweza kutumia vibaya:
+Platforms zinazobeba source code ya project yako zina taarifa nyeti na watu wanahitaji kuwa waangalifu sana na permissions zinazotolewa ndani ya platform hii. Haya ni baadhi ya matatizo ya kawaida katika VCS platforms ambayo attacker anaweza kutumia vibaya:
 
 - **Leaks**: Ikiwa code yako ina leaks kwenye commits na attacker anaweza kufikia repo (kwa sababu ni public au kwa sababu ana access), anaweza kugundua leaks hizo.
-- **Access**: Ikiwa attacker anaweza **kufikia account ndani ya platform ya VCS** anaweza kupata **mwonekano zaidi na permissions zaidi**.
-- **Register**: Baadhi ya platforms zitaruhusu tu users wa nje kuunda account.
-- **SSO**: Baadhi ya platforms hazitaruhusu users kujiandikisha, lakini zitaruhusu mtu yeyote kufikia kwa kutumia SSO halali (kwa hiyo attacker anaweza kutumia account yake ya github kuingia, kwa mfano).
+- **Access**: Ikiwa attacker anaweza **kufikia account ndani ya VCS platform** anaweza kupata **mwonekano zaidi na permissions zaidi**.
+- **Register**: Baadhi ya platforms zitaruhusu tu external users kuunda account.
+- **SSO**: Baadhi ya platforms hazitaruhusu users kujisajili, lakini zitaruhusu mtu yeyote kufikia kwa kutumia valid SSO (hivyo attacker anaweza kutumia github account yake kuingia kwa mfano).
 - **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... kuna aina kadhaa za tokens ambazo user anaweza kuiba ili kwa namna fulani kufikia repo.
-- **Webhooks**: Platforms za VCS huruhusu kuunda webhooks. Ikiwa hazijalindwa **kwa secrets zisizoonekana** an **attacker could abuse them**.
-- Ikiwa hakuna secret iliyowekwa, attacker anaweza kutumia vibaya webhook ya third party platform
-- Ikiwa secret iko kwenye URL, kitu kimoja hutokea na attacker pia anapata secret hiyo
-- **Code compromise:** Ikiwa actor mbaya ana aina fulani ya access ya **write** kwenye repos, anaweza kujaribu **kudunga malicious code**. Ili awe na mafanikio huenda akahitaji **kuepuka branch protections**. Vitendo hivi vinaweza kufanywa kwa malengo tofauti akilini:
+- **Webhooks**: VCS platforms huruhusu kutengeneza webhooks. Ikiwa **hazijalindwa** kwa non visible secrets **attacker anaweza kuzitumia vibaya**.
+- Ikiwa hakuna secret imewekwa, attacker anaweza kutumia vibaya webhook ya third party platform
+- Ikiwa secret iko kwenye URL, jambo lilelile hutokea na attacker pia ana secret hiyo
+- **Code compromise:** Ikiwa malicious actor ana aina fulani ya **write** access juu ya repos, anaweza kujaribu **kuinject malicious code**. Ili kufanikiwa anaweza kuhitaji **kuepuka branch protections**. Haya matendo yanaweza kufanywa kwa malengo tofauti akilini:
 - Kuharibu main branch ili **kuharibu production**.
-- Kuharibu main (au branches nyingine) ili **kuharibu machines za developers** (kwa kawaida wao hu-execute test, terraform au mambo mengine ndani ya repo kwenye machines zao).
+- Kuharibu main (au branches nyingine) ili **kuharibu developer machines** (kwa kawaida huendesha test, terraform au vitu vingine ndani ya repo kwenye machines zao).
 - **Kuharibu pipeline** (angalia sehemu inayofuata)
 
-## Mbinu ya Pentesting ya Pipelines
+## Pipelines Pentesting Methodology
 
-Njia ya kawaida zaidi ya kufafanua pipeline ni kwa kutumia **CI configuration file iliyohostiwa kwenye repository** ambayo pipeline huijenga. File hii hueleza mpangilio wa jobs zinazotekelezwa, conditions zinazoathiri flow, na settings za build environment.\
-Files hizi kwa kawaida zina jina na format thabiti, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files zilizo chini ya .github/workflows. Inapochochewa, pipeline job **huchukua code** kutoka kwenye source iliyochaguliwa (k.m. commit / branch), na **huendesha commands zilizobainishwa katika CI configuration file** dhidi ya code hiyo.
+Njia ya kawaida zaidi ya kufafanua pipeline ni kwa kutumia **CI configuration file iliyo hostiwa ndani ya repository** ambayo pipeline huijenga. Faili hii inaeleza mpangilio wa jobs zinazotekelezwa, conditions zinazoathiri flow, na build environment settings.\
+Faili hizi kwa kawaida zina jina na format thabiti, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files zilizoko chini ya .github/workflows. Inapochochewa, pipeline job **hu-pull code** kutoka source iliyochaguliwa (mfano commit / branch), na **huendesha commands zilizobainishwa kwenye CI configuration file** dhidi ya code hiyo.
 
-Kwa hiyo lengo la mwisho la attacker ni kwa namna fulani **kuharibu files hizo za configuration** au **commands wanazotekeleza**.
+Kwa hiyo lengo kuu la attacker ni kwa njia fulani **kuharibu configuration files hizo** au **commands wanazotekeleza**.
 
 > [!TIP]
-> Baadhi ya hosted builders huruhusu contributors kuchagua Docker build context na Dockerfile path. Ikiwa context inadhibitiwa na attacker, unaweza kuiweka nje ya repo (k.m., "..") ili kuchukua host files wakati wa build na ku-exfiltrate secrets. Tazama:
+> Baadhi ya hosted builders huruhusu contributors kuchagua Docker build context na Dockerfile path. Ikiwa context inadhibitiwa na attacker, unaweza kuiweka nje ya repo (kwa mfano, "..") ili kuchukua host files wakati wa build na exfiltrate secrets. Tazama:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,72 +58,73 @@ Kwa hiyo lengo la mwisho la attacker ni kwa namna fulani **kuharibu files hizo z
 
 ### PPE - Poisoned Pipeline Execution
 
-Njia ya Poisoned Pipeline Execution (PPE) hutumia permissions ndani ya SCM repository ili ku-manipulate CI pipeline na ku-execute commands hatari. Users wenye permissions zinazohitajika wanaweza kurekebisha CI configuration files au files nyingine zinazotumiwa na pipeline job ili kujumuisha commands za uhalifu. Hii "hu-poison" CI pipeline, na kusababisha utekelezaji wa commands hizi za uhalifu.
+Njia ya Poisoned Pipeline Execution (PPE) hutumia permissions ndani ya SCM repository ili kuendesha CI pipeline vibaya na kutekeleza commands hatari. Users wenye permissions zinazohitajika wanaweza kubadilisha CI configuration files au files nyingine ambazo pipeline job hutumia ili kujumuisha malicious commands. Hii "huchafua" CI pipeline, na kusababisha utekelezaji wa commands hizo mbaya.
 
-Ili actor mbaya afanikiwe katika kufanya shambulizi la PPE anahitaji kuwa na uwezo wa:
+Ili malicious actor afanikiwe kufanya PPE attack inambidi aweze:
 
-- Kuwa na **write access kwenye platform ya VCS**, kwa kawaida pipelines huchochewa wakati push au pull request inapofanyika. (Angalia VCS pentesting methodology kwa muhtasari wa njia za kupata access).
-- Kumbuka kwamba wakati mwingine **external PR huhesabika kama "write access"**.
+- Kuwa na **write access kwenye VCS platform**, kwa kuwa kwa kawaida pipelines huchochewa wakati push au pull request inapofanyika. (Angalia VCS pentesting methodology kwa muhtasari wa njia za kupata access).
+- Kumbuka kwamba wakati mwingine **external PR huhesabiwa kama "write access"**.
 - Hata akiwa na write permissions, anahitaji kuhakikisha anaweza **kurekebisha CI config file au files nyingine ambazo config inategemea**.
 - Kwa hili, huenda akahitaji kuwa na uwezo wa **kuepuka branch protections**.
 
-Kuna aina 3 za PPE:
+Kuna flavours 3 za PPE:
 
-- **D-PPE**: Shambulizi la **Direct PPE** hutokea wakati actor **anarekebisha CI config** file ambayo ita-executeiwa.
-- **I-DDE**: Shambulizi la **Indirect PPE** hutokea wakati actor **anarekebisha** **file** ambayo CI config file itakayotekelezwa **inategemea** (kama make file au terraform config).
-- **Public PPE or 3PE**: Katika baadhi ya hali pipelines zinaweza **kuchochewa na users ambao hawana write access kwenye repo** (na huenda hata wasiwe sehemu ya org) kwa sababu wanaweza kutuma PR.
-- **3PE Command Injection**: Kwa kawaida, CI/CD pipelines zita**weka environment variables** zenye **taarifa kuhusu PR**. Ikiwa value hiyo inaweza kudhibitiwa na attacker (kama title ya PR) na **inatumika** mahali **hatari** (kama ku-execute **sh commands**), attacker anaweza **ku-dunga commands humo**.
+- **D-PPE**: Attack ya **Direct PPE** hutokea wakati actor **anabadilisha CI config** file ambayo itatekelezwa.
+- **I-DDE**: Attack ya **Indirect PPE** hutokea wakati actor **anabadilisha** **file** ambayo CI config file itakayotekelezwa **inategemea** (kama make file au terraform config).
+- **Public PPE or 3PE**: Katika baadhi ya hali pipelines zinaweza **kuchochewa na users wasio na write access kwenye repo** (na huenda hata wasiwe sehemu ya org) kwa sababu wanaweza kutuma PR.
+- **3PE Command Injection**: Kwa kawaida, CI/CD pipelines zitaweka **environment variables** zenye **taarifa kuhusu PR**. Ikiwa value hiyo inaweza kudhibitiwa na attacker (kama title ya PR) na **inatumiwa** mahali **hatari** (kama kutekeleza **sh commands**), attacker anaweza **kuinject commands hapo**.
 
-### Faida za Utekelezaji
+### Exploitation Benefits
 
-Kujua aina 3 za ku-poison pipeline, hebu tuone attacker anaweza kupata nini baada ya exploitation iliyofanikiwa:
+Kujua flavours 3 za kuharibu pipeline, hebu tuchunguze attacker anaweza kupata nini baada ya exploitation kufanikiwa:
 
-- **Secrets**: Kama ilivyotajwa hapo awali, pipelines zinahitaji **privileges** kwa jobs zake (kuchukua code, kuijenga, ku-deploy...) na privileges hizi kwa kawaida **hutolewa katika secrets**. Secrets hizi kwa kawaida zinaweza kufikiwa kupitia **env variables au files ndani ya system**. Kwa hiyo attacker atajaribu kila wakati ku-exfiltrate secrets nyingi iwezekanavyo.
-- Kulingana na platform ya pipeline, attacker **huenda akahitaji kubainisha secrets kwenye config**. Hii inamaanisha kwamba ikiwa attacker hawezi kurekebisha CI configuration pipeline (**I-PPE** kwa mfano), anaweza **ku-exfiltrate tu secrets ambazo pipeline hiyo inazo**.
-- **Computation**: Code hu-executeiwa mahali fulani, kulingana na mahali inapo-executeiwa attacker anaweza kuweza pivot zaidi.
-- **On-Premises**: Ikiwa pipelines zina-executeiwa on premises, attacker anaweza kuishia kwenye **internal network yenye access kwa resources zaidi**.
-- **Cloud**: Attacker anaweza kufikia **machines nyingine kwenye cloud** lakini pia anaweza **ku-exfiltrate** IAM roles/service accounts **tokens** kutoka humo ili kupata **access zaidi ndani ya cloud**.
-- **Platforms machine**: Wakati mwingine jobs zita-executeiwa ndani ya **pipelines platform machines**, ambazo kwa kawaida ziko ndani ya cloud bila **access zaidi**.
-- **Select it:** Wakati mwingine **pipelines platform itakuwa ime-configure machines kadhaa** na kama unaweza **kurekebisha CI configuration file** unaweza **kuashiria unapotaka ku-run code mbaya**. Katika hali hii, attacker pengine ata-run reverse shell kwenye kila machine linalowezekana ili kujaribu kulichukua zaidi.
-- **Kuharibu production**: Ikiwa uko ndani ya pipeline na version ya mwisho hujengwa na ku-deployiwa kutoka humo, unaweza **kuharibu code ambayo itakwenda kuishia iki-run kwenye production**.
+- **Secrets**: Kama ilivyotajwa awali, pipelines zinahitaji **privileges** kwa jobs zake (kuchukua code, kuijenga, kuideploy...) na privileges hizi kwa kawaida **hutolewa ndani ya secrets**. Secrets hizi kwa kawaida zinaweza kufikiwa kupitia **env variables au files ndani ya system**. Kwa hiyo attacker ataendelea kujaribu **kutoa nje secrets nyingi iwezekanavyo**.
+- Kulingana na pipeline platform attacker **anaweza kuhitaji kubainisha secrets kwenye config**. Hii inamaanisha kwamba ikiwa attacker hawezi kurekebisha CI configuration pipeline (**I-PPE** kwa mfano), anaweza **tu kutoa nje secrets ambazo pipeline hiyo inazo**.
+- **Computation**: Code inatekelezwa mahali fulani, kulingana na mahali inapoendeshwa attacker anaweza kuweza pivot zaidi.
+- **On-Premises**: Ikiwa pipelines zinaendeshwa on premises, attacker anaweza kuishia ndani ya **internal network yenye access zaidi kwenye resources**.
+- **Cloud**: Attacker anaweza kufikia **machines nyingine kwenye cloud** lakini pia anaweza **kutoa nje** IAM roles/service accounts **tokens** kutoka humo ili kupata **access zaidi ndani ya cloud**.
+- **Platforms machine**: Wakati mwingine jobs zitaendeshwa ndani ya **pipelines platform machines**, ambazo kwa kawaida ziko ndani ya cloud bila **access zaidi**.
+- **Select it:** Wakati mwingine **pipelines platform itakuwa imeconfigura machines kadhaa** na ikiwa unaweza **kurekebisha CI configuration file** unaweza **kubainisha unapotaka kuendesha malicious code**. Katika hali hii, attacker huenda akaendesha reverse shell kwenye kila machine inayowezekana ili kujaribu kuiexploit zaidi.
+- **Compromise production**: Ikiwa uko ndani ya pipeline na final version inajengwa na deploy from it, unaweza **kuharibu code ambayo itaishia ikiendeshwa production**.
 
-### Supply-Chain Abuse ya Dependency & Registry
+### Dependency & Registry Supply-Chain Abuse
 
-Kuharibu CI/CD pipeline au kuiba credentials kutoka humo kunaweza kumruhusu attacker kuhama kutoka **pipeline execution** kwenda **ecosystem-wide code execution** kwa ku-backdoor dependencies au release tooling:
+Kuharibu CI/CD pipeline au kuiba credentials kutoka humo kunaweza kuruhusu attacker kusogea kutoka **pipeline execution** hadi **ecosystem-wide code execution** kwa backdooring dependencies au release tooling:
 
-- **Install-time code execution via package hooks**: publish version ya package inayoongeza `preinstall`, `postinstall`, `prepare`, au hooks zinazofanana ili payload i-run kiotomatiki kwenye developer workstations na CI runners wakati wa dependency installation.
-- **Secondary execution paths**: hata kama targets wana-install kwa `--ignore-scripts`, malicious package bado inaweza kusajili **common CLI name** kwenye `bin` field hivyo wrapper inayodhibitiwa na attacker ina-symlinkiwa ndani ya `PATH` na baadaye ina-executewa command hiyo inapotumiwa.
-- **Runtime bootstrapping**: installer ndogo inaweza kupakua second runtime au toolchain wakati wa installation (kwa mfano Bun au packed interpreter) kisha ku-launch main payload nayo, ikiepuka local dependency requirements.
-- **Credential harvesting from build environments**: mara code inapo-run ndani ya CI, angalia environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs, na local tooling kama `gh auth token`. Kwenye GitHub Actions, pia tafuta runner-specific secrets na artifacts.
-- **Workflow injection with stolen GitHub tokens**: token yenye permissions za **`repo` + `workflow`** inatosha kuunda branch, ku-commit file mbaya ndani ya `.github/workflows/`, kuichochea, kukusanya artifacts/logs zilizozalishwa, kisha kufuta temporary branch/workflow run ili kupunguza traces.
-- **Wormable registry propagation**: stolen npm tokens zinapaswa kuthibitishwa kwa permissions za **publish** na kama zinapita 2FA. Kama zinapita, enumerate writable packages, pakua tarballs zake, dunga loader kama `setup.mjs`, weka `preinstall` ili i-execute, ongeza patch version, na republish. Hii hugeuza compromise moja ya CI kuwa auto-execution ya downstream kwenye mazingira mengine.
+- **Install-time code execution via package hooks**: publish package version inayoongeza `preinstall`, `postinstall`, `prepare`, au hooks zinazofanana ili payload iendeshe kiotomatiki kwenye developer workstations na CI runners wakati wa dependency installation.
+- **Secondary execution paths**: hata ikiwa targets zinasinstall kwa `--ignore-scripts`, malicious package bado inaweza kusajili **common CLI name** kwenye `bin` field ili wrapper inayodhibitiwa na attacker iunganishwe kupitia symlink kwenye `PATH` na kutekelezwa baadaye command hiyo itakapotumika.
+- **Runtime bootstrapping**: installer ndogo inaweza kupakua second runtime au toolchain wakati wa installation (kwa mfano Bun au packed interpreter) na kisha ku-launch main payload nayo, ikiepuka local dependency requirements.
+- **Credential harvesting from build environments**: mara code inapoendeshwa ndani ya CI, kagua environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs, na local tooling kama `gh auth token`. Kwenye GitHub Actions, pia tafuta runner-specific secrets na artifacts.
+- **Workflow injection with stolen GitHub tokens**: token yenye permissions za **`repo` + `workflow`** inatosha kuunda branch, commit malicious file ndani ya `.github/workflows/`, kuichochea, kukusanya artifacts/logs zilizozalishwa, kisha kufuta temporary branch/workflow run ili kupunguza traces.
+- **Wormable registry propagation**: stolen npm tokens zinapaswa kuthibitishwa kwa permissions za **publish** na kama zinapita 2FA. Kama zinapita, enumerate writable packages, download tarballs zao, inject loader kama `setup.mjs`, weka `preinstall` ili kuiendesha, ongeza patch version, na republish. Hii hugeuza CI compromise moja kuwa downstream auto-execution kwenye mazingira mengine.
 
 #### Practical checks during an assessment
 
-- Kagua release automation kwa package-manager hooks zilizoongezwa kwenye `package.json`, unexpected `bin` entries, au version bumps zinazobadilisha release artifact pekee.
-- Angalia kama CI huhifadhi registry credentials za muda mrefu kwenye files wazi kama `~/.npmrc` badala ya kutumia short-lived OIDC au trusted publishing.
+- Kagua release automation kwa package-manager hooks zilizoongezwa kwenye `package.json`, unexpected `bin` entries, au version bumps zinazobadilisha tu release artifact.
+- Angalia kama CI huhifadhi long-lived registry credentials kwenye plaintext files kama `~/.npmrc` badala ya kutumia short-lived OIDC au trusted publishing.
 - Thibitisha kama GitHub tokens zinazopatikana kwenye CI zinaweza kuandika workflow files au kuunda branches/tags.
-- Ikiwa package iliyoharibiwa inashukiwa, kagua published tarball na si Git repository pekee, kwa sababu malicious loader/runtime inaweza kuwepo tu kwenye artifact iliyopublished.
-- Tafuta unexpected package-manager execution ndani ya CI kama `npm install` badala ya `npm ci`, unexpected Bun downloads/execution, au new workflow artifacts zinazotokana na transient branches.
+- Ikiwa compromised package inashukiwa, kagua published tarball na si tu Git repository, kwa sababu malicious loader/runtime inaweza kuwepo tu kwenye published artifact.
+- Tafuta unexpected package-manager execution ndani ya CI kama `npm install` badala ya `npm ci`, unexpected Bun downloads/execution, au new workflow artifacts zinazozalishwa kutoka transient branches.
+- Kagua GitOps deployment engines pia kama CI/CD targets. Argo CD-specific enumeration, repo-server abuse, na Redis cache poisoning attacks zimefunikwa katika [Argo CD Security](argocd-security.md).
 
-## Taarifa zaidi zinazohusiana
+## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ni tool ya open-source ya kukagua software supply chain stack yako kwa security compliance kulingana na [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) mpya. Ukaguzi unalenga SDLC process nzima, ambapo unaweza kufichua risks kutoka code time hadi deploy time.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ni open-source tool ya auditing software supply chain stack yako kwa security compliance kulingana na mpya [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Auditing hujikita kwenye mchakato mzima wa SDLC, ambapo inaweza kufichua risks kutoka code time hadi deploy time.
 
 ### Top 10 CI/CD Security Risk
 
-Angalia makala hii ya kuvutia kuhusu top 10 CI/CD risks kulingana na Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Soma article hii ya kuvutia kuhusu top 10 CI/CD risks kulingana na Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Kwenye kila platform unayoweza kui-run locally utapata jinsi ya kui-launch locally ili uweze kuiconfigure jinsi unavyotaka kuijaribu
+- Kwenye kila platform unayoweza kuendesha locally utapata jinsi ya kui-launch locally ili uweze kui-configure upendavyo ili kuipima
 - 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** ni tool ya static code analysis kwa infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ni static code analysis tool kwa infrastructure-as-code.
 
 ## References