OWASP Top 10 de Riesgos CI/CD Explicados con Ejemplos Reales

Los pipelines CI/CD se han convertido en la columna vertebral de la entrega moderna de software. Pero con ese poder viene un riesgo significativo. El proyecto OWASP Top 10 de Riesgos de Seguridad CI/CD cataloga los vectores de ataque más críticos que afectan a los sistemas de integración y entrega continua. En esta guía, desglosamos cada riesgo con ejemplos reales, evaluaciones de impacto y medidas correctivas aplicables a GitHub Actions, GitLab CI y otras plataformas.

Tabla Resumen: OWASP Top 10 de Riesgos CI/CD de un Vistazo

ID	Nombre del Riesgo	Problema Principal	Severidad
CICD-SEC-1	Insufficient Flow Control Mechanisms	Sin aplicación de puertas de aprobación antes de que el código llegue a producción	Crítica
CICD-SEC-2	Inadequate Identity and Access Management	Identidades con permisos excesivos en los sistemas del pipeline	Crítica
CICD-SEC-3	Dependency Chain Abuse	Paquetes maliciosos inyectados a través de la cadena de suministro de software	Alta
CICD-SEC-4	Poisoned Pipeline Execution (PPE)	Los atacantes manipulan las definiciones del pipeline para ejecutar código malicioso	Crítica
CICD-SEC-5	Insufficient PBAC (Pipeline-Based Access Controls)	Pipelines con permisos excesivos más allá de lo que los jobs requieren	Alta
CICD-SEC-6	Insufficient Credential Hygiene	Secretos expuestos en logs, repositorios o compartidos en exceso entre pipelines	Crítica
CICD-SEC-7	Insecure System Configuration	Configuraciones predeterminadas o incorrectas de la plataforma CI/CD	Alta
CICD-SEC-8	Ungoverned Usage of 3rd Party Services	Integraciones de terceros sin verificar con acceso al pipeline	Media
CICD-SEC-9	Improper Artifact Integrity Validation	Sin verificación de que los artefactos de compilación no hayan sido alterados	Alta
CICD-SEC-10	Insufficient Logging and Visibility	Incapacidad para detectar o investigar ataques basados en pipelines	Media

Profundicemos en cada riesgo en detalle.

CICD-SEC-1: Insufficient Flow Control Mechanisms

¿Qué es?

Los mecanismos de control de flujo son las puertas y barreras que gobiernan cómo el código se mueve desde la estación de trabajo del desarrollador hasta producción. Cuando estos controles son insuficientes, un atacante — o incluso un empleado interno malintencionado — puede enviar código directamente a una rama de producción sin revisión por pares, evadir aprobaciones requeridas u omitir verificaciones de seguridad críticas como los análisis SAST y SCA.

Ejemplo Real

En 2021, un investigador demostró cómo un solo desarrollador en una importante empresa tecnológica podía evadir las reglas de protección de ramas enviando código directamente a la rama predeterminada cuando las protecciones no se aplicaban a los administradores. El resultado: código sin probar ni revisar desplegado directamente en producción, sin registro de aprobación. De manera similar, muchas organizaciones configuran sus pipelines para desplegar automáticamente al hacer merge pero olvidan exigir un número mínimo de revisores o requisitos de verificaciones de estado.

Impacto

Un atacante que evade los controles de flujo puede inyectar puertas traseras, desactivar herramientas de seguridad o alterar configuraciones de despliegue — todo sin que nadie lo note hasta que sea demasiado tarde. Este es el riesgo puerta de entrada: si los controles de flujo son débiles, todos los controles posteriores se vuelven menos efectivos.

Medidas Correctivas

Aplicar reglas de protección de ramas en todas las ramas críticas. Exigir al menos dos revisiones aprobatorias antes del merge y no permitir que los administradores omitan estas reglas.
Requerir que las verificaciones de estado pasen antes del merge, incluyendo SAST, linting y pruebas unitarias.
Usar archivos CODEOWNERS para exigir revisiones de equipos específicos para rutas sensibles (por ejemplo, .github/workflows/, Dockerfile, archivos Terraform).
Habilitar commits firmados y verificarlos en el pipeline. Consulta nuestra guía en Laboratorios de Pipelines Seguros para un recorrido práctico.

