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

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

@@ -0,0 +1,21 @@
+# Gitblit Seguridad
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## ¿Qué es Gitblit
+
+Gitblit es un servidor Git autoalojado escrito en Java. Puede ejecutarse como un JAR independiente o en contenedores servlet y trae un servicio SSH embebido (Apache MINA SSHD) para Git sobre SSH.
+
+## Temas
+
+- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#ref}}
+gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
+{{#endref}}
+
+## Referencias
+
+- [Gitblit project](https://gitblit.com/)
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md

@@ -0,0 +1,107 @@
+# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Summary
+
+CVE-2024-28080 es un bypass de autenticación en el servicio embedded SSH de Gitblit debido a un manejo incorrecto del estado de session al integrarse con Apache MINA SSHD. Si una cuenta de usuario tiene al menos una public key SSH registrada, un atacante que conozca el username y cualquiera de las public keys de ese usuario puede autenticarse sin el private key y sin la password.
+
+- Affected: Gitblit < 1.10.0 (observed on 1.9.3)
+- Fixed: 1.10.0
+- Requirements to exploit:
+- Git over SSH enabled on the instance
+- Victim account has at least one SSH public key registered in Gitblit
+- Attacker knows victim username and one of their public keys (often discoverable, e.g., https://github.com/<username>.keys)
+
+## Root cause (state leaks between SSH methods)
+
+En RFC 4252, la public‑key authentication procede en dos fases: el servidor primero comprueba si una public key proporcionada es aceptable para un username, y solo después de un challenge/response con una signature autentica al user. En MINA SSHD, el PublickeyAuthenticator se invoca dos veces: en la aceptación de la key (aún no hay signature) y más tarde, después de que el cliente devuelva una signature.
+
+El PublickeyAuthenticator de Gitblit mutó el contexto de la session en la primera llamada pre‑signature al asociar el UserModel autenticado a la session y devolver true ("key acceptable"). Cuando la autenticación más tarde cayó de vuelta a password, el PasswordAuthenticator confió en ese estado de session mutado y cortocircuitó, devolviendo true sin validar la password. Como resultado, cualquier password (incluida la vacía) era aceptada después de una previa "acceptance" por public‑key para el mismo user.
+
+Flujo defectuoso a alto nivel:
+
+1) Client offers username + public key (no signature yet)
+2) Server recognizes the key as belonging to the user and prematurely attaches user to the session, returns true ("acceptable")
+3) Client cannot sign (no private key), so auth falls back to password
+4) Password auth sees a user already present in session and unconditionally returns success
+
+## Step‑by‑step exploitation
+
+- Collect a victim’s username and one of their public keys:
+- GitHub exposes public keys at https://github.com/<username>.keys
+- Public servers often expose authorized_keys
+- Configure OpenSSH to present only the public half so signature generation fails, forcing a fallback to password while still triggering the public‑key acceptance path on the server.
+
+Example SSH client config (no private key available):
+```sshconfig
+# ~/.ssh/config
+Host gitblit-target
+HostName <host-or-ip>
+User <victim-username>
+PubkeyAuthentication yes
+PreferredAuthentications publickey,password
+IdentitiesOnly yes
+IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
+```
+Conéctese y presione Enter en el aviso de contraseña (o escriba cualquier cadena):
+```bash
+ssh gitblit-target
+# or Git over SSH
+GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
+```
+La autenticación tiene éxito porque la fase anterior de public‑key mutó la sesión a un usuario autenticado, y password auth confía incorrectamente en ese estado.
+
+Nota: Si ControlMaster multiplexing está habilitado en la configuración de SSH, comandos Git posteriores pueden reutilizar la conexión autenticada, aumentando el impacto.
+
+## Impacto
+
+- Suplantación completa de cualquier usuario de Gitblit que tenga al menos una SSH public key registrada
+- Acceso de lectura/escritura a repositorios según los permisos de la víctima (exfiltración de código fuente, pushes no autorizados, riesgos de supply‑chain)
+- Impacto administrativo potencial si se ataca a un usuario admin
+- Explotación puramente de red; no se requiere fuerza bruta ni private key
+
+## Ideas de detección
+
+- Revisar logs de SSH en busca de secuencias donde un intento de publickey es seguido por una autenticación por password exitosa con una contraseña vacía o muy corta
+- Buscar flujos: método publickey ofreciendo material de clave no soportado/incompatible seguido por un éxito inmediato de password para el mismo nombre de usuario
+
+## Mitigaciones
+
+- Actualizar a Gitblit v1.10.0+
+- Hasta que se actualice:
+- Deshabilitar Git sobre SSH en Gitblit, o
+- Restringir el acceso de red al servicio SSH, y
+- Monitorear los patrones sospechosos descritos arriba
+- Rotar las credenciales de usuarios afectados si se sospecha compromiso
+
+## General: abuso del state‑leakage del método de autenticación SSH (servicios basados en MINA/OpenSSH)
+
+Patrón: Si el public‑key authenticator de un servidor muta el estado de usuario/sesión durante la fase pre‑signature "key acceptable" y otros authenticators (p. ej., password) confían en ese estado, puedes omitir la autenticación mediante:
+
+- Presentar una public key legítima del usuario objetivo (sin private key)
+- Forzar al cliente a fallar en la firma para que el servidor recurra a password
+- Proporcionar cualquier password mientras el password authenticator se ataja por leaked state
+
+Consejos prácticos:
+
+- Public key harvesting at scale: pull public keys from common sources such as https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
+- Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password
+- MINA SSHD integration pitfalls:
+- PublickeyAuthenticator.authenticate(...) no debe adjuntar estado de usuario/sesión hasta que la ruta de verificación post‑signature confirme la firma
+- PasswordAuthenticator.authenticate(...) no debe inferir éxito a partir de cualquier estado mutado durante un método de autenticación previo e incompleto
+
+Notas relacionadas de protocolo/diseño y literatura:
+- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
+- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
+
+## References
+
+- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
+- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)
+- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/)
+- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html)
+- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252)
+
+
+{{#include ../../banners/hacktricks-training.md}}

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

@@ -1,4 +1,4 @@
-# Metodología de Pentesting CI/CD
+# Pentesting CI/CD Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,99 +6,102 @@
 
 ## VCS
 
-VCS significa **Sistema de Control de Versiones**, estos sistemas permiten a los desarrolladores **gestionar su código fuente**. El más común es **git** y generalmente encontrarás empresas usándolo en una de las siguientes **plataformas**:
+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**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
-- Proveedores de la nube (ofrecen sus propias plataformas VCS)
+- Gitblit
+- Cloud providers (they offer their own VCS platforms)
 
-## Pipelines CI/CD
 
-Los pipelines CI/CD permiten a los desarrolladores **automatizar la ejecución de código** para varios propósitos, incluyendo la construcción, prueba y despliegue de aplicaciones. Estos flujos de trabajo automatizados son **activados por acciones específicas**, como pushes de código, pull requests o tareas programadas. Son útiles para agilizar el proceso desde el desarrollo hasta la producción.
+## CI/CD Pipelines
 
-Sin embargo, estos sistemas necesitan ser **ejecutados en algún lugar** y generalmente con **credenciales privilegiadas para desplegar código o acceder a información sensible**.
+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.
 
-## Metodología de Pentesting VCS
+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]
-> Incluso si algunas plataformas VCS permiten crear pipelines, en esta sección solo vamos a analizar los posibles ataques al control del código fuente.
+> 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.
 
-Las plataformas que contienen el código fuente de tu proyecto contienen información sensible y las personas deben tener mucho cuidado con los permisos otorgados dentro de esta plataforma. Estos son algunos problemas comunes en las plataformas VCS que un atacante podría abusar:
+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:
 
-- **Filtraciones**: Si tu código contiene filtraciones en los commits y el atacante puede acceder al repositorio (porque es público o porque tiene acceso), podría descubrir las filtraciones.
-- **Acceso**: Si un atacante puede **acceder a una cuenta dentro de la plataforma VCS**, podría obtener **más visibilidad y permisos**.
-- **Registro**: Algunas plataformas solo permitirán a los usuarios externos crear una cuenta.
-- **SSO**: Algunas plataformas no permitirán a los usuarios registrarse, pero permitirán a cualquiera acceder con un SSO válido (por lo que un atacante podría usar su cuenta de github para entrar, por ejemplo).
-- **Credenciales**: Nombre de usuario + Contraseña, tokens personales, claves ssh, tokens Oauth, cookies... hay varios tipos de tokens que un usuario podría robar para acceder de alguna manera a un repositorio.
-- **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 secreto en su lugar, el atacante podría abusar del webhook de la plataforma de terceros.
-- Si el secreto está en la URL, lo mismo sucede y el atacante también tiene el secreto.
-- **Compromiso de código:** Si un actor malicioso tiene algún tipo de acceso **de escritura** sobre los repositorios, podría intentar **inyectar código malicioso**. Para tener éxito, podría necesitar **eludir las protecciones de rama**. Estas acciones pueden realizarse con diferentes objetivos en mente:
-- Comprometer la rama principal para **comprometer la producción**.
-- Comprometer la principal (u otras ramas) para **comprometer las máquinas de los desarrolladores** (ya que generalmente ejecutan pruebas, terraform u otras cosas dentro del repositorio en sus máquinas).
-- **Comprometer el pipeline** (ver la siguiente sección).
+- **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)
 
