Seguridad para su pipeline CI/CD

Con los Top 10 CI/CD Security Risks (v1.0, 2022), la OWASP Foundation ha catalogado de forma sistemática las debilidades típicas de los entornos de build y despliegue: «Insufficient Flow Control Mechanisms» (CICD-SEC-1), «Inadequate Identity and Access Management» (CICD-SEC-2), «Dependency Chain Abuse» (CICD-SEC-3), «Poisoned Pipeline Execution» (CICD-SEC-4), «Insufficient PBAC (Pipeline-Based Access Controls)» (CICD-SEC-5), «Insufficient Credential Hygiene» (CICD-SEC-6), «Insecure System Configuration» (CICD-SEC-7), «Ungoverned Usage of 3rd Party Services» (CICD-SEC-8), «Improper Artifact Integrity Validation» (CICD-SEC-9) e «Insufficient Logging and Visibility» (CICD-SEC-10). El catálogo resulta idóneo como matriz de evaluación para un assessment estructurado de su propio panorama de pipelines, independientemente de si utiliza GitHub Actions, GitLab CI/CD o Jenkins.

En una Poisoned Pipeline Execution, un atacante con acceso al sistema de código fuente manipula el proceso de build sin necesidad de comprometer el propio entorno de build. OWASP distingue tres variantes: en la Direct PPE (D-PPE), el atacante modifica directamente el archivo de configuración de CI; en la Indirect PPE (I-PPE), inyecta código en archivos referenciados como makefiles o scripts de test; y la Public PPE (3PE) aprovecha pull requests de contribuidores anónimos en repositorios públicos. Contramedidas eficaces: ejecutar código no revisado únicamente en runners aislados sin acceso a secretos, iniciar los pipelines de contribuidores externos solo tras una aprobación manual y cargar las configuraciones de CI desde ramas protegidas.

«Dependency Chain Abuse» agrupa los ataques a través de la cadena de suministro de paquetes: dependency confusion, dependency hijacking, typosquatting y brandjacking. En la dependency confusion, el atacante publica en un registro público un paquete con el nombre de un paquete interno y un número de versión superior; si el gestor de paquetes resuelve la dependencia dando preferencia a la fuente pública, el código malicioso acaba en el build. El investigador de seguridad Alex Birsan demostró la técnica en 2021 en los sistemas de build de más de 35 organizaciones, entre ellas Apple, Microsoft y PayPal. Las contramedidas incluyen un proxy de registro interno como única fuente de suministro, la fijación de las versiones de los paquetes mediante archivos de lock junto con la verificación de sumas de comprobación y firmas, scopes de organización para paquetes privados, así como la ejecución de los scripts de instalación en contextos aislados sin acceso a secretos.

Los pipelines necesitan acceso a registros, entornos cloud y destinos de despliegue, por lo que las credenciales se acumulan allí de forma natural. «Insufficient Credential Hygiene» (CICD-SEC-6) describe las consecuencias: secretos de larga duración y con amplios privilegios que pueden acabar en logs, artefactos o repositorios forkeados. La palanca más eficaz es el cambio a credenciales federadas y de corta duración: a través de OpenID Connect (OIDC), la plataforma de CI emite por cada job un token de identidad firmado, que el proveedor cloud valida contra una relación de confianza previamente definida y canjea por un token de acceso de corta duración, válido únicamente para ese job y que expira automáticamente. Las credenciales cloud almacenadas de forma estática y la rotación manual quedan así en gran medida eliminadas; el secret scanning y una gestión centralizada de secretos siguen siendo necesarios como medidas complementarias.

El principio de mínimo privilegio también se aplica al entorno de ejecución: los runners deberían recibir por pipeline únicamente los permisos mínimos necesarios y, en el mejor de los casos, operarse de forma efímera, es decir, descartarse tras cada job. Las reglas de branch protection con revisiones y status checks obligatorios impiden que cambios no revisados —incluidas configuraciones de CI manipuladas— lleguen a la rama principal; los commits firmados garantizan la autoría de los cambios. Los artefactos firmados y las attestations de procedencia permiten verificar criptográficamente antes del despliegue que un artefacto procede realmente del pipeline esperado; con Sigstore/Cosign incluso en modo «keyless», mediante certificados efímeros vinculados a una identidad OIDC y el registro de transparencia público Rekor. Con ello aborda al mismo tiempo «Improper Artifact Integrity Validation» (CICD-SEC-9); contra «Insufficient Logging and Visibility» (CICD-SEC-10) ayuda un registro exhaustivo y analizado de forma centralizada de toda la actividad de los pipelines.

Supply-chain Levels for Software Artifacts (SLSA) es una especificación intersectorial bajo el paraguas de la OpenSSF (Linux Foundation) que traduce las medidas de refuerzo en niveles verificables. El Build Track define los niveles L1 a L3: desde la procedencia generada automáticamente que documenta cómo se construyó un artefacto (L1), pasando por la procedencia firmada de una plataforma de build alojada (L2), hasta builds reforzados y aislados entre sí, en los que el material de firma queda fuera del alcance de los pasos de build definidos por el usuario (L3). La versión actual 1.2 (estado «Approved», 11/2025) incorpora por primera vez un Source Track que aborda la integridad de la gestión del código fuente. NIST SP 800-204D (02/2024) aporta guías de implementación complementarias; encontrará un análisis más detallado en nuestro artículo de conocimiento sobre la seguridad de la cadena de suministro SLSA.