CICD-SEC-2: Inadequate Identity and Access Management

¿Qué es?

Los entornos CI/CD abarcan múltiples sistemas — control de código fuente, servidores de compilación, registros de artefactos, proveedores de nube y objetivos de despliegue. Cada sistema tiene su propio modelo de identidad. Una gestión inadecuada de IAM significa que las identidades (humanas o de máquina) tienen privilegios excesivos, las cuentas obsoletas persisten o no hay gobernanza centralizada sobre quién o qué puede hacer qué en todo el pipeline.

Ejemplo Real

El ataque a la cadena de suministro de Codecov (abril de 2021) explotó una cuenta de servicio con permisos excesivos. Los atacantes modificaron el script Codecov Bash Uploader para exfiltrar variables de entorno — incluyendo tokens CI y secretos — de miles de pipelines CI/CD de clientes. Como esos tokens CI tenían permisos amplios (a menudo acceso de escritura a repositorios y registros de paquetes), los atacantes pudieron moverse lateralmente por toda la cadena de entrega.

Impacto

Los privilegios excesivos significan que una sola identidad comprometida puede leer secretos, modificar código, alterar definiciones de pipeline, publicar artefactos maliciosos y pivotar a entornos cloud de producción. El radio de impacto es enorme.

Medidas Correctivas

Aplicar el principio de mínimo privilegio a cada identidad — usuarios humanos, cuentas bot y tokens de servicio.
Usar credenciales de corta duración y alcance limitado en lugar de tokens de acceso personal de larga duración. La integración OIDC de GitHub con proveedores cloud es un patrón sólido.
Auditar y rotar credenciales regularmente. Revocar el acceso de los miembros del equipo desvinculados de inmediato.
Centralizar la gestión de identidades mediante SSO/SAML y exigir MFA para todo acceso a plataformas CI/CD. Más información en nuestras guías de Identidad y Acceso.

CICD-SEC-3: Dependency Chain Abuse

¿Qué es?

Las aplicaciones modernas incorporan cientos o miles de dependencias de registros públicos (npm, PyPI, Maven Central, Docker Hub). El abuso de la cadena de dependencias ocurre cuando un atacante inyecta código malicioso en un paquete que tu pipeline instala automáticamente — mediante typosquatting, confusión de dependencias o comprometiendo la cuenta de un mantenedor existente.

Ejemplo Real

En el incidente de ua-parser-js (octubre de 2021), un paquete npm ampliamente utilizado con más de 7 millones de descargas semanales fue comprometido cuando un atacante obtuvo acceso a la cuenta npm del mantenedor. Publicaron versiones maliciosas que instalaban criptomineros y ladrones de credenciales. Cualquier pipeline CI/CD que ejecutara npm install sin versiones fijadas descargó el paquete troyanizado automáticamente.

Impacto

Las dependencias comprometidas se ejecutan dentro de tu entorno de compilación con acceso total a variables de entorno, secretos y conectividad de red. Pueden exfiltrar credenciales, inyectar puertas traseras en tus propios artefactos de compilación o minar criptomonedas en tu infraestructura.

Medidas Correctivas

Fijar dependencias a versiones exactas y usar archivos de bloqueo (package-lock.json, Pipfile.lock, go.sum).
Habilitar la revisión de dependencias en pull requests usando herramientas como dependency-review-action para GitHub Actions.
Usar un registro privado o proxy (Artifactory, Nexus) para cachear y escanear paquetes antes de que entren en tu compilación.
Implementar Software Composition Analysis (SCA) en cada ejecución del pipeline. Consulta nuestras guías de Seguridad de la Cadena de Suministro para patrones de integración.

CICD-SEC-4: Poisoned Pipeline Execution (PPE)

¿Qué es?

Poisoned Pipeline Execution es uno de los riesgos CI/CD más peligrosos. Ocurre cuando un atacante puede modificar el archivo de configuración del pipeline CI/CD (por ejemplo, .github/workflows/, .gitlab-ci.yml, Jenkinsfile) y esa modificación es ejecutada por el pipeline. Existen tres variantes: Direct PPE (D-PPE), donde el atacante modifica el archivo del pipeline directamente; Indirect PPE (I-PPE), donde el atacante modifica archivos que el pipeline referencia (scripts, Makefiles); y Public PPE (3PE), donde pull requests basados en forks activan pipelines en el repositorio objetivo.