-## Metodología de Pentesting de Pipelines
+## Pipelines Pentesting Methodology
 
-La forma más común de definir un pipeline es utilizando un **archivo de configuración CI alojado en el repositorio** que el pipeline construye. Este archivo describe el orden de los trabajos ejecutados, las condiciones que afectan el flujo y la configuración del entorno de construcción.\
-Estos archivos generalmente tienen 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 trabajo del pipeline **extrae el código** de la fuente seleccionada (por ejemplo, commit / rama) 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 **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.
 
-Por lo tanto, el objetivo final del atacante es de alguna manera **comprometer esos archivos de configuración** o los **comandos que ejecutan**.
+Por lo tanto, el objetivo último del atacante es de alguna manera **comprometer esos archivos de configuración** o los **comandos que ejecutan**.
 
-### PPE - Ejecución de Pipeline Envenenado
+### PPE - Poisoned Pipeline Execution
 
-La ruta de Ejecución de Pipeline Envenenado (PPE) explota permisos en un repositorio SCM para manipular un pipeline CI y ejecutar comandos dañinos. Los usuarios con los permisos necesarios pueden modificar archivos de configuración CI u otros archivos utilizados por el trabajo del pipeline para incluir comandos maliciosos. Esto "envenena" el pipeline CI, llevando a la ejecución de estos comandos maliciosos.
+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.
 
