Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md',

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

@@ -6,7 +6,7 @@
 
 ## VCS
 
-VCS significa **Sistema de Control de Versiones**, este sistema permite a los desarrolladores **gestionar su código fuente**. El más común es **git** y normalmente encontrarás que las empresas lo usan en una de las siguientes **plataformas**:
+VCS significa **Version Control System**, estos sistemas permiten a los desarrolladores **gestionar su source code**. El más común es **git** y normalmente encontrarás empresas usándolo en una de las siguientes **platforms**:
 
 - Github
 - Gitlab
@@ -18,86 +18,86 @@ VCS significa **Sistema de Control de Versiones**, este sistema permite a los de
 
 ## CI/CD Pipelines
 
-Los CI/CD pipelines permiten a los desarrolladores **automatizar la ejecución de código** con varios propósitos, incluyendo construir, testear 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 el desarrollo hasta producción.
+CI/CD pipelines permiten a los desarrolladores **automatizar la ejecución del code** para varios propósitos, incluyendo build, test y deploy de aplicaciones. Estos workflows automatizados se **disparan por acciones específicas**, como code pushes, pull requests, o tareas programadas. Son útiles para optimizar el proceso desde el desarrollo hasta production.
 
-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**.
+Sin embargo, estos sistemas necesitan ser **ejecutados en algún lado** y normalmente con **credenciales privilegiadas para deploy code o acceder a información sensible**.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
+> Incluso si algunas VCS platforms permiten crear pipelines para esta sección vamos a analizar solo ataques potenciales al control del source code.
 
-Las plataformas que contienen el código fuente de tu proyecto guardan información sensible y las personas deben tener mucho cuidado con los permisos concedidos dentro de esa plataforma. Estos son algunos problemas comunes en plataformas VCS que un atacante podría aprovechar:
+Las platforms que contienen el source code de tu proyecto contienen información sensible y la gente debe tener mucho cuidado con los permisos otorgados dentro de esa platform. Estos son algunos problemas comunes en VCS platforms 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 plataforma VCS** podría obtener **más visibilidad y permisos**.
-- **Register**: Algunas plataformas simplemente permiten a usuarios externos crear una cuenta.
-- **SSO**: Algunas plataformas no permiten registrar usuarios, pero permiten que cualquiera acceda con un SSO válido (por ejemplo, un atacante podría usar su cuenta de github para entrar).
-- **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 plataformas VCS permiten generar webhooks. Si no están **protegidos** con secretos no visibles un **atacante podría abusar de ellos**.
-- Si no hay ningún secreto configurado, 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 además obtendría el secreto
-- **Code compromise:** Si un actor malicioso tiene algún tipo de acceso de **escritura** sobre los repos, podría intentar **inyectar código malicioso**. Para tener éxito podría necesitar **bypassear las protecciones de ramas**. Estas acciones pueden realizarse con diferentes objetivos en mente:
-- Comprometer la rama main para **comprometer production**.
-- Comprometer la rama main (u otras ramas) para **comprometer las máquinas de los desarrolladores** (ya que normalmente ejecutan tests, terraform u otras cosas del repo en sus máquinas).
-- **Comprometer el pipeline** (revisar la siguiente sección)
+- **Leaks**: Si tu code 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 VCS platform** podría obtener **más visibilidad y permisos**.
+- **Register**: Algunas platforms simplemente permiten a usuarios externos crear una cuenta.
+- **SSO**: Algunas platforms no permiten registro, pero permiten que cualquiera entre con un SSO válido (por ejemplo un atacante podría usar su cuenta de github para entrar).
+- **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 forma a un repo.
+- **Webhooks**: VCS platforms permiten generar webhooks. Si no están **protegidos** con secretos no visibles un **atacante podría abusar de ellos**.
+- Si no hay un secret en su lugar, el atacante podría abusar del webhook de la plataforma de terceros
+- Si el secret está en la URL, sucede lo mismo y el atacante además tendría el secret
+- **Code compromise:** Si un actor malicioso tiene algún tipo de **write** access 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:
+- Comprometer la main branch para **comprometer production**.
+- Comprometer la main (u otras branches) para **comprometer las máquinas de los developers** (ya que suelen ejecutar tests, terraform u otras cosas del repo en sus máquinas).
+- **Comprometer el pipeline** (revisa la siguiente sección)
 
 ## Pipelines Pentesting Methodology
 