Ejemplo Real

En la ola de vulnerabilidades de pull_request_target en GitHub Actions (2020-2021), investigadores de seguridad demostraron que los repositorios públicos que usaban el trigger pull_request_target con checkout explícito del código del PR (mediante actions/checkout con ref: ${{ github.event.pull_request.head.sha }}) permitían a cualquier colaborador externo ejecutar código arbitrario dentro del contexto del repositorio objetivo — con acceso a sus secretos. Importantes proyectos open-source, incluidos varios repositorios de la Apache Foundation, fueron encontrados vulnerables.

Impacto

PPE otorga a los atacantes ejecución de código dentro de tu pipeline con acceso a secretos, credenciales de despliegue y la capacidad de modificar los resultados de la compilación. Es efectivamente ejecución remota de código en tu infraestructura CI/CD.

Medidas Correctivas

Nunca usar pull_request_target con actions/checkout de la referencia head del PR. Usar pull_request en su lugar para código no confiable.
Requerir aprobación para workflows de PR basados en forks en la configuración de GitHub Actions (Settings > Actions > Fork pull request workflows).
Mantener las definiciones del pipeline en ramas protegidas y restringir quién puede modificarlas.
Separar pipelines de compilación y despliegue: el pipeline de compilación (que ejecuta código no confiable) nunca debe tener acceso a credenciales de despliegue a producción. Consulta nuestros laboratorios prácticos para patrones de separación de pipelines.

CICD-SEC-5: Insufficient Pipeline-Based Access Controls (PBAC)

¿Qué es?

PBAC se refiere a los controles de acceso aplicados al propio entorno de ejecución del pipeline. Un PBAC insuficiente significa que los pipelines tienen acceso a recursos, secretos y sistemas que no son necesarios para su job específico. Es el equivalente en el pipeline de violar el mínimo privilegio — un job de compilación para un servicio frontend tiene acceso a credenciales de producción de la base de datos, por ejemplo.

Ejemplo Real

Considera una organización que ejecuta 50 microservicios en un monorepo, todos compartiendo una única configuración CI/CD. Cada job del pipeline — independientemente de qué servicio compile — tiene acceso a todos los secretos del repositorio: URLs de bases de datos de producción, claves root de AWS, certificados de firma. Cuando el job de pruebas de un desarrollador junior falla y vuelca las variables de entorno al log para depuración, los secretos de los 50 servicios quedan expuestos.

Impacto

Cuando un solo job del pipeline es comprometido (a través de PPE, abuso de dependencias o un empleado malintencionado), un PBAC insuficiente significa que el atacante obtiene acceso a mucho más que el servicio específico en compilación. El radio de impacto se expande a cada sistema que el pipeline pueda alcanzar.

Medidas Correctivas

Limitar el alcance de los secretos a entornos y jobs específicos. En GitHub Actions, usar secretos con alcance de entorno con revisores requeridos para entornos de producción.
Usar federación OIDC para acceso cloud en lugar de almacenar credenciales estáticas de nube. Limitar las claims OIDC a repositorios, ramas y entornos específicos.
Restringir los permisos de GITHUB_TOKEN usando la clave permissions a nivel de workflow y job. Usar read-all por defecto y otorgar escritura solo donde sea necesario.
Aislar los runners del pipeline por nivel de sensibilidad — no ejecutar jobs de despliegue a producción en los mismos runners que los jobs de validación de PR. Consulta nuestras guías de Seguridad CI/CD para patrones de arquitectura.

CICD-SEC-6: Insufficient Credential Hygiene

¿Qué es?

Las credenciales (claves API, tokens, contraseñas, certificados) son el elemento vital de los pipelines CI/CD. Una higiene de credenciales insuficiente se refiere a secretos codificados directamente en el código, almacenados en texto plano, impresos en logs, compartidos en exceso, nunca rotados, o que persisten mucho después de que deberían haber sido revocados.

Ejemplo Real

La filtración de Samsung (marzo de 2022) vio al grupo Lapsus$ extraer casi 200 GB de código fuente de los repositorios de Samsung, que contenían credenciales codificadas incluyendo claves de firma privadas y claves API incrustadas directamente en el código fuente. En contextos CI/CD, los investigadores encuentran regularmente secretos impresos en logs de compilación a través de salida de depuración, comandos env o mensajes de error que incluyen cabeceras de autenticación.

