Durante años, los programas de seguridad de aplicaciones se han centrado en los entornos de producción: fortalecer servidores, parchear vulnerabilidades, desplegar WAFs y monitorizar el comportamiento en tiempo de ejecución. Ese enfoque tenía sentido cuando la mayoría de los compromisos significativos ocurrían después del despliegue, al explotar debilidades en las aplicaciones en ejecución.
Pero los atacantes modernos eluden cada vez más las defensas de producción. En lugar de atacar la aplicación en tiempo de ejecución, comprometen los sistemas que construyen, empaquetan y entregan el software: los pipelines CI/CD y la software supply chain que los respalda.
En muchas organizaciones, los pipelines CI/CD son ahora un objetivo más valioso y más frágil que la propia producción. La razón es simple: los pipelines se sitúan en la intersección de la confianza, los privilegios y la distribución. Si los atacantes pueden controlar el pipeline, pueden controlar lo que llega a producción—y lo que llega a los usuarios.
Este artículo explica por qué los pipelines se convirtieron en una superficie de ataque principal, qué nos enseñan los incidentes recientes de supply chain, cómo la seguridad de pipelines difiere de la seguridad en tiempo de ejecución, y qué errores de diseño comunes mantienen vulnerables a los pipelines. La conclusión es clara: el pipeline es un límite de confianza, y debe ser diseñado como tal.
La evolución de los ataques al software
Las amenazas clásicas a la seguridad de aplicaciones se dirigían a vulnerabilidades en tiempo de ejecución: SQL injection, RCE, SSRF, auth bypass y escalada de privilegios. Los defensores han dedicado dos décadas a aumentar el coste de estos ataques mediante:
- Mejoras en el parcheo, el escaneo de dependencias y la gestión de vulnerabilidades
- Controles de seguridad cloud-native e infraestructura gestionada
- Mejor aislamiento (contenedores, sandboxes, segmentación)
- Capacidades centralizadas de logging y detección
Como resultado, los adversarios se adaptaron. Si la producción se vuelve más difícil de explotar directamente, los atacantes buscan ventaja en otro lugar—y el proceso de entrega de software ofrece esa ventaja.
En lugar de preguntar “¿Cómo puedo entrar en este sistema en ejecución?”, los atacantes preguntan cada vez más:
¿Cómo puedo hacer que mi código se distribuya como si fuera legítimo?
Cuando eso sucede, las defensas diseñadas para compromisos en tiempo de ejecución pueden volverse irrelevantes. Una actualización maliciosa entregada a través de canales legítimos no es una “brecha” en el sentido tradicional— puede parecer una operación normal del negocio.
Tres incidentes que ilustran el cambio
Los incidentes de supply chain de alto perfil no ocurrieron porque las defensas en tiempo de ejecución fueran débiles. Ocurrieron porque los atacantes comprometieron mecanismos de entrega que se sitúan aguas arriba de producción. Los detalles difieren, pero el patrón es consistente: comprometer un paso de construcción o distribución confiable, y heredas la confianza a escala.
SolarWinds: comprometer el build y alcanzar a todos
En el incidente de SolarWinds, los atacantes lograron inyectar código malicioso en las actualizaciones de software. La característica definitoria no fue un único servidor explotado—fue la capacidad de distribuir software con backdoor a través de un canal de actualización confiable.
El ROI del atacante fue masivo: comprometer el pipeline de build o release una vez, y luego dejar que los clientes instalen tu payload por ti.
Codecov: comprometer las herramientas de CI y robar secretos a escala
En el incidente de Codecov, un compromiso afectó la forma en que los entornos de CI manejaban un script. El impacto práctico: los sistemas CI que se ejecutaban en muchas organizaciones filtraron información sensible.
Los entornos de CI son extremadamente sensibles porque comúnmente contienen:
- Tokens de repositorios
- Credenciales de la nube
- Claves de firma o acceso a servicios de firma
- Secretos de despliegue
Este incidente destaca que las herramientas de CI no son “solo automatización”—son un sistema de procesamiento de secretos de alto valor.
3CX: comprometer un proveedor y convertir la confianza en arma
El incidente de 3CX demostró otra dinámica de supply chain: comprometer un proveedor y convertir la confianza en arma para distribuir software malicioso a los clientes downstream.
Desde el punto de vista de la defensa, la lección no se limita a los proveedores. Internamente, tu pipeline CI/CD es efectivamente un “proveedor” para tu entorno de producción y para tus usuarios: producción confía en las salidas del pipeline.
Por qué el pipeline es más atractivo que producción
Los atacantes eligen objetivos basados en el apalancamiento. Los pipelines CI/CD ofrecen un apalancamiento que los sistemas de producción rara vez igualan.
1) Los pipelines agregan confianza
Un pipeline es el tejido conectivo entre:
- Repositorios de código fuente (Git)
- Registros de dependencias (npm, PyPI, Maven, etc.)
- Sistemas de build y runners
- Repositorios de artefactos (registros de contenedores, repos de paquetes)
- Sistemas de firma y metadatos de provenance
- Objetivos de despliegue (Kubernetes, cuentas cloud, servidores de producción)
Comprometer producción generalmente te da acceso a un entorno. Comprometer el pipeline puede darte:
- Acceso a múltiples entornos a través de credenciales de automatización
- Control sobre los artefactos de release
- Influencia sobre lo que se despliega y cuándo
Los pipelines son “multiplicadores de confianza”: pueden tomar entradas no confiables y producir salidas confiables. Si los atacantes controlan esa transformación, controlan la confianza.
2) Los pipelines operan con altos privilegios por diseño
La automatización necesita privilegios. Los pipelines a menudo requieren permisos para:
- Leer y escribir en repositorios (incluyendo tags y releases)
- Descargar dependencias y publicar artefactos
- Acceder a secretos para firma o despliegue
- Desplegar en staging o producción
En muchas organizaciones, las identidades de los pipelines se convierten en “superidentidades” con el tiempo, porque es más fácil otorgar acceso amplio que diseñar permisos granulares.
Esto crea una estrategia predecible para los atacantes: comprometer la identidad del pipeline en lugar de luchar contra las defensas de producción.
3) El compromiso de pipelines escala mejor
El compromiso en tiempo de ejecución a menudo escala mal: debes explotar objetivos repetidamente, manejar la variabilidad entre entornos y mantener la persistencia por objetivo.
El compromiso de pipelines escala eficientemente: inyectar una vez, distribuir a todas partes. Si puedes modificar un paso de build, una ruta de resolución de dependencias o un artefacto de release, puedes comprometer muchos sistemas mientras pareces legítimo.
4) La detección es más difícil porque “todo parece normal”
Las herramientas de seguridad de producción buscan comportamiento sospechoso en tiempo de ejecución: llamadas de red inesperadas, escaladas de privilegios, procesos anormales. Pero si el código malicioso se distribuye como un release normal, se ejecuta como parte del comportamiento esperado de la aplicación.
Sin controles de integridad sólidos y provenance, los defensores pueden tener dificultades para responder:
¿Este binario/contenedor es realmente lo que pretendíamos construir?
Seguridad de pipelines vs seguridad en tiempo de ejecución
Un error común es pensar que la seguridad de pipelines es simplemente “seguridad en tiempo de ejecución aplicada más temprano en el ciclo de vida.” Ese enfoque es incompleto. La seguridad de pipelines y la seguridad en tiempo de ejecución protegen garantías diferentes.
La seguridad en tiempo de ejecución responde:
¿Qué está haciendo este sistema ahora mismo, y es malicioso?
La seguridad de pipelines responde:
¿Por qué deberíamos confiar en este software en primer lugar?
Si el pipeline está comprometido, las defensas en tiempo de ejecución podrían proteger fielmente una aplicación maliciosa, porque desde la perspectiva del sistema es “la aplicación.” El verdadero fallo ocurrió aguas arriba, en el punto donde se estableció la confianza.
Es por esto que la seguridad de supply chain se centra en:
- Integridad de las salidas del build
- Provenance (quién/qué lo construyó, dónde y cómo)
- Puertas de verificación antes del despliegue
- Reducir la capacidad de manipular los pasos de build y release
Dónde son realmente vulnerables los pipelines
Para asegurar los pipelines, debemos ser específicos sobre dónde ocurren los ataques. “CI/CD” no es un solo componente. Es una cadena de componentes y transiciones de confianza. Estos son los puntos de ataque más comunes.
Código fuente: pull requests y contribuciones no confiables
Muchos pipelines ejecutan código de pull requests. Si el pipeline trata el código del PR como confiable (o filtra secretos a los builds de PR), los atacantes pueden exfiltrar credenciales o modificar las salidas del build.
Dependencias: confianza transitiva a escala de internet
Los builds modernos descargan cientos o miles de dependencias de terceros. Una dependencia comprometida, un paquete de typosquatting o dependency confusion pueden desviar la ejecución dentro del entorno de build—a menudo sin tocar tu código fuente.
Configuración del pipeline: “código” que a menudo se revisa menos
Las definiciones de CI (workflows YAML, templates compartidos, acciones reutilizables) controlan la ejecución. Un cambio sutil puede:
- Expandir permisos
- Introducir exfiltración de datos
- Cambiar las fuentes de artefactos
- Desactivar verificaciones de seguridad
Sin embargo, la configuración de CI a veces recibe una revisión menos rigurosa que el código de la aplicación.
Runners: el entorno de ejecución es un límite de seguridad
Los runners alojados, los runners self-hosted y los contenedores efímeros tienen todos perfiles de riesgo diferentes. Pero el punto clave es universal: los runners ejecutan entradas no confiables. Si los runners no están aislados adecuadamente, se convierten en un punto de apoyo para el atacante.
Artefactos: la integridad y el provenance a menudo se asumen, no se demuestran
Muchas organizaciones asumen que “si vino de CI, es seguro.” Esa es precisamente la suposición que explotan los atacantes. Sin firmas, attestations y puertas de verificación, la integridad de los artefactos es frágil.
Errores comunes en el diseño de pipelines
La mayoría de los compromisos de pipelines tienen éxito debido a errores de ingeniería predecibles—generalmente impulsados por la velocidad, la conveniencia o la falta de claridad en la propiedad. Estos errores crean violaciones de confianza silenciosas.
Error #1: Tratar los runners de CI como “internos y confiables”
Los runners a menudo se ejecutan dentro de redes confiables y tienen acceso a recursos sensibles. Pero ejecutan código que puede estar influenciado por contribuidores externos, dependencias o acciones de terceros. Si el runner está comprometido, el atacante puede:
- Robar secretos de las variables de entorno
- Extraer tokens de la configuración local
- Modificar las salidas del build
- Persistir a través de cachés, imágenes o volúmenes compartidos
Error #2: Identidades de pipeline con exceso de privilegios
Los tokens amplios (por ejemplo, tokens de repositorio “write-all”, credenciales cloud multi-entorno) son comunes. Facilitan la automatización—pero también dan a los atacantes un camino rápido hacia el impacto.
Error #3: Límites débiles entre las etapas del pipeline
Si una etapa temprana puede influir en los artefactos utilizados por etapas posteriores sin verificación de integridad, el envenenamiento de artefactos se vuelve trivial. Esto incluye:
- Cachés de build no verificadas
- Espacios de trabajo compartidos entre jobs
- Artefactos pasados entre etapas sin verificaciones
Error #4: Componentes de terceros sin control
Las acciones reutilizables, plugins y templates son poderosos. Pero también añaden riesgo de supply chain dentro del propio CI. Si los componentes de terceros no están fijados, revisados y restringidos, se convierten en un vector de ejecución.
Error #5: “Verificaciones de seguridad” que no bloquean el despliegue
El escaneo de seguridad que no bloquea los releases a menudo se trata como “suficiente.” Desde la perspectiva del atacante, es irrelevante. Los controles deben ser aplicables: deben afectar lo que se puede construir, firmar y desplegar.
El pipeline es un límite de confianza
El modelo mental correcto no es “CI/CD como automatización.” Es CI/CD como un límite de confianza.
Un límite de confianza es donde las entradas no confiables se convierten en salidas confiables. Eso es exactamente lo que hace un pipeline:
- Toma código fuente (potencialmente influenciado por muchos actores)
- Resuelve dependencias (a menudo de ecosistemas externos)
- Ejecuta instrucciones de build
- Produce artefactos en los que producción confiará
Si no haces la confianza explícita, obtienes confianza implícita. La confianza implícita es lo que los atacantes monetizan.
Diseñar el pipeline como un límite de confianza significa:
- Límites de etapa explícitos con aislamiento y verificación entre ellos
- Privilegio mínimo para las identidades del pipeline, por job y por entorno
- Ejecución efímera (o aislamiento fuerte) para runners y builds
- Integridad criptográfica para artefactos (firma y verificación)
- Provenance y attestations que puedan ser validadas en el momento del despliegue
Qué debe incluir una estrategia de seguridad moderna
Si los pipelines son superficies de ataque principales, los programas de seguridad deben invertir en consecuencia. No añadiendo más “verificaciones,” sino construyendo garantías sólidas en el proceso de entrega.
1) Modelar las amenazas del pipeline (no solo de la aplicación)
Mapear los límites de confianza: entradas de PR, resolución de dependencias, runners, almacenamiento de artefactos, firma y despliegue. Identificar dónde puede entrar influencia no confiable.
2) Reducir privilegios y alcance de forma agresiva
Usar identidades con alcance por job, credenciales con alcance por entorno, tokens de corta duración y límites de permisos explícitos. Evitar los “superusuarios de pipeline.”
3) Fortalecer los runners y los entornos de ejecución
Preferir runners efímeros cuando sea posible. Si se usan runners self-hosted, aislarlos: restricciones de red, controles de sistema de archivos, sin estado compartido de larga duración, y segregación estricta entre cargas de trabajo confiables y no confiables.
4) Hacer que la integridad sea verificable, no asumida
Firmar artefactos, generar attestations y verificarlos antes del despliegue. Asegurar que producción confíe en la verificación, no simplemente en el hecho de que “CI lo produjo.”
5) Validar los cambios de pipeline como cambios de producción
Tratar la configuración de CI como código de alto riesgo. Usar code owners, revisiones y aplicación de políticas para prevenir la expansión silenciosa de privilegios o la inyección de pasos no confiables.
Conclusión
Los pipelines CI/CD se han convertido silenciosamente en algunos de los componentes más críticos—y más explotados—de los ecosistemas de software modernos. Agregan confianza, operan con altos privilegios y proporcionan a los atacantes un camino de alto apalancamiento para lograr impacto a escala.
El paso más importante es cambiar el modelo mental:
Un pipeline CI/CD no es “solo automatización.” Es un límite de confianza.
Las organizaciones que diseñen pipelines con límites de confianza explícitos—a través de aislamiento, privilegio mínimo, integridad y provenance—estarán en una posición mucho mejor para defenderse contra la próxima generación de ataques a la software supply chain.
