Un pipeline CI/CD comprometido es tan crítico como una brecha en servidores de producción, porque es la fuente de la cual se generan esos servidores. Protegerlo requiere controles tan o más estrictos que el perimetro de producción.
Qué es CI/CD
CI/CD (Continuous Integration / Continuous Deployment) es un conjunto de prácticas y herramientas que automatizan el proceso de compilación, pruebas y despliegue de código en producción. Integración continua (CI) significa que cada commit de código es automáticamente compilado y probado. Despliegue continuo (CD) lleva cambios validados automáticamente a producción o staging sin intervención manual. Un pipeline CI/CD mal asegurado es una puerta abierta para inyección de código malicioso: un atacante que comprometa credenciales de repositorio o infraestructura de CI/CD puede inyectar malware directamente en aplicaciones desplegadas a millones de usuarios.
Por qué importa
Para un CISO, los pipelines CI/CD representan un punto crítico de riesgo. Son la vía por la que el código se convierte en servicios en producción. Si un atacante puede modificar, redireccionar o inyectar contenido en un pipeline CI/CD, compromete la integridad de todo lo que sale de ahí. Incidentes históricos como SolarWinds y 3CX demostraron que el software supply chain es un objetivo de primer orden. Las prácticas de aseguramiento de CI/CD incluyen: control de acceso basado en roles (RBAC), autenticación multifactor en repositorios, auditoría de cambios de código, pruebas de seguridad automatizadas (SAST, DAST), firma de artefactos compilados, aislamiento de infraestructura de CI/CD, y escaneo de dependencias (SCA) para detectar librerías vulnerables o maliciosas. Sin estas medidas, el riesgo es exponencial.
Puntos clave
Las vulnerabilidades en dependencias (librerías de terceros) se introducen automáticamente en el código compilado si no existe escaneo de dependencias (Software Composition Analysis - SCA) en el pipeline. Una librería popular con vulnerabilidad descubierta puede afectar millones de aplicaciones.
Los secretos (API keys, tokens, contraseñas) no deben estar en código fuente. Deben inyectarse en tiempo de despliegue desde un vault seguro. Un secret expuesto en repositorio es casi imposible de revocar completamente (Git mantiene historiales).
La firma de artefactos garantiza que lo que se deployó es exactamente lo que fue compilado. Sin firma, alguien podría intercambiar un artefacto en tránsito o en almacenamiento sin que se note.
Ejemplo: aseguramiento de pipeline CI/CD en startup tecnológica
Una startup con 50 desarrolladores utiliza GitHub para control de versiones y GitHub Actions para CI/CD. Inicialmente: (1) Cualquier desarrollador puede mergear código a main. (2) Los secrets (API keys de AWS, tokens de base de datos) están en variables de entorno con acceso global. (3) No hay pruebas de seguridad automáticas. (4) Los artefactos compilados no están firmados. Un atacante compromete una cuenta de desarrollador junior. Inyecta código que roba datos de clientes cada noche. El código pasa pruebas funcionales porque la lógica sigue correcta. Se despliega a producción y afecta a 100.000 usuarios antes de ser detectado. Después del incidente, implementan: branch protection en main (requiere revisión de 2 personas), RBAC en GitHub (solo tech leads pueden mergear), secrets en AWS Secrets Manager (inyectados en tiempo de despliegue, no en código), SAST (SonarQube) que bloquea patrones sospechosos antes de mergear, SCA que alerta sobre dependencias vulnerables, firma de artefactos con cosign, y logs de auditoría inmutables. Un nuevo intento de inyección es bloqueado automáticamente en el pull request.
Errores habituales
- Almacenar secretos en repositorio o en código. Una vez en Git, el secreto existe para siempre, incluso si lo borras después. Usar vaults seguros (AWS Secrets Manager, HashiCorp Vault, GitHub Secrets) inyectados en tiempo de despliegue es no-negociable.
- No validar la procedencia del código. Cualquiera que pueda mergear es una vulnerabilidad. Implementar branch protection, requerir reviews de código de personas confiables y usar firmas criptográficas de commits reduce riesgo significativamente.
- Omitir pruebas de seguridad automáticas. SAST (análisis estático), DAST (análisis dinámico) y SCA (análisis de composición) en el pipeline detectan vulnerabilidades antes de que lleguen a producción. Son imprescindibles.
- No auditar quién accede al pipeline ni qué cambios se hacen. Sin logs inmutables de cambios y accesos, es imposible investigar un compromiso. Auditoría y trazabilidad completa son críticas.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿Qué diferencia hay entre CI y CD?
Integración continua (CI) es la automatización de compilación y pruebas cada vez que hay un cambio de código. Despliegue continuo (CD) automatiza la liberación de ese código a producción. CI es obligatorio; CD es opcional si requiere aprobación manual.
¿Cómo protejo credenciales en CI/CD?
Nunca las guardes en código o variables visibles. Usa un vault seguro (AWS Secrets Manager, HashiCorp Vault, GitHub Secrets). El pipeline extrae credenciales del vault solo cuando se ejecuta, con acceso basado en roles (RBAC) estricto.
¿Qué es SAST y DAST en CI/CD?
SAST (Static Application Security Testing) analiza el código fuente sin ejecutarlo, detectando patrones de vulnerabilidad conocidos. DAST (Dynamic Application Security Testing) ejecuta la aplicación y busca vulnerabilidades comportamentales. Ambos deben estar en el pipeline automatizados.
¿Qué es Software Composition Analysis (SCA)?
SCA escanea todas las dependencias (librerías de terceros) de tu código para detectar versiones vulnerables o componentes conocidos como maliciosos. Es crítico porque la mayoría del código moderno depende de decenas o cientos de librerías externas.