Impacto

Las credenciales expuestas dan a los atacantes acceso directo a sistemas posteriores — cuentas cloud, registros de artefactos, bases de datos y objetivos de despliegue — sin necesidad de explotar ninguna vulnerabilidad adicional. Una sola clave AWS filtrada puede comprometer todo un entorno cloud.

Medidas Correctivas

Nunca codificar secretos directamente. Usar el gestor de secretos nativo de tu plataforma (GitHub Encrypted Secrets, GitLab CI/CD Variables con enmascaramiento, HashiCorp Vault).
Habilitar el escaneo de secretos en todos los repositorios para detectar credenciales comprometidas accidentalmente. La protección push de GitHub bloquea commits que contienen patrones de secretos conocidos.
Enmascarar secretos en logs. La mayoría de las plataformas CI soportan enmascaramiento automático, pero verifica que funcione para tus salidas personalizadas.
Rotar credenciales de forma programada e inmediatamente ante una sospecha de exposición. Usar tokens de corta duración (OIDC, STS) siempre que sea posible.
Ejecutar herramientas como trufflehog o gitleaks en tu pipeline para detectar secretos antes de que lleguen a la rama principal. Consulta nuestras guías de Gestión de Secretos para detalles de implementación.

CICD-SEC-7: Insecure System Configuration

¿Qué es?

Las plataformas CI/CD (Jenkins, GitHub Actions, GitLab CI, CircleCI, ArgoCD) vienen con configuraciones predeterminadas que priorizan la facilidad de uso sobre la seguridad. La configuración insegura del sistema cubre errores de configuración como: versiones de software desactualizadas con CVEs conocidos, acceso de red excesivamente permisivo, runners auto-hospedados sin endurecimiento, registro de auditoría deshabilitado e interfaces de administración expuestas.

Ejemplo Real

Miles de instancias de Jenkins están expuestas a internet con configuraciones predeterminadas, muchas ejecutando versiones desactualizadas con vulnerabilidades de ejecución remota de código conocidas (por ejemplo, CVE-2024-23897, una lectura arbitraria de archivos en la CLI de Jenkins). Las búsquedas en Shodan revelan regularmente servidores Jenkins con acceso no autenticado a logs de compilación, definiciones de pipeline y credenciales almacenadas. En 2022, los investigadores encontraron más de 30,000 instancias de Jenkins expuestas, muchas pertenecientes a empresas Fortune 500.

Impacto

Una plataforma CI/CD mal configurada puede exponer credenciales, permitir la ejecución no autorizada de pipelines, proporcionar a los atacantes un punto de apoyo en tu red interna y darles la capacidad de alterar cada artefacto que tu organización produce.

Medidas Correctivas

Endurecer los runners/agentes auto-hospedados. Usar contenedores efímeros que se destruyen después de cada job. Nunca instalar runners en VMs de larga duración que acumulan estado.
Mantener las plataformas CI/CD actualizadas y suscribirse a los avisos de seguridad de tus plataformas específicas.
Restringir el acceso de red a las interfaces de administración CI/CD. Usar VPN o acceso de red zero-trust.
Deshabilitar funcionalidades innecesarias — si tu organización no usa la CLI de Jenkins, deshabilitala. Si no necesitas acceso SSH a los runners, desactívalo.
Aplicar los benchmarks CIS para tus plataformas CI/CD donde estén disponibles. Consulta nuestras guías de Endurecimiento de Pipelines para listas de verificación por plataforma.

CICD-SEC-8: Ungoverned Usage of 3rd Party Services

¿Qué es?

Los pipelines CI/CD modernos se integran con docenas de servicios de terceros: herramientas de calidad de código, escáneres de seguridad, sistemas de notificación, plataformas de despliegue y acciones del marketplace. El uso no gobernado significa que estas integraciones se adoptan sin revisión de seguridad, se les otorgan alcances OAuth excesivos y no se monitorean los cambios en su comportamiento o propiedad.

Ejemplo Real

