Por qué los pipelines CI/CD se convirtieron en el objetivo favorito de los atacantes
La brecha de SolarWinds no comenzó con un correo de phishing ni un bucket S3 mal configurado. Comenzó dentro de un pipeline de build. Los atacantes inyectaron código malicioso directamente en el proceso de construcción del software — y se distribuyó a más de 18.000 clientes sin que se disparara ninguna alerta de seguridad. Eso fue en 2020. Para 2026, los ataques a la cadena de suministro dirigidos a infraestructuras CI/CD se han más que triplicado, según el Informe de Amenazas a la Cadena de Suministro de Software de CISA 2026.
La verdad incómoda: la mayoría de los equipos de ingeniería han invertido fuertemente en seguridad de aplicaciones — escaneos SAST, pruebas DAST, auditorías de dependencias — pero han dejado el pipeline que ejecuta todos esos controles prácticamente desprotegido. Si un atacante compromete el sistema CI/CD, no necesita eludir los controles. Simplemente los desactiva, o peor, hace que parezcan superados.
Esta guía cubre qué significa realmente la seguridad CI/CD en la práctica, qué riesgos OWASP importan más, qué herramientas pertenecen al pipeline y cómo implementar buenas prácticas sin frenar la velocidad de despliegue.
¿Qué es la seguridad CI/CD?
La seguridad CI/CD protege todo el pipeline — desde el commit de código hasta build, test, almacenamiento de artefactos y despliegue — frente a manipulaciones, acceso no autorizado, filtración de secretos e inyección de paquetes maliciosos. Se sitúa en la intersección de la seguridad de aplicaciones, la seguridad de infraestructura y la integridad de la cadena de suministro.
El pipeline es esencialmente un entorno de ejecución privilegiado. El runner de CI tiene credenciales para el proveedor cloud, el registro de contenedores, el clúster de Kubernetes de producción y el gestor de secretos. Si se compromete ese runner, el blast radius equivale al de un SRE senior con permisos de administrador en todos los entornos — no es hipérbole, es la ruta de ataque documentada en la clase de vulnerabilidades de token-hijacking en GitHub Actions.
Top 10 Riesgos de Seguridad CI/CD de OWASP
OWASP mantiene su taxonomía de riesgos CI/CD como un marco independiente del Top 10 clásico de aplicaciones web. Los riesgos que causan más daño real:
CICD-SEC-1: Mecanismos de control de flujo insuficientes
El código llega a producción sin gates de revisión. Implementa reglas de protección de ramas, revisores obligatorios y verificaciones de estado que no puedan ser eludidas por el committer.
CICD-SEC-2: Gestión inadecuada de identidad y acceso
Cuentas de servicio compartidas, claves API de larga duración como variables de entorno, tokens CI con scope a nivel de organización. Cada job del pipeline debería usar credenciales de corta duración y alcance limitado — idealmente OIDC federation con el proveedor cloud.
CICD-SEC-3 a CICD-SEC-10
Abuso de la cadena de dependencias, ejecución de pipeline envenenado (PPE), PBAC insuficiente, higiene deficiente de credenciales, configuraciones de sistema inseguras, registro inadecuado, integridad débil de artefactos y servicios de terceros sin gobierno. Secret Detection debe escanear cada commit y cada log de build. Los artefactos deben firmarse con Sigstore/cosign. Los logs del pipeline deben almacenarse de forma inviolable en un SIEM.
Mejores prácticas de seguridad para pipelines CI/CD
Shift Left — pero sin detenerse ahí
Ejecutar SAST en cada pull request es el mínimo exigible. Pero el shift-left solo aborda el código fuente. También necesitas escaneos en la fase de build (escaneo de imágenes de contenedores, SCA), en la fase de artefactos (firma y generación de SBOM) y en la fase de despliegue (aplicación de políticas). Gates de seguridad en cada punto de transición.
La generación de SBOM es ya estándar
Genera un Software Bill of Materials en formato CycloneDX o SPDX para cada artefacto de build. Tu plataforma de Vulnerability Management debería consumir estos SBOMs y correlacionarlos con puntuaciones NVD y EPSS.
Artefactos inmutables y builds firmados
Usa cosign para firmar imágenes de contenedores en el build. Verifica las firmas en el despliegue con admission controllers. Container Image Scanning debe integrarse en los hooks de push del registro.
Policy as Code
Policy-as-Code define los requisitos de seguridad del pipeline como reglas legibles por máquinas — bloquea builds con imágenes que corren como root, rechaza artefactos sin firma válida, impide despliegues en producción sin un ticket de cambio.
Las mejores herramientas de seguridad CI/CD en 2026
Semgrep para SAST, Gitleaks y TruffleHog para detección de secretos, Trivy para imágenes de contenedores y generación de SBOM, Sigstore para firma de artefactos. Plataformas como SECRAILS integran estas capacidades en un flujo DevSecOps unificado. Para IaC, Checkov y KICS detectan configuraciones erróneas antes del despliegue, complementados por una plataforma CSPM para validar el entorno en vivo.
Medir la madurez de seguridad CI/CD
El framework SLSA, OpenSSF Scorecard y la taxonomía de riesgos OWASP CI/CD son referencias adecuadas. Los resultados deben alimentar el programa de Compliance. La brecha más grande rara vez es la falta de herramientas — son los procesos sin reglas de bloqueo reales y los gates de seguridad con demasiadas excepciones. Comienza con unas pocas reglas de alta precisión y expande desde ahí.