-Para que un actor malicioso tenga éxito realizando un ataque PPE, necesita poder:
+Para que un actor malicioso tenga éxito realizando un ataque PPE necesita poder:
 
-- Tener **acceso de escritura a la plataforma VCS**, ya que generalmente los pipelines se activan cuando se realiza un push o un pull request. (Consulta la metodología de pentesting VCS para un resumen de formas de obtener acceso).
-- Ten en cuenta que a veces un **PR externo cuenta como "acceso de escritura"**.
-- Incluso si tiene permisos de escritura, necesita asegurarse de que puede **modificar el archivo de configuración CI u otros archivos de los que depende la configuración**.
-- Para esto, podría necesitar poder **eludir las protecciones de rama**.
+- 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**.
 
-Hay 3 sabores de PPE:
+Hay 3 variantes de PPE:
 
-- **D-PPE**: Un ataque **Directo PPE** ocurre cuando el actor **modifica el archivo de configuración CI** que se va a ejecutar.
-- **I-DDE**: Un ataque **Indirecto PPE** ocurre cuando el actor **modifica** un **archivo** del que el archivo de configuración CI que se va a ejecutar **depende** (como un archivo make o una configuración de terraform).
-- **PPE Público o 3PE**: En algunos casos, los pipelines pueden ser **activados por usuarios que no tienen acceso de escritura en el repositorio** (y que podrían ni siquiera ser parte de la organización) porque pueden enviar un PR.
-- **Inyección de Comandos 3PE**: Generalmente, los pipelines CI/CD **configuran 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 se **usa** en un **lugar peligroso** (como ejecutar **comandos sh**), un atacante podría **inyectar comandos allí**.
+- **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í**.
 