El compromiso de tj-actions/changed-files (marzo de 2025) demostró este riesgo de forma dramática. Una GitHub Action ampliamente utilizada fue comprometida a través de una cadena de eventos: los atacantes primero comprometieron la acción reviewdog/action-setup, la usaron para robar un PAT del mantenedor de tj-actions, y luego inyectaron código malicioso en tj-actions/changed-files. El código malicioso volcó los secretos CI/CD a los logs de compilación. Como miles de repositorios usaban esta acción con referencias de versión predeterminadas (sin fijar), el radio de impacto fue enorme.

Impacto

Una integración de terceros comprometida puede leer tu código fuente, robar secretos, modificar los resultados de la compilación y desplegar código malicioso — todo dentro del contexto de confianza de tu pipeline. Como estas herramientas a menudo tienen alcances OAuth amplios, un solo compromiso puede propagarse por toda tu organización.

Medidas Correctivas

Fijar las acciones de terceros a SHAs de commit completos, no a tags o nombres de rama. Los tags pueden ser movidos para apuntar a commits maliciosos.
Usar la política actions/allowed-actions de GitHub para restringir qué acciones pueden ejecutarse en tu organización.
Auditar los permisos de aplicaciones OAuth regularmente. Revocar el acceso de herramientas que ya no se utilizan.
Habilitar Dependabot o Renovate para rastrear actualizaciones de tus dependencias de acciones y revisar los cambios cuidadosamente antes de hacer merge. Consulta nuestra sección de Seguridad de la Cadena de Suministro para marcos de gobernanza.

CICD-SEC-9: Improper Artifact Integrity Validation

¿Qué es?

Los artefactos de compilación — imágenes de contenedores, binarios, paquetes — fluyen a través de múltiples sistemas entre la etapa de compilación y el despliegue. La validación inadecuada de la integridad de artefactos significa que no existe un mecanismo para verificar que el artefacto desplegado en producción es exactamente el artefacto producido por el pipeline de compilación de confianza, sin manipulación intermedia.

Ejemplo Real

El ataque SolarWinds SUNBURST (diciembre de 2020) es el ejemplo definitivo. Los atacantes comprometieron el sistema de compilación de SolarWinds e inyectaron una puerta trasera en el software Orion durante el proceso de compilación. Como no existía una verificación independiente de la integridad de los resultados de compilación, la actualización troyanizada fue firmada con el certificado legítimo de SolarWinds y distribuida a aproximadamente 18,000 organizaciones, incluyendo múltiples agencias gubernamentales de Estados Unidos.

Impacto

Sin validación de la integridad de artefactos, los atacantes pueden reemplazar compilaciones legítimas con maliciosas, inyectar puertas traseras durante el tránsito de compilación a despliegue, o reproducir versiones anteriores (vulnerables) de artefactos. Los consumidores de tu software no tienen forma de verificar que recibieron lo que pretendías entregar.

Medidas Correctivas

Firmar todos los artefactos de compilación usando herramientas como Sigstore/Cosign para contenedores o GPG para paquetes tradicionales.
Generar y distribuir SBOMs (Software Bills of Materials) con cada release usando formato SPDX o CycloneDX.
Implementar atestaciones de procedencia SLSA (Supply-chain Levels for Software Artifacts). SLSA Level 2+ asegura que la procedencia de la compilación sea generada por el servicio de compilación mismo, no por el desarrollador.
Verificar los checksums de artefactos en cada etapa del pipeline de entrega — después de la compilación, después del push al registro y antes del despliegue.
Usar admission controllers (por ejemplo, Kyverno, OPA Gatekeeper) en Kubernetes para rechazar imágenes sin firmar o sin atestar. Consulta nuestras guías de Seguridad de Artefactos para recorridos de implementación.

CICD-SEC-10: Insufficient Logging and Visibility

¿Qué es?

Si no puedes ver lo que está sucediendo en tus pipelines, no puedes detectar ataques, investigar incidentes ni demostrar cumplimiento normativo. El registro y la visibilidad insuficientes significan que los eventos CI/CD — ejecuciones de pipeline, cambios de configuración, acceso a secretos, inicios de sesión de usuarios, modificaciones de permisos — no se capturan, no se centralizan, no se monitorean o no se retienen el tiempo suficiente para apoyar la respuesta a incidentes.

Ejemplo Real

