El threat modeling es una práctica bien establecida en la seguridad de aplicaciones. Los equipos modelan amenazas de forma rutinaria contra APIs, servicios backend y entornos de producción.
Sin embargo, los pipelines de CI/CD a menudo se excluyen de los ejercicios formales de threat modeling, a pesar de ser uno de los componentes más críticos de los sistemas de software modernos.
Esta es una brecha peligrosa.
Los pipelines de CI/CD se encuentran en la intersección de entradas no confiables, privilegios elevados y salidas confiables. Son precisamente el tipo de sistema donde el threat modeling proporciona el mayor valor, y sin embargo, con frecuencia se tratan como «simple automatización».
Este artículo explica cómo realizar threat modeling de pipelines de CI/CD de manera efectiva, con un enfoque en la identificación de trust boundaries, la comprensión de attack paths y la priorización de controles que realmente reducen el riesgo.
Por qué el threat modeling de pipelines de CI/CD es diferente
Los enfoques tradicionales de threat modeling a menudo asumen un límite de sistema relativamente estable: una aplicación ejecutándose en producción, con usuarios, flujos de datos y activos definidos.
Los pipelines de CI/CD rompen muchas de estas suposiciones.
Un pipeline no es un sistema único. Es una cadena dinámica de sistemas que:
- Consume entradas de múltiples fuentes
- Ejecuta código no confiable
- Opera con privilegios elevados
- Produce artefactos en los que los sistemas posteriores confían implícitamente
En otras palabras, los pipelines no son solo parte del proceso de entrega — son un mecanismo de transformación de confianza.
El threat modeling de pipelines de CI/CD, por lo tanto, requiere un cambio de mentalidad:
El objetivo no es solo prevenir compromisos, sino comprender dónde se crea, amplifica o viola la confianza.
Lo que realmente estamos protegiendo
Antes de identificar amenazas, es esencial clarificar qué activos es responsable de proteger un pipeline de CI/CD.
Los activos comunes del pipeline incluyen:
- Integridad del código fuente — asegurar que el código no sea modificado inesperadamente
- Integridad del build — asegurar que los builds se ejecuten según lo previsto
- Integridad de los artefactos — asegurar que las salidas coincidan con las entradas
- Secrets y credenciales — tokens, claves e identidades utilizadas por la automatización
- Autenticidad de los releases — asegurar que los releases sean legítimos y atribuibles
Un ataque exitoso a un pipeline no siempre implica robar datos o colapsar sistemas. A menudo, el objetivo del atacante es mucho más sutil:
Introducir comportamiento malicioso preservando la apariencia de legitimidad.
Comprender los trust boundaries en CI/CD
Un trust boundary existe cuando datos o control cruzan de un contexto menos confiable a uno más confiable.
En los pipelines de CI/CD, los trust boundaries están en todas partes, pero rara vez son explícitos.
El threat modeling comienza identificando estos límites y haciendo una pregunta simple:
¿Qué suposiciones estamos haciendo sobre la confianza en este punto?
1. Entradas de código fuente
Los pipelines consumen código fuente de repositorios, ramas, tags y pull requests. No todas estas entradas tienen el mismo nivel de confianza.
- Las ramas principales pueden estar restringidas y revisadas
- Las ramas de features pueden estar controladas de forma laxa
- Los pull requests pueden incluir contribuciones no confiables
Sin embargo, muchos pipelines tratan todas las entradas de código como igualmente confiables.
Esto crea una superficie de ataque donde código no confiable puede influir en procesos de build y deployment confiables.
2. Resolución de dependencias
Los builds modernos resuelven dependencias dinámicamente desde ecosistemas externos: registros de paquetes, registros de contenedores y repositorios de artefactos.
Cada paso de resolución de dependencias cruza un trust boundary:
- Del control interno a la infraestructura externa
- De entradas verificadas a código de terceros
El threat modeling debe considerar:
- Dependency confusion
- Typosquatting
- Paquetes upstream comprometidos
Ignorar las dependencias en el threat modeling deja un attack path importante sin explorar.
3. Runners de CI/CD y entornos de ejecución
Los runners son donde la lógica del pipeline realmente se ejecuta. Son uno de los trust boundaries más críticos — y más incomprendidos.
Los runners ejecutan:
- Código fuente
- Scripts de build
- Acciones o plugins de terceros
Si los runners se tratan como infraestructura confiable, pero ejecutan entradas no confiables, el trust boundary colapsa.
El threat modeling debe considerar explícitamente:
- Aislamiento de runners
- Persistencia entre jobs
- Acceso a red y sistema de archivos
- Acceso a secrets
4. Configuración y orquestación del pipeline
Los archivos de configuración de CI/CD definen qué se ejecuta, cuándo se ejecuta y con qué permisos.
Son efectivamente planos de control para el proceso de entrega.
Cualquier cambio en la configuración del pipeline puede:
- Alterar el flujo de ejecución
- Expandir privilegios
- Introducir nuevos attack paths
El threat modeling debe tratar los cambios de configuración con el mismo rigor que los cambios de código de producción.
5. Artefactos y traspaso al deployment
El trust boundary final es el traspaso del pipeline a producción.
En este punto, los entornos de producción a menudo asumen:
Si vino del CI/CD, es seguro.
Esta suposición es precisamente lo que los atacantes explotan.
Sin verificación de integridad y comprobaciones de procedencia, producción no puede distinguir artefactos legítimos de los envenenados.
Identificación de attack paths comunes en CI/CD
Una vez identificados los trust boundaries, el siguiente paso es mapear attack paths realistas.
El objetivo no es enumerar cada amenaza teórica, sino comprender cómo los atacantes se mueven a través del sistema.
Attack path 1: Pull request a exfiltración de secrets
Un attack path común involucra:
- Un atacante envía un pull request
- El pipeline ejecuta el código del PR
- Los secrets se exponen al entorno de build
- El atacante exfiltra credenciales
Este ataque no requiere explotar una vulnerabilidad — explota una suposición implícita de confianza.
Attack path 2: Compromiso de dependencia a envenenamiento de build
Otro path común:
- Una dependencia se compromete upstream
- El pipeline resuelve la dependencia
- Código malicioso se ejecuta durante el build
- Los artefactos se modifican antes de la publicación
Sin comprobaciones de integridad o procedencia, el artefacto envenenado puede parecer completamente legítimo.
Attack path 3: Manipulación de la configuración del pipeline
Los archivos de configuración del pipeline a menudo reciben menos escrutinio que el código de la aplicación.
Un atacante que puede modificar la configuración puede:
- Añadir pasos de ejecución ocultos
- Expandir permisos silenciosamente
- Redirigir las salidas de artefactos
Este attack path es especialmente peligroso porque puede persistir a través de múltiples builds.
Attack path 4: Compromiso de runner y movimiento lateral
Si los runners son compartidos, persistentes o están mal aislados, un atacante puede:
- Persistir entre jobs
- Robar secrets de otros pipelines
- Modificar builds futuros
En algunos casos, el compromiso del runner proporciona acceso a redes internas o entornos cloud.
Mapeo visual de trust boundaries
El threat modeling efectivo se beneficia de representaciones visuales.
Para pipelines de CI/CD, los diagramas deben enfocarse en:
- Dónde entran las entradas no confiables
- Dónde aumentan los privilegios
- Dónde se producen y consumen los artefactos
Cada flecha en el diagrama representa una transición de confianza. Cada transición es candidata para la aplicación de controles.
La pregunta clave en cada límite es:
¿Qué garantías tenemos en este punto y cómo se aplican?
Priorización de controles basada en threat modeling
El threat modeling solo es valioso si informa la acción.
Para pipelines de CI/CD, los controles de mayor impacto generalmente incluyen:
1. Reducir la confianza implícita
Distinguir explícitamente entre entradas confiables y no confiables. No exponer secrets o acciones privilegiadas a contextos no confiables.
2. Aplicar el principio de mínimo privilegio
Las identidades del pipeline deben estar limitadas por job, por stage y por entorno. Evitar tokens de larga duración y amplio alcance.
3. Aislar los entornos de ejecución
Los runners deben ser efímeros o estar fuertemente aislados. Las cargas de trabajo no confiables nunca deben compartir contexto de ejecución con las confiables.
4. Verificar la integridad de los artefactos
Los artefactos deben estar firmados, atestados y verificados antes del deployment. Producción debe confiar en la verificación — no en suposiciones.
5. Tratar la configuración del pipeline como código de alto riesgo
Aplicar revisiones, políticas y validación a los cambios de configuración de CI/CD. Prevenir la expansión silenciosa de ejecución o privilegios.
Errores comunes en el threat modeling de CI/CD
Incluso cuando las organizaciones intentan realizar threat modeling de pipelines, a menudo caen en trampas predecibles.
- Enfocarse solo en herramientas, no en relaciones de confianza
- Asumir que «interno» significa «confiable»
- Ignorar componentes de terceros
- Modelar arquitecturas idealizadas en lugar de pipelines reales
El threat modeling efectivo debe reflejar cómo operan realmente los pipelines, no cómo deseamos que operen.
Conclusión
Los pipelines de CI/CD no son sistemas periféricos. Son centrales para la integridad, seguridad y confianza del software.
El threat modeling de pipelines revela attack paths que los modelos de amenazas de aplicaciones tradicionales no detectan, porque el objetivo del atacante no es explotar el comportamiento en tiempo de ejecución, sino controlar lo que se entrega en primer lugar.
Al identificar trust boundaries, mapear attack paths realistas y priorizar controles aplicables, las organizaciones pueden reducir significativamente el riesgo de ataques a la cadena de suministro de software.
El cambio más importante es conceptual:
Si no modelas explícitamente la confianza en tu pipeline, estás confiando en suposiciones — y los atacantes explotan las suposiciones.