-La forma más común de definir un pipeline es usando un **archivo de configuración de CI alojado en el repositorio** que el pipeline construye. Este archivo describe el orden de los jobs ejecutados, condiciones que afectan el 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 disparan, el job del pipeline **pulls the code** desde la fuente seleccionada (por ejemplo commit / branch), y **ejecuta los comandos especificados en el archivo de configuración de CI** contra ese código.
+La forma más común de definir un pipeline es usando un **CI configuration file alojado en el repository** que el pipeline construye. Este archivo describe el orden de los jobs ejecutados, condiciones que afectan el flujo, y la configuración del build environment.\
+Estos archivos típicamente tienen un nombre y formato consistente, por ejemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), y los GitHub Actions YAML files ubicados bajo .github/workflows. Cuando se dispara, el pipeline job **pulls the code** desde la fuente seleccionada (p. ej. commit / branch), y **ejecuta los comandos especificados en el CI configuration file** contra ese code.
 
-Por lo tanto, el objetivo último del atacante es de alguna manera **comprometer esos archivos de configuración** o los **comandos que ejecutan**.
+Por lo tanto el objetivo final del atacante es de alguna manera **comprometer esos configuration files** o los **comandos que ejecutan**.
 
 ### PPE - Poisoned Pipeline Execution
 
-La ruta Poisoned Pipeline Execution (PPE) explota permisos en un repositorio SCM para manipular un pipeline de CI y ejecutar comandos dañinos. Usuarios con los permisos necesarios pueden modificar archivos de configuración de CI u otros archivos usados por el job del pipeline para incluir comandos maliciosos. Esto "envenena" el pipeline de CI, conduciendo a la ejecución de esos comandos maliciosos.
+El Poisoned Pipeline Execution (PPE) explota permisos en un SCM repository para manipular un CI pipeline y ejecutar comandos dañinos. Usuarios con los permisos necesarios pueden modificar CI configuration files u otros archivos usados por el pipeline job para incluir comandos maliciosos. Esto "envenena" el CI pipeline, llevando a la ejecución de esos comandos maliciosos.
 
-Para que un actor malicioso tenga éxito realizando un ataque PPE necesita poder:
+Para que un actor malicioso tenga éxito realizando un PPE necesita poder:
 
-- Tener **write access to the VCS platform**, ya que normalmente los pipelines se disparan cuando se hace un push o un pull request. (Revisa la VCS pentesting methodology para un resumen de formas de obtener acceso).
-- Notar que a veces un **PR externo cuenta como "write access"**.
-- Incluso si tiene permisos de escritura, necesita asegurarse de que puede **modificar el archivo de config de CI u otros archivos de los que el config depende**.
-- Para esto, podría necesitar ser capaz de **bypassear las protecciones de ramas**.
+- Tener **write access to the VCS platform**, ya que usualmente los pipelines se disparan cuando se realiza un push o un pull request. (Revisa la VCS pentesting methodology para un resumen de maneras de obtener acceso).
+- Nota que a veces un **external PR cuenta como "write access"**.
+- Incluso si tiene permisos de write, necesita estar seguro de que puede **modificar el CI config file u otros archivos de los que el config depende**.
+- Para esto, podría necesitar poder **bypassear branch protections**.
 
-Hay 3 variantes de PPE:
+Hay 3 sabores de PPE:
 