Muchas organizaciones descubren compromisos CI/CD semanas o meses después del hecho — si es que los descubren. En la brecha de Codecov, las empresas afectadas tuvieron dificultades para determinar la exposición porque sus logs CI/CD no capturaban qué variables de entorno estaban presentes durante las compilaciones afectadas, o esos logs ya habían sido rotados. Sin registro centralizado, los equipos quedaron adivinando qué secretos necesitaban rotación.

Impacto

Sin visibilidad, cada otro riesgo de esta lista se vuelve más difícil de detectar y responder. Los atacantes pueden operar sin ser detectados, el tiempo de permanencia aumenta y la respuesta a incidentes se convierte en conjeturas en lugar de investigación basada en evidencias. Los marcos de cumplimiento (SOC 2, ISO 27001) también requieren registros de auditoría demostrables para la entrega de software.

Medidas Correctivas

Centralizar los logs CI/CD en un SIEM o plataforma de gestión de logs (Splunk, Elastic, Datadog). No depender únicamente de la retención nativa de logs de la plataforma CI.
Monitorear el comportamiento anómalo del pipeline: tiempos de ejecución inusuales, nuevos archivos de workflow, acceso inesperado a secretos, compilaciones activadas a horas inusuales o pipelines ejecutándose desde ramas no reconocidas.
Habilitar el registro de auditoría en todas las plataformas CI/CD y sistemas SCM. El log de auditoría de GitHub Enterprise, los eventos de auditoría de GitLab y el plugin de registro de auditoría de Jenkins son puntos de partida.
Configurar alertas para eventos de alto riesgo: cambios en archivos de workflow, nuevas instalaciones de aplicaciones OAuth, modificaciones de reglas de protección de ramas y aprobaciones de despliegue fallidas.
Retener logs durante al menos 90 días (más para industrias reguladas). Asegurar que los logs sean inmutables y a prueba de manipulaciones. Consulta nuestras guías de Monitoreo y Registro para patrones de arquitectura.

Construyendo un Programa Integral de Seguridad CI/CD

Abordar el OWASP Top 10 de riesgos CI/CD no es un proyecto puntual — es un programa continuo. Aquí hay un enfoque priorizado:

Comenzar con la visibilidad (CICD-SEC-10): No puedes arreglar lo que no puedes ver. Centraliza el registro primero para tener una línea base.
Bloquear el acceso (CICD-SEC-2, CICD-SEC-5, CICD-SEC-6): Implementar mínimo privilegio para identidades, limitar el alcance de los permisos del pipeline y mejorar la higiene de credenciales. Estos tres riesgos juntos cubren las superficies de ataque más comunes.
Endurecer el pipeline (CICD-SEC-1, CICD-SEC-4, CICD-SEC-7): Aplicar controles de flujo, prevenir la ejecución envenenada de pipelines y endurecer las configuraciones de tu plataforma CI/CD.
Asegurar la cadena de suministro (CICD-SEC-3, CICD-SEC-8, CICD-SEC-9): Fijar dependencias, gobernar las integraciones de terceros e implementar firma y verificación de artefactos.

Cada capa se construye sobre la anterior. Sin visibilidad, no puedes validar que tus controles de acceso funcionan. Sin controles de acceso, el endurecimiento se evade fácilmente. Y sin un pipeline endurecido, los controles de la cadena de suministro pueden ser eludidos.

Conclusión

El OWASP Top 10 de Riesgos de Seguridad CI/CD proporciona un marco integral para comprender y abordar las amenazas que enfrentan los pipelines modernos de entrega de software. Como han demostrado ataques como SolarWinds, Codecov y tj-actions, los pipelines CI/CD son objetivos de alto valor que los atacantes están explotando activamente.

La buena noticia: cada riesgo de esta lista tiene medidas correctivas prácticas e implementables. Al trabajar sistemáticamente a través de estos riesgos — comenzando con la visibilidad y los controles de acceso, luego endureciendo los pipelines y asegurando la cadena de suministro — puedes reducir drásticamente la exposición de tu organización a ataques basados en CI/CD.

¿Listo para ponerlo en práctica? Explora nuestros laboratorios prácticos para implementar estas medidas correctivas en entornos reales de GitHub Actions y GitLab CI, o consulta nuestras guías de Seguridad CI/CD para detalles de implementación por plataforma.