Qué ha pasado exactamente
El gusano Miasma se introdujo a través de un commit malicioso en el repositorio Azure/durabletask, un componente core del framework de orquestación de flujos de trabajo en Azure. El atacante utilizó una cuenta con acceso legítimo al repositorio —aún se investiga si mediante compromiso de credenciales o ingeniería social— para inyectar el payload inicial.
Desde ese punto de entrada, el gusano se propagó lateralmente a otros 72 repositorios bajo las organizaciones Azure, Azure-Samples, Microsoft y MicrosoftDocs. GitHub deshabilitó en bloque los 73 repositorios comprometidos tras detectar la actividad anómala, lo que contuvo la propagación pero evidenció la velocidad de movimiento lateral dentro de un ecosistema de repositorios interconectados.
El vector de propagación más probable: referencias de código y dependencias cruzadas entre repositorios, combinadas con flujos de automatización que ejecutan código de los repositorios comprometidos sin verificación de integridad previa.
Por qué las pipelines CI/CD son el nuevo perímetro
Durante años hemos tratado las pipelines de integración y entrega continua como entornos de confianza implícita dentro del modelo de seguridad de las organizaciones. Si un desarrollador tiene acceso al repositorio y el código pasa los tests automáticos, se asume que es legítimo. Miasma demuestra que esa lógica es incompleta.
Una pipeline CI/CD que ejecuta código sin verificación de procedencia es, a efectos prácticos, un vector de ejecución de código arbitrario con privilegios elevados dentro de la infraestructura del cliente. En entornos cloud-native esto incluye acceso a secrets, tokens de servicio, configuraciones de infraestructura y, en muchos casos, acceso directo a sistemas de producción a través del flujo de deployment.
GitHub Actions, Azure DevOps Pipelines y sus equivalentes en otras plataformas deben tratarse con el mismo rigor de segmentación y control que cualquier otro componente crítico de la infraestructura. No son "herramientas de desarrollador" — son superficie de ataque con acceso privilegiado.
Los controles que habrían reducido el impacto
No existe un control que garantice inmunidad absoluta frente a un compromiso de cuenta con acceso legítimo. Pero una arquitectura de seguridad de cadena de suministro bien diseñada habría limitado significativamente el radio de impacto:
Firmado de commits y verificación de procedencia. El firmado obligatorio de commits con GPG o SSH, combinado con políticas de protección de ramas que rechacen commits sin firma verificada, eleva enormemente el coste de inyección para el atacante. Sigstore y la especificación SLSA (Supply-chain Levels for Software Artifacts) ofrecen un framework completo para la verificación de procedencia de artefactos.
Principio de mínimo privilegio en tokens de CI/CD. Los tokens de acceso utilizados por las pipelines deben tener el alcance mínimo necesario para ejecutar la tarea concreta. Un token de build no necesita acceso de escritura a otros repositorios. Un token de deployment no necesita acceso al código fuente. La separación de privilegios limita el movimiento lateral.
Escaneo de dependencias en tiempo real. Herramientas como Dependabot, GitHub Advanced Security o equivalentes comerciales monitorizan las referencias cruzadas entre repositorios y detectan modificaciones anómalas en dependencias. La detección temprana en el repositorio origen habría acotado la propagación.
Revisión obligatoria de cambios en workflows. Los ficheros .github/workflows/ y equivalentes deben estar protegidos por reglas de protección de ramas estrictas que requieran revisión de un segundo revisor con acceso explícito, independientemente del nivel del committer. Un workflow modificado maliciosamente sin revisión es el vector más directo de compromiso de pipeline.
Mi perspectiva sobre proyectos de Zero Trust
En los proyectos de Zero Trust, el repositorio de código y las pipelines CI/CD han pasado a ser parte explícita del modelo de amenazas desde hace dos años. No es una práctica que todos nuestros clientes tenían incorporada, y la resistencia inicial es comprensible: los equipos de desarrollo no quieren ver sus herramientas tratadas como vectores de ataque potencial.
El argumento que más ha funcionado para superar esa resistencia es simple: un entorno de producción en Azure puede estar perfectamente segmentado, con todas las identidades bajo PIM, acceso condicional por señal de riesgo y logs completos en Sentinel — y ser comprometido en horas si la pipeline que hace el deployment tiene acceso al Key Vault con un token sin expiración almacenado en texto plano en el repositorio.
Miasma no es una anomalía. Es la materialización de un riesgo que llevamos tiempo señalando. El sector financiero y asegurador, que opera sobre stacks Azure con GitHub Enterprise o Azure DevOps, debería revisar sus controles de supply chain esta semana.