-### Beneficios de la Explotación
+### Exploitation Benefits
 
-Conociendo los 3 sabores para envenenar un pipeline, veamos qué podría obtener un atacante después de una explotación exitosa:
+Conociendo las 3 variantes para envenenar un pipeline, veamos qué podría obtener un atacante tras una explotación exitosa:
 
-- **Secretos**: Como se mencionó anteriormente, los pipelines requieren **privilegios** para sus trabajos (recuperar el código, construirlo, desplegarlo...) y estos privilegios generalmente están **otorgados en secretos**. Estos secretos son generalmente accesibles a través de **variables de entorno o archivos dentro del sistema**. Por lo tanto, un atacante siempre intentará exfiltrar tantos secretos como sea posible.
-- Dependiendo de la plataforma del pipeline, el atacante **podría necesitar especificar los secretos en la configuración**. Esto significa que si el atacante no puede modificar la configuración del pipeline CI (**I-PPE** por ejemplo), podría **solo exfiltrar los secretos que tiene ese pipeline**.
-- **Cómputo**: 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 allá.
-- **On-Premises**: Si los pipelines se ejecutan en las instalaciones, un atacante podría terminar en una **red interna con acceso a más recursos**.
-- **Nube**: El atacante podría acceder a **otras máquinas en la nube** pero también podría **exfiltrar** tokens de cuentas de servicio/roles IAM **de ella para obtener** **más acceso dentro de la nube**.
-- **Máquina de plataformas**: A veces los trabajos se ejecutarán dentro de las **máquinas de la plataforma de pipelines**, que generalmente están dentro de una nube con **sin más acceso**.
-- **Seleccionarlo:** A veces la **plataforma 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á un shell inverso en cada máquina posible para intentar explotarla más.
-- **Comprometer producción**: Si estás dentro del pipeline y la versión final se construye y despliega desde él, podrías **comprometer el código que va a terminar ejecutándose en producción**.
+- **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**.
 
-## Más información relevante
+## More relevant info
 
-### Herramientas y Benchmark CIS
+### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) es una herramienta de código abierto para auditar tu pila de cadena de suministro de software para cumplimiento de seguridad basado en un nuevo [**benchmark de Seguridad de Cadena de Suministro de Software CIS**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). La auditoría se centra en todo el proceso SDLC, donde puede revelar riesgos desde el tiempo de código hasta el tiempo de despliegue.
+- [**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.
 
-### Top 10 Riesgos de Seguridad CI/CD
+### Top 10 CI/CD Security Risk
 
-Consulta este interesante artículo sobre los 10 principales riesgos de CI/CD según Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+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/)
 
-### Laboratorios
+### Labs
 
-- En cada plataforma que puedes ejecutar localmente encontrarás cómo lanzarlo localmente para que puedas configurarlo como desees para probarlo.
-- Laboratorio Gitea + Jenkins: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- 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
+- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
-### Herramientas Automáticas
+### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** es una herramienta de análisis de código estático para infraestructura como código.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for infrastructure-as-code.
 
-## Referencias
+## References
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
 
+
 {{#include ../banners/hacktricks-training.md}}