From 86ffd1343dd575aea3c7b901377f10249b835ca5 Mon Sep 17 00:00:00 2001
From: Translator <github-actions@github.com>
Date: Mon, 6 Jul 2026 15:54:43 +0000
Subject: [PATCH] Translated
 ['src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', 'src

---
 src/pentesting-ci-cd/argocd-security.md       | 219 ++++++++++++++++++
 .../pentesting-ci-cd-methodology.md           |  97 ++++----
 2 files changed, 268 insertions(+), 48 deletions(-)
 create mode 100644 src/pentesting-ci-cd/argocd-security.md

diff --git a/src/pentesting-ci-cd/argocd-security.md b/src/pentesting-ci-cd/argocd-security.md
new file mode 100644
index 000000000..7926d7233
--- /dev/null
+++ b/src/pentesting-ci-cd/argocd-security.md
@@ -0,0 +1,219 @@
+# Argo CD Security
+
+{{#include ../banners/hacktricks-training.md}}
+
+## Información básica
+
+[Argo CD](https://argo-cd.readthedocs.io/) es una plataforma de continuous delivery GitOps para Kubernetes. Supervisa repositorios Git, renderiza manifiestos de Kubernetes con herramientas como Helm, Kustomize, Jsonnet o config management plugins, y reconcilia el estado real del cluster con el estado deseado almacenado en Git.
+
+Desde la perspectiva de un atacante, trata Argo CD como un **deployment engine con credenciales de Kubernetes**. Un compromiso útil de Argo CD puede llevar a:
+
+- Acceso a repositorios Git privados y credenciales de repositorio.
+- Acceso a secretos del cluster de Kubernetes usados por Argo CD.
+- Ejecución de código en la generación de manifiestos en `argocd-repo-server`.
+- Despliegue no autorizado de objetos de Kubernetes mediante repositorios Git de confianza, aplicaciones de Argo CD o manipulación de caché.
+
+## Arquitectura y componentes interesantes
+
+Objetos y servicios comunes de Kubernetes:
+```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
+```
+Servicios interesantes:
+
+- **`argocd-server`**: API pública, interfaz web, API de CLI, autenticación y autorización.
+- **`argocd-application-controller`**: compara el estado deseado y el estado activo, luego aplica recursos a Kubernetes.
+- **`argocd-repo-server`**: clona repositorios, cachea datos de Git y ejecuta Helm/Kustomize/Jsonnet/plugins para generar manifests. El puerto gRPC por defecto es **8081**.
+- **`argocd-redis`**: cache para datos de application, manifest y referencias de Git. El puerto Redis por defecto es **6379**.
+- **`argocd-applicationset-controller`**: genera objetos Argo CD `Application` a partir de generators como Git, SCM, clusters y pull requests.
+
+Desde un pod comprometido o un segmento de red interno, comprueba la accesibilidad interna:
+```bash
+nc -vz <argocd-server> 443
+nc -vz <argocd-repo-server> 8081
+nc -vz <argocd-redis> 6379
+```
+## Ataques a la API pública / UI
+
+Si tienes credenciales de Argo CD o una instancia expuesta, empieza con la superficie normal de la API:
+```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>
+```
+Rutas de ataque útiles:
+
+- **Application write access**: modifica `source.repoURL`, `source.path`, valores de Helm, opciones de Kustomize, settings de plugins u opciones de sync para que Argo CD despliegue manifests controlados por el atacante.
+- **Project misconfiguration**: los objetos `AppProject` pueden permitir `sourceRepos` amplios, `destinations` amplios, `clusterResourceWhitelist` inseguro o restricciones de namespace débiles.
+- **Repository credential abuse**: los secretos de repository, credenciales de GitHub App, claves SSH y tokens pueden permitir hacer push a repos confiables o añadir dependencias maliciosas.
+- **Cluster credential abuse**: los secretos de cluster pueden contener bearer tokens o configuración de exec-provider usada por Argo CD para desplegar en clusters de destino.
+- **Local admin / project tokens**: los tokens de Argo CD de larga duración pueden reutilizarse a través de la API salvo que sean revocados o expiren.
+
+Enumera la configuración desde Kubernetes cuando tengas 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
+```
+## Trusted Git Repository Abuse
+
+Si puedes hacer push a un repository en el que Argo CD confía, normalmente puedes influir en lo que se despliega. El impacto depende de los límites de `AppProject` y de los permisos de service account usados por el application controller.
+
+Ubicaciones comunes del payload:
+
+- Raw Kubernetes YAML bajo una ruta de la application.
+- Plantillas de Helm chart y `values.yaml`.
+- Overlays de Kustomize, remote bases y generators.
+- Entrada de Jsonnet o de config management plugin.
+- Archivos generator de ApplicationSet que crean o actualizan objetos `Application`.
+
+Comprueba si la app usa automated sync, pruning, self-heal, sync windows o 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'
+```
+## Abuso directo de `argocd-repo-server`
+
+No asumas que la API pública de Argo CD es la única superficie de ataque. Los componentes internos de Argo CD se comunican con `argocd-repo-server` mediante gRPC. Si pods arbitrarios pueden alcanzar repo-server, las requests internas controladas por un atacante pueden saltarse controles que normalmente impone `argocd-server`.
+
+Comprobaciones prácticas:
+```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
+```
+Señales interesantes:
+
+- El endpoint gRPC de repo-server es accesible desde pods que no son de Argo CD.
+- Faltan NetworkPolicies o solo permiten egress mediante allow-list sin denegar ingress.
+- El repo-server tiene acceso a custom config management plugins, herramientas de decryption o contenido de repository de múltiples tenants.
+- Redis es accesible desde pods que no son de Argo CD, lo que permite inspección o manipulación de la cache si las credentials están disponibles o no se requieren.
+
+## Unauthenticated Repo-Server RCE via Kustomize Options
+
+En julio de 2026, Synacktiv divulgó una cadena de ejecución de código no autenticada en `repo-server` de Argo CD cuando un atacante puede alcanzar el servicio gRPC interno. El ataque abusa del acceso directo a `/repository.RepoServerService/GenerateManifest` y de `KustomizeOptions` controladas por el atacante.
+
+El primitive peligroso es forzar a repo-server a clonar contenido de repository controlado por el atacante y ejecutar Kustomize con soporte de Helm:
+```bash
+kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
+```
+Entrada maliciosa mínima de Kustomize necesita activar el procesamiento de Helm:
+```yaml
+helmCharts:
+- name: pwn
+version: 0.0.1
+```
+Por qué esto funciona:
+
+- `argocd-repo-server` clona el repository antes de renderizar.
+- `--helm-command ./payload.sh` se resuelve relativo al repository clonado.
+- La ejecución de code no requiere inyección de metacharacters de shell si el attacker puede controlar el rendered repository y las Kustomize build options.
+
+En el momento de la divulgación de Synacktiv del 1 de julio de 2026, informaron que el issue no tenía fix oficial ni CVE. Trata esto primero como un issue de network-exposure: la explotación requiere reachability al puerto gRPC interno de `repo-server`.
+
+## Redis Cache Poisoning to Deploy Manifests
+
+Después de code execution en `argocd-repo-server`, o después de acceso directo a Redis con credenciales válidas, inspecciona las cache entries respaldadas por Redis. Argo CD comúnmente almacena valores JSON comprimidos con gzip.
+
+Prefijos de key interesantes:
+```text
+mfst|...       # cached rendered manifests
+git-refs|...   # Git branch/ref to commit mappings
+app|...        # application resource/cache data
+cluster|...    # cluster cache information
+```
+El ataque de cache poisoning descrito por Synacktiv abusa de dos piezas de estado:
+
+1. Modificar la entrada de cache de manifiesto `mfst|...` relevante para incluir un Kubernetes manifest controlado por el atacante.
+2. Modificar el mapeo `git-refs|...` relacionado para que Argo CD crea que la rama se movió y luego vuelva a reconciliar con la revisión en cache.
+
+Impacto:
+
+- Con Auto Sync habilitado, Argo CD puede aplicar automáticamente el cached manifest envenenado.
+- Sin Auto Sync, el payload aún puede aplicarse cuando un usuario sincroniza manualmente la aplicación.
+- El impacto final está limitado por el destino de la aplicación objetivo y los permisos de Kubernetes disponibles para Argo CD.
+
+## ApplicationSet Attacks
+
+ApplicationSet es especialmente sensible porque crea o actualiza objetos `Application` a partir de la salida del generator.
+
+Review:
+```bash
+kubectl get applicationsets.argoproj.io -A -o yaml
+kubectl get appprojects.argoproj.io -A -o yaml
+```
+Patrones interesantes:
+
+- Generadores de git que leen archivos escribibles por el atacante y que controlan nombres de apps, paths, projects o destinations.
+- Generadores de pull request para repositorios públicos donde contributors no confiables pueden influir en las aplicaciones generadas.
+- Campos de template que permiten broad destination clusters/namespaces.
+- AppProjects que permiten `sourceRepos: ["*"]` o broad `destinations`.
+- Applications generadas que heredan automated sync y pruning.
+
+## Post-Exploitation
+
+Desde un shell del pod de Argo CD, prioriza:
+```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'
+```
+Objetivos útiles:
+
+- Robar `REDIS_PASSWORD` o material TLS/client de Redis.
+- Extraer credenciales de repositorio desde secrets montados o Argo CD Kubernetes secrets.
+- Identificar credenciales de cluster usadas por Argo CD.
+- Leer manifests generados y salida de plugins que puedan incluir secrets inyectados.
+- Comprobar si custom plugins, SOPS, Helm secrets, Vault plugins o cloud CLIs exponen decryption keys y cloud credentials.
+
+## Detection & Hardening
+
+Comprobaciones importantes:
+
+- Restringe el puerto **8081** de `argocd-repo-server` y el puerto **6379** de Redis con NetworkPolicies para que solo los componentes esperados de Argo CD puedan पहुंचarlos.
+- En despliegues con Helm, verifica que las network policies se creen realmente. Los valores del Helm chart de Argo CD históricamente han dejado deshabilitada por defecto la creación de network policy para componentes.
+- Mantén `argocd-server` como punto de entrada autenticado. Los servicios internos no deben ser accesibles desde workloads arbitrarios.
+- Deshabilita herramientas y plugins de config management no usados.
+- Restringe `AppProject` `sourceRepos`, `destinations`, permisos de namespace y recursos con ámbito de cluster.
+- Evita almacenar credenciales de repositorio demasiado amplias donde un usuario de Argo CD con pocos privilegios pueda provocar su reutilización.
+- Monitoriza requests a repo-server, Kustomize build options, ejecuciones de plugins, escrituras en Redis y accesos inesperados a claves `mfst|` / `git-refs|`.
+- Rota usuarios locales de Argo CD, tokens de proyecto, credenciales de repositorio y credenciales de cluster después de un compromiso.
+
+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
+```
+## Static Analysis Note: Typed API Requests in CodeQL
+
+Para servicios Go que usan handlers gRPC/REST, las remote sources predeterminadas de CodeQL pueden perder flows una vez que la entrada raw se ha unmarshaled en typed request objects. Un modelo útil para servicios estilo Argo CD es:
+
+- Receiver type como `Server` o `Service`.
+- El primer parámetro es `context.Context`.
+- El segundo parámetro es un typed request object.
+
+Modela ese segundo parámetro como una remote source y añade custom sinks para argumentos de `exec.Command` / `exec.CommandContext`. Esto ayuda a encontrar flows desde campos de internal API request hacia 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)
diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
index 24fd2249e..2acc146f9 100644
--- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
+++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
@@ -6,51 +6,51 @@
 
 ## VCS
 
-VCS significa **Version Control System**, este sistema permite a los desarrolladores **gestionar su código fuente**. El más común es **git** y normalmente encontrarás empresas usándolo en una de las siguientes **platforms**:
+VCS significa **Version Control System**, este systems permite a los desarrolladores **gestionar su código fuente**. El más común es **git** y normalmente encontrarás empresas usándolo en una de las siguientes **plataformas**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (ofrecen sus propias platforms VCS)
+- Cloud providers (ofrecen sus propias plataformas VCS)
 
 
 ## CI/CD Pipelines
 
-Los pipelines CI/CD permiten a los desarrolladores **automatizar la ejecución de código** para diversos propósitos, incluyendo compilar, probar y desplegar aplicaciones. Estos flujos de trabajo automatizados se **activan por acciones específicas**, como pushes de código, pull requests o tareas programadas. Son útiles para agilizar el proceso desde desarrollo hasta producción.
+Los CI/CD pipelines permiten a los desarrolladores **automatizar la ejecución de código** para diversos fines, incluyendo construir, probar y desplegar aplicaciones. Estos flujos de trabajo automatizados se **disparan por acciones específicas**, como pushes de código, pull requests o tareas programadas. Son útiles para agilizar el proceso desde desarrollo hasta producción.
 
-Sin embargo, estos sistemas deben **ejecutarse en algún lugar** y normalmente con **credenciales privilegiadas para desplegar código o acceder a información sensible**.
+Sin embargo, estos sistemas necesitan **ejecutarse en algún lugar** y normalmente con **credenciales privilegiadas para desplegar código o acceder a información sensible**.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Aunque algunas platforms VCS permiten crear pipelines, en esta sección vamos a analizar solo posibles ataques al control del código fuente.
+> Incluso si algunas plataformas VCS permiten crear pipelines, para esta sección vamos a analizar solo ataques potenciales al control del código fuente.
 
-Las platforms que contienen el código fuente de tu proyecto contienen información sensible y la gente debe tener mucho cuidado con los permisos concedidos dentro de esta platform. Estos son algunos problemas comunes en platforms VCS que un atacante podría abusar:
+Las plataformas que contienen el código fuente de tu proyecto contienen información sensible y la gente debe tener mucho cuidado con los permisos concedidos dentro de esta plataforma. Estos son algunos problemas comunes en las plataformas VCS que un atacante podría abusar:
 
 - **Leaks**: Si tu código contiene leaks en los commits y el atacante puede acceder al repo (porque es público o porque tiene acceso), podría descubrir los leaks.
-- **Access**: Si un atacante puede **acceder a una cuenta dentro de la platform VCS** podría obtener **más visibilidad y permisos**.
-- **Register**: Algunas platforms simplemente permitirán que usuarios externos creen una cuenta.
-- **SSO**: Algunas platforms no permitirán que los usuarios se registren, pero sí permitirán que cualquiera acceda con un SSO válido (por ejemplo, un atacante podría usar su cuenta de github para entrar).
+- **Access**: Si un atacante puede **acceder a una cuenta dentro de la plataforma VCS** podría ganar **más visibilidad y permisos**.
+- **Register**: Algunas plataformas simplemente permiten a usuarios externos crear una cuenta.
+- **SSO**: Algunas plataformas no permitirán registrarse, pero sí permitirán que cualquiera acceda con un SSO válido (así que un atacante podría usar su cuenta de github para entrar, por ejemplo).
 - **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... hay varios tipos de tokens que un usuario podría robar para acceder de alguna manera a un repo.
-- **Webhooks**: Las platforms VCS permiten generar webhooks. Si no están **protegidos** con secretos no visibles, un **atacante podría abusar de ellos**.
-- Si no hay secreto configurado, el atacante podría abusar del webhook de la platform de tercero
+- **Webhooks**: Las plataformas VCS permiten generar webhooks. Si **no están protegidos** con secretos no visibles, **un atacante podría abusar de ellos**.
+- Si no hay un secreto, el atacante podría abusar del webhook de la plataforma de terceros
 - Si el secreto está en la URL, ocurre lo mismo y el atacante también tiene el secreto
-- **Code compromise:** Si un actor malicioso tiene algún tipo de acceso de **write** sobre los repos, podría intentar **inyectar código malicioso**. Para tener éxito podría necesitar **bypassear branch protections**. Estas acciones pueden realizarse con distintos objetivos en mente:
-- Comprometer la main branch para **comprometer producción**.
-- Comprometer la main (u otras branches) para **comprometer máquinas de desarrolladores** (ya que normalmente ejecutan tests, terraform u otras cosas dentro del repo en sus máquinas).
-- **Compromise the pipeline** (consulta la siguiente sección)
+- **Code compromise:** Si un actor malicioso tiene algún tipo de acceso de **write** sobre los repos, podría intentar **inyectar código malicioso**. Para tener éxito, podría necesitar **bypassear branch protections**. Estas acciones pueden realizarse con distintos objetivos en mente:
+- Comprometer la rama principal para **comprometer production**.
+- Comprometer la rama principal (u otras ramas) para **comprometer las máquinas de los desarrolladores** (ya que normalmente ejecutan test, terraform u otras cosas dentro del repo en sus máquinas).
+- **Comprometer el pipeline** (consulta la siguiente sección)
 
 ## Pipelines Pentesting Methodology
 
-La forma más común de definir un pipeline es usando un **archivo de configuración CI alojado en el repository** que el pipeline construye. Este archivo describe el orden de los jobs ejecutados, las condiciones que afectan al flujo y la configuración del entorno de build.\
-Estos archivos suelen tener un nombre y formato consistentes, por ejemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) y los archivos YAML de GitHub Actions ubicados en .github/workflows. Cuando se activa, el job del pipeline **descarga el código** desde la fuente seleccionada (por ejemplo, commit / branch) y **ejecuta los comandos especificados en el archivo de configuración CI** contra ese código.
+La forma más común de definir un pipeline es usando un **CI configuration file alojado en el repositorio** que el pipeline construye. Este archivo describe el orden de los jobs ejecutados, las condiciones que afectan al flujo y la configuración del entorno de build.\
+Estos archivos suelen tener un nombre y formato consistentes, por ejemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), y los archivos YAML de GitHub Actions ubicados bajo .github/workflows. Cuando se dispara, el pipeline job **extrae el código** de la fuente seleccionada (p. ej., commit / branch), y **ejecuta los comandos especificados en el CI configuration file** contra ese código.
 
-Por tanto, el objetivo final del atacante es de alguna forma **comprometer esos archivos de configuración** o los **comandos que ejecutan**.
+Por tanto, el objetivo final del atacante es, de algún modo, **comprometer esos archivos de configuración** o los **comandos que ejecutan**.
 
 > [!TIP]
-> Algunos hosted builders permiten a los contributors elegir el Docker build context y la ruta del Dockerfile. Si el context está controlado por el atacante, puedes situarlo fuera del repo (por ejemplo, "..") para ingerir archivos del host durante el build y exfiltrar secrets. Ver:
+> Algunos hosted builders permiten a los contributors elegir el Docker build context y la ruta del Dockerfile. Si el context está controlado por el atacante, puedes ponerlo fuera del repo (p. ej., "..") para ingerir archivos del host durante la build y exfiltrar secretos. Ver:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,59 +58,60 @@ Por tanto, el objetivo final del atacante es de alguna forma **comprometer esos
 
 ### PPE - Poisoned Pipeline Execution
 
-La ruta Poisoned Pipeline Execution (PPE) explota permisos en un repository SCM para manipular un pipeline CI y ejecutar comandos maliciosos. Los usuarios con los permisos necesarios pueden modificar archivos de configuración CI u otros archivos usados por el job del pipeline para incluir comandos maliciosos. Esto "envenena" el pipeline CI, lo que lleva a la ejecución de estos comandos maliciosos.
+La ruta Poisoned Pipeline Execution (PPE) explota permisos en un repositorio SCM para manipular un CI pipeline y ejecutar comandos dañinos. Los usuarios con los permisos necesarios pueden modificar archivos de configuración de CI u otros archivos usados por el pipeline job para incluir comandos maliciosos. Esto "envenena" el CI pipeline, lo que lleva a la ejecución de estos comandos maliciosos.
 
 Para que un actor malicioso tenga éxito realizando un ataque PPE necesita poder:
 
-- Tener **write access to the VCS platform**, ya que normalmente los pipelines se activan cuando se realiza un push o un pull request. (Consulta la metodología VCS pentesting para un resumen de formas de obtener acceso).
+- Tener **write access a la plataforma VCS**, ya que normalmente los pipelines se disparan cuando se realiza un push o un pull request. (Consulta la VCS pentesting methodology para un resumen de formas de obtener acceso).
 - Ten en cuenta que a veces un **external PR cuenta como "write access"**.
-- Incluso teniendo permisos de write, debe asegurarse de poder **modificar el archivo de config CI u otros archivos de los que depende la config**.
-- Para ello, podría necesitar poder **bypassear branch protections**.
+- Incluso con permisos de write, necesita asegurarse de que puede **modificar el CI config file o los otros archivos de los que depende la configuración**.
+- Para ello, puede necesitar ser capaz de **bypassear branch protections**.
 
 Hay 3 variantes de PPE:
 
-- **D-PPE**: Un ataque **Direct PPE** ocurre cuando el actor **modifica el archivo de config CI** que se va a ejecutar.
-- **I-DDE**: Un ataque **Indirect PPE** ocurre cuando el actor **modifica** un **archivo** del que depende el archivo de config CI que se va a ejecutar (como un make file o una config terraform).
-- **Public PPE or 3PE**: En algunos casos los pipelines pueden ser **activados por usuarios que no tienen write access en el repo** (e incluso podrían no formar parte de la org) porque pueden enviar un PR.
-- **3PE Command Injection**: Normalmente, los pipelines CI/CD **establecerán environment variables** con **información sobre el PR**. Si ese valor puede ser controlado por un atacante (como el título del PR) y se **usa** en un **lugar peligroso** (como ejecutar **sh commands**), un atacante podría **inyectar comandos** ahí.
+- **D-PPE**: Un ataque **Direct PPE** ocurre cuando el actor **modifica el CI config** file que va a ejecutarse.
+- **I-DDE**: Un ataque **Indirect PPE** ocurre cuando el actor **modifica** un **archivo** del que depende el CI config file que va a ejecutarse (como un make file o una terraform config).
+- **Public PPE o 3PE**: En algunos casos los pipelines pueden ser **disparados por usuarios que no tienen write access en el repo** (e incluso puede que no formen parte de la org) porque pueden enviar un PR.
+- **3PE Command Injection**: Normalmente, los CI/CD pipelines **establecerán environment variables** con **información sobre el PR**. Si ese valor puede ser controlado por un atacante (como el título del PR) y es **usado** en un **lugar peligroso** (como ejecutar **sh commands**), un atacante podría **inyectar comandos ahí**.
 
 ### Exploitation Benefits
 
 Conociendo las 3 variantes para envenenar un pipeline, veamos qué podría obtener un atacante tras una explotación exitosa:
 
-- **Secrets**: Como se mencionó antes, los pipelines requieren **privilegios** para sus jobs (obtener el código, compilarlo, desplegarlo...) y estos privilegios normalmente se **conceden en secrets**. Estos secrets suelen ser accesibles mediante **env variables o archivos dentro del sistema**. Por tanto, un atacante siempre intentará exfiltrar tantos secrets como sea posible.
-- Dependiendo de la platform del pipeline, el atacante **podría necesitar especificar los secrets en la config**. Esto significa que si el atacante no puede modificar la CI configuration pipeline (**I-PPE** por ejemplo), **solo podría exfiltrar los secrets que tenga ese pipeline**.
-- **Computation**: El código se ejecuta en algún lugar; dependiendo de dónde se ejecute, un atacante podría ser capaz de pivotar más.
-- **On-Premises**: Si los pipelines se ejecutan on premises, un atacante podría acabar en una **internal network con acceso a más recursos**.
-- **Cloud**: El atacante podría acceder a **otras máquinas en la cloud** pero también podría **exfiltrar** IAM roles/service accounts **tokens** de ella para obtener **más acceso dentro de la cloud**.
-- **Platforms machine**: A veces los jobs se ejecutarán dentro de las **máquinas de la platform de pipelines**, que normalmente están dentro de una cloud sin **más acceso**.
-- **Select it:** A veces la **platform de pipelines tendrá configuradas varias máquinas** y si puedes **modificar el archivo de configuración CI** puedes **indicar dónde quieres ejecutar el código malicioso**. En esta situación, un atacante probablemente ejecutará una reverse shell en cada máquina posible para intentar explotarla más.
-- **Compromise production**: Si estás dentro del pipeline y la versión final se construye y despliega desde ahí, podrías **comprometer el código que acabará ejecutándose en producción**.
+- **Secrets**: Como se mencionó antes, los pipelines requieren **privilegios** para sus jobs (obtener el código, construirlo, desplegarlo...) y estos privilegios normalmente se **conceden en secrets**. Estos secrets suelen ser accesibles mediante **env variables o archivos dentro del sistema**. Por tanto, un atacante siempre intentará exfiltrar tantos secrets como sea posible.
+- Dependiendo de la plataforma del pipeline, el atacante **podría necesitar especificar los secrets en la config**. Esto significa que si el atacante no puede modificar el CI configuration pipeline (**I-PPE**, por ejemplo), **solo podría exfiltrar los secrets que tenga ese pipeline**.
+- **Computation**: El código se ejecuta en algún lugar; dependiendo de dónde se ejecute, un atacante podría pivotar más allá.
+- **On-Premises**: Si los pipelines se ejecutan on premises, un atacante podría acabar en una **red interna con acceso a más recursos**.
+- **Cloud**: El atacante podría acceder a **otras máquinas en el cloud** pero también podría **exfiltrar** IAM roles/service accounts **tokens** de allí para obtener **más acceso dentro del cloud**.
+- **Platforms machine**: A veces los jobs se ejecutarán dentro de las **máquinas de la plataforma de pipelines**, que normalmente están dentro de un cloud con **sin más acceso**.
+- **Select it:** A veces la **plataforma de pipelines tendrá configuradas varias máquinas** y, si puedes **modificar el CI configuration file**, puedes **indicar dónde quieres ejecutar el código malicioso**. En esta situación, un atacante probablemente ejecute un reverse shell en cada máquina posible para intentar explotarla más.
+- **Compromise production**: Si estás dentro del pipeline y la versión final se construye y despliega desde ahí, podrías **comprometer el código que va a terminar ejecutándose en production**.
 
 ### Dependency & Registry Supply-Chain Abuse
 
-Comprometer un pipeline CI/CD o robar credenciales de él puede permitir a un atacante pasar de **pipeline execution** a **ecosystem-wide code execution** mediante backdooring de dependencies o tooling de release:
+Comprometer un CI/CD pipeline o robar credenciales de él puede permitir a un atacante pasar de la **pipeline execution** a la **execution de código a nivel de ecosistema** mediante backdooring dependencies o release tooling:
 
-- **Install-time code execution via package hooks**: publica una versión del package que añada hooks `preinstall`, `postinstall`, `prepare` o similares para que el payload se ejecute automáticamente en las estaciones de trabajo de developers y en los runners de CI durante la instalación de dependencies.
-- **Secondary execution paths**: incluso si los objetivos instalan con `--ignore-scripts`, un package malicioso aún puede registrar un **common CLI name** en el campo `bin` para que el wrapper controlado por el atacante se enlace mediante symlink en `PATH` y se ejecute más tarde cuando se use el comando.
-- **Runtime bootstrapping**: un pequeño installer puede descargar un segundo runtime o toolchain durante la instalación (por ejemplo Bun o un interpreter empaquetado) y luego lanzar con él el payload principal, evitando dependencias locales.
-- **Credential harvesting from build environments**: una vez que el código se ejecuta dentro de CI, revisa environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs y tooling local como `gh auth token`. En GitHub Actions, revisa también secrets y artifacts específicos del runner.
-- **Workflow injection with stolen GitHub tokens**: un token con permisos **`repo` + `workflow`** es suficiente para crear una branch, commitear un archivo malicioso dentro de `.github/workflows/`, activarlo, recopilar los artifacts/logs producidos y luego borrar la branch temporal/la ejecución del workflow para reducir rastros.
-- **Wormable registry propagation**: los tokens robados de npm deben validarse para permisos de **publish** y para ver si evitan 2FA. Si lo hacen, enumera packages escribibles, descarga sus tarballs, inyecta un loader como `setup.mjs`, establece `preinstall` para ejecutarlo, incrementa la versión patch y republish. Esto convierte una sola compromise de CI en auto-ejecución aguas abajo en otros entornos.
+- **Install-time code execution via package hooks**: publicar una versión de paquete que añada `preinstall`, `postinstall`, `prepare` o hooks similares para que el payload se ejecute automáticamente en las estaciones de trabajo de los developers y en los CI runners durante la instalación de dependencias.
+- **Secondary execution paths**: incluso si los targets instalan con `--ignore-scripts`, un paquete malicioso todavía puede registrar un **common CLI name** en el campo `bin` para que el wrapper controlado por el atacante se enlace mediante symlink en `PATH` y se ejecute más tarde cuando se use el comando.
+- **Runtime bootstrapping**: un pequeño installer puede descargar un segundo runtime o toolchain durante la instalación (por ejemplo Bun o un interpreter empaquetado) y luego lanzar el payload principal con él, evitando requisitos de dependencias locales.
+- **Credential harvesting from build environments**: una vez que el código se ejecuta dentro de CI, revisa environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, configuraciones de cloud CLI y tooling local como `gh auth token`. En GitHub Actions, busca también secrets y artifacts específicos del runner.
+- **Workflow injection with stolen GitHub tokens**: un token con permisos **`repo` + `workflow`** es suficiente para crear una branch, hacer commit de un archivo malicioso dentro de `.github/workflows/`, dispararlo, recolectar los artifacts/logs producidos y luego borrar la branch temporal/la ejecución del workflow para reducir rastros.
+- **Wormable registry propagation**: los tokens de npm robados deben validarse para permisos de **publish** y comprobar si evaden 2FA. Si lo hacen, enumera los packages escribibles, descarga sus tarballs, inyecta un loader como `setup.mjs`, establece `preinstall` para ejecutarlo, incrementa la versión patch y vuelve a publicar. Esto convierte una sola compromission de CI en auto-ejecución downstream en otros entornos.
 
 #### Practical checks during an assessment
 
-- Revisa la release automation buscando hooks del package-manager añadidos a `package.json`, entradas `bin` inesperadas o incrementos de versión que solo modifiquen el release artifact.
-- Comprueba si CI almacena credenciales de registry de larga duración en archivos en texto plano como `~/.npmrc` en lugar de usar OIDC de corta duración o trusted publishing.
-- Verifica si los tokens de GitHub disponibles en CI pueden escribir archivos de workflow o crear branches/tags.
-- Si se sospecha de un package comprometido, inspecciona el tarball publicado y no solo el Git repository, porque el loader/runtime malicioso puede existir solo en el artifact publicado.
-- Busca ejecución inesperada del package-manager dentro de CI, como `npm install` en lugar de `npm ci`, descargas/ejecución inesperadas de Bun o nuevos artifacts de workflow generados desde branches transitorias.
+- Revisa la automatización de releases en busca de hooks del package-manager añadidos a `package.json`, entradas `bin` inesperadas o incrementos de versión que solo modifican el release artifact.
+- Comprueba si CI almacena credenciales de registry de larga duración en archivos de texto plano como `~/.npmrc` en lugar de usar OIDC de corta duración o trusted publishing.
+- Verifica si los GitHub tokens disponibles en CI pueden escribir workflow files o crear branches/tags.
+- Si se sospecha de un paquete comprometido, inspecciona el tarball publicado y no solo el Git repository, porque el loader/runtime malicioso puede existir solo en el artifact publicado.
+- Busca ejecución inesperada del package-manager dentro de CI como `npm install` en lugar de `npm ci`, descargas/ejecuciones inesperadas de Bun o nuevos workflow artifacts generados desde branches transitorias.
+- Revisa también los motores de despliegue GitOps como objetivos de CI/CD. La enumeración específica de Argo CD, el abuso de repo-server y los ataques de Redis cache poisoning se cubren en [Argo CD Security](argocd-security.md).
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is a open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.
 
 ### Top 10 CI/CD Security Risk