La cadena de suministro de software en jaque: imágenes de Trivy comprometidas y credenciales expuestas

La seguridad del desarrollo de software ha vuelto a ser el centro de atención tras una nueva oleada de ataques dirigida a la cadena de suministro: versiones troceadas del escáner de vulnerabilidades Trivy, distribuidas por Docker Hub, han servido como vector para filtrar credenciales y propagar malware más allá del entorno original. El alcance no se limita a una simple imagen comprometida: los efectos se han sentido en repositorios, acciones de GitHub y paquetes de ecosistemas de código abierto.

Según los investigadores que han analizado la campaña, las últimas versiones públicas confiables de Trivy en Docker Hub databan de la etiqueta 0.69.3; inmediatamente después aparecieron imágenes etiquetadas como 0.69.4, 0.69.5 y 0.69.6 que fueron detectadas como maliciosas y retiradas. Puedes revisar las etiquetas históricas en la página oficial del repositorio de imágenes aquasec/trivy en Docker Hub.

El patrón de ataque descrito por los analistas apunta a una escalada en cadena: un actor malicioso explotó credenciales comprometidas para subir versiones de Trivy con un ladrón de credenciales embebido, y además consiguió inyectar cambios en dos acciones de GitHub vinculadas al proyecto —las que facilitan la integración de Trivy en pipelines— lo que multiplicó la superficie de infección en entornos de CI/CD. El detalle técnico y los indicadores de compromiso han sido documentados por el equipo de Socket Security en este informe sobre las imágenes de Trivy comprometidas.

Esta intrusión no quedó aislada: con las credenciales exfiltradas los atacantes lograron comprometer paquetes en el registro npm y distribuir una amenaza autorreplicante conocida como CanisterWorm. Investigadores independientes que rastrean la campaña atribuyen las acciones a un actor apodado TeamPCP, que ya había mostrado interés por infraestructuras cloud y componentes nativos como APIs de Docker, clústeres de Kubernetes y servicios expuestos.

El impacto también alcanzó a la organización de Aqua Security. Según el rastreo forense publicado por el equipo OpenSourceMalware, 44 repositorios internos de la organización aquasec-com en GitHub fueron renombrados y expuestos públicamente en un intervalo de tiempo muy corto, lo que sugiere una explotación automatizada por medio de un token comprometido de una cuenta de servicio. El análisis técnico disponible en su blog explica cómo un token persistente (del servicio “Argon-DevOps-Mgt”) sirvió como llave para escribir en múltiples organizaciones, amplificando el daño en cadena: análisis del compromiso.

Los informes técnicos también han documentado la evolución de las capacidades del grupo atacante: además del robo de credenciales y la distribución de worms, se han identificado payloads diseñados para sabotear entornos. Investigadores de la firma Aikido describen un componente que, según las reglas incluidas en su script, despliega DaemonSets privilegiados en cada nodo de Kubernetes y, en sistemas con detecciones geográficas orientadas a Irán, ejecuta rutinas de borrado masivo y reinicio forzado. El artículo técnico de Aikido ahonda en cómo se comporta esa carga y en la separación de acciones según la localización del objetivo: análisis sobre el payload y su impacto en K8s.

Si hay una lección clara de este incidente, es que un único eslabón débil en la cadena de suministro (por ejemplo, una cuenta de servicio con un token de larga duración) puede tener consecuencias en cascada. Las credenciales persistentes y los permisos demasiado amplios son precisamente lo que los atacantes buscan explotar para moverse lateralmente y envenenar flujos de trabajo automatizados.

Para equipos que utilizan Trivy en sus pipelines, las recomendaciones inmediatas son evidentes: evitar las versiones afectadas, auditar ejecuciones recientes y asumir compromiso si se usaron esas imágenes o acciones en procesos críticos. El repositorio de Trivy en GitHub y sus mantenedores han publicado información oficial sobre la investigación y las versiones seguras, por lo que conviene contrastar con la fuente primaria: repositorio de Trivy en GitHub.

Más allá de reemplazar o bloquear imágenes, la respuesta debe incluir medidas de higiene de credenciales: revocar tokens y claves sospechosas, reducir el tiempo de vida de tokens de servicio, revisar permisos asignados a cuentas automatizadas y aplicar principios de menor privilegio en integraciones entre organizaciones. Asimismo, es aconsejable reforzar el control de acceso a APIs de Docker (por ejemplo, evitar exponer el puerto 2375 sin autenticación) y aplicar segmentación de red que impida que un servidor comprometido propague agentes a subredes locales.

En el plano organizacional conviene complementar estas acciones con detección y respuesta: revisar logs de CI/CD en busca de ejecuciones anómalas, comprobar la integridad de artefactos desplegados y usar firmas y verificación de procedencia para imágenes en producción. Las autoridades y equipos de seguridad pública han publicado guías para mitigar riesgos en la cadena de suministro del software; su consulta puede ayudar a formalizar políticas de control y respuesta a incidentes, por ejemplo en el repositorio de recursos de la CISA sobre gestión del riesgo en la cadena de suministro de software (CISA – Software Supply Chain Risk Management).

Es importante recordar que en ataques de este tipo no siempre hay una única víctima visible: la organización propietaria del proyecto afectado puede convertirse en plataforma involuntaria para comprometer a decenas o cientos de consumidores de su software. La confianza en componentes y acciones de terceros debe ser validada de forma continua, no asumida de por vida.

Mientras los equipos forenses y los responsables de las plataformas continúan corrigiendo vectores y publicando indicadores de compromiso, las empresas y desarrolladores deben tomar medidas inmediatas para contener el impacto y evitar que pequeñas fallas locales se conviertan en brechas masivas. La cadena de suministro del software es tan fuerte como el eslabón más débil: minimizar esos puntos débiles es ahora una prioridad ineludible.