-- **D-PPE**: Un ataque **Direct PPE** ocurre cuando el actor **modifica el CI config** que va a ser ejecutado.
-- **I-DDE**: Un ataque **Indirect PPE** ocurre cuando el actor **modifica** un **archivo** del que el CI config que va a ser ejecutado **depende** (como un make file o una configuración de terraform).
-- **Public PPE or 3PE**: En algunos casos los pipelines pueden ser **disparados por usuarios que no tienen write access en el repo** (y que ni siquiera forman parte de la org) porque pueden enviar un PR.
-- **3PE Command Injection**: Normalmente, los pipelines CI/CD **establecen variables de entorno** 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** (por ejemplo para ejecutar comandos sh), un atacante podría **inyectar comandos ahí**.
+- **D-PPE**: Un ataque **Direct PPE** ocurre cuando el actor **modifica el CI config** file que se va a ejecutar.
+- **I-DDE**: Un ataque **Indirect PPE** ocurre cuando el actor **modifica** un **file** del que el CI config que se va a ejecutar **depende** (como un make file o un terraform config).
+- **Public PPE or 3PE**: En algunos casos los pipelines pueden ser **triggered por users que no tienen write access en el repo** (y que quizás ni siquiera forman parte de la org) porque pueden enviar un PR.
+- **3PE Command Injection**: Usualmente, CI/CD pipelines **set environment variables** con **información sobre el PR**. Si ese valor puede ser controlado por un atacante (como el title 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:
+Conociendo los 3 sabores para envenenar un pipeline, veamos qué podría obtener un atacante tras una explotación exitosa:
 
-- **Secrets**: Como se mencionó anteriormente, los pipelines requieren **privilegios** para sus jobs (recuperar el código, construirlo, desplegarlo...) y estos privilegios suelen estar **almacenados en secrets**. Estos secrets normalmente son accesibles vía **env variables o archivos dentro del sistema**. Por lo tanto un atacante siempre intentará exfiltrar tantos secrets como sea posible.
-- Dependiendo de la plataforma de pipeline el atacante **podría necesitar especificar los secrets en el config**. Esto significa que si el atacante no puede modificar la configuración del pipeline (**I-PPE** por ejemplo), podría **solo exfiltrar los secrets que ese pipeline tiene**.
-- **Computation**: El código se ejecuta en algún lugar; dependiendo de dónde se ejecute un atacante podría pivotar aún más.
-- **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 la nube** pero también podría **exfiltrar** tokens de roles IAM/service accounts para obtener **más acceso dentro de la nube**.
-- **Platforms machine**: A veces los jobs se ejecutan dentro de las **máquinas de la plataforma de pipelines**, que normalmente están en una nube sin **más acceso**.
-- **Select it:** A veces la **plataforma de pipelines tiene 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 ejecutará un reverse shell en cada máquina posible para tratar de explotarla más.
-- **Compromise production**: Si estás dentro del pipeline y la versión final se builda y despliega desde ahí, podrías **comprometer el código que terminará corriendo en production**.
+- **Secrets**: Como se mencionó previamente, los pipelines requieren **privilegios** para sus jobs (retrieve the code, build it, deploy it...) y estos privilegios usualmente se **otorgan en secrets**. Estos secrets suelen ser accesibles vía **env variables o files dentro del sistema**. Por lo tanto un atacante siempre intentará exfiltrar la mayor cantidad de secrets posible.
+- Dependiendo de la plataforma de pipeline el atacante **podría necesitar especificar los secrets en el config**. Esto significa que si el atacante no puede modificar la CI configuration pipeline (**I-PPE** por ejemplo), podría **solo exfiltrar los secrets que ese pipeline tenga**.
+- **Computation**: El code se ejecuta en algún lado; dependiendo de dónde se ejecute un atacante podría pivotar más.
+- **On-Premises**: Si los pipelines se ejecutan On-Premises, un atacante podría terminar en una **red interna 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 allí para obtener **más acceso dentro del cloud**.
+- **Platforms machine**: A veces los jobs se ejecutan dentro de las **máquinas de la plataforma de pipelines**, que usualmente están en una cloud sin **acceso adicional**.
+- **Select it:** A veces la **platform de pipelines tendrá varias máquinas configuradas** 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 ejecutará 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 builda y deploya desde ahí, podrías **comprometer el code que terminará corriendo en production**.
 
 ## 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) es una herramienta open-source para auditar tu software supply chain stack por seguridad y cumplimiento basada en un nuevo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). La auditoría se enfoca en todo el SDLC, donde puede revelar riesgos desde code time hasta deploy time.
 
 ### Top 10 CI/CD Security Risk
 
-Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Revisa este artículo interesante sobre los top 10 CI/CD risks según Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it
+- En cada platform que puedas ejecutar localmente encontrarás cómo lanzarla localmente para que puedas configurarla como quieras y probarla
 - 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** is a static code analysis tool for infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** es una herramienta de análisis estático para infrastructure-as-code.
 
 ## References