Pentesting de pipelines CI/CD: qué hay que auditar
Un pipeline de CI/CD comprometido no da acceso a una sola aplicación: da acceso a la fábrica que construye y despliega todas las aplicaciones. Es una de las superficies con mayor impacto potencial en cualquier organización de desarrollo de software, y sin embargo rara vez se audita con el mismo rigor que la propia aplicación que produce.
Por qué un pipeline comprometido es peor que una aplicación comprometida
Comprometer una aplicación en producción da acceso a esa aplicación concreta. Comprometer el pipeline que la construye da la capacidad de inyectar código malicioso en cada despliegue futuro, de forma persistente y con la firma legítima del proceso de build de la organización. Es exactamente el patrón detrás de los incidentes de cadena de suministro de software más graves de los últimos años: el atacante no ataca el producto final, ataca la fábrica que lo produce, porque el impacto se multiplica por cada release y cada cliente.
Secretos expuestos en variables de entorno, logs y configuración
Los pipelines manejan credenciales de alto valor —claves de despliegue, tokens de registro de paquetes, credenciales cloud con permisos amplios— habitualmente como variables de entorno o secretos gestionados por la plataforma de CI/CD. Los fallos más comunes son: secretos hardcodeados en el propio fichero de configuración del pipeline (versionado en el repositorio), secretos que se filtran en los logs de ejecución por un comando de debug mal gestionado, y secretos con un alcance (scope) excesivo —una clave de despliegue de producción accesible desde un pipeline de una rama de desarrollo cualquiera.
Permisos de runners y ejecución de código no confiable
En repositorios que aceptan contribuciones externas o pull requests de forks, es crítico revisar si los workflows de CI/CD ejecutan automáticamente código de un pull request no confiable con acceso a los mismos secretos que un workflow del repositorio principal. Es un vector de ataque conocido: un atacante externo envía un pull request que, sin necesitar aprobación, ejecuta código arbitrario en el runner con acceso a las credenciales del pipeline. También hay que revisar el aislamiento de los runners auto-hospedados, que si están mal segmentados pueden dar acceso a la red interna de la organización.
Integridad de dependencias y de la cadena de suministro de software
Un pipeline seguro debe verificar la integridad de cada dependencia que instala —usando lockfiles, checksums y, cuando sea posible, firmas de paquetes— para evitar ataques de dependency confusion (publicar un paquete malicioso con el mismo nombre que uno interno en un registro público) o de compromiso de una dependencia legítima aguas arriba. Auditar esto implica revisar la configuración de los registros de paquetes usados, si se generan y verifican SBOMs (Software Bill of Materials), y si existe un proceso de escaneo de dependencias (SCA) integrado en el propio pipeline, no solo ejecutado manualmente de forma ocasional.
FAQ
¿Un pentesting de pipelines CI/CD sustituye a una auditoría de código fuente?
No, son complementarios. La auditoría de código fuente revisa la aplicación en sí (SAST, revisión manual de lógica y vulnerabilidades); el pentesting de pipelines revisa la infraestructura que construye y despliega esa aplicación —secretos, permisos, integridad de dependencias—. Ambas superficies importan porque un atacante puede elegir la más débil.
¿Qué plataformas de CI/CD cubre este tipo de evaluación?
La metodología aplica a cualquier plataforma —GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure DevOps— porque los riesgos (secretos expuestos, permisos de runners, integridad de dependencias) son conceptualmente los mismos, aunque los detalles de configuración cambien entre plataformas.