El Escáner que Protege tu Código Ahora es el Atacante
Trivy es una de las herramientas más confiadas en el ecosistema de seguridad moderno. Desarrollado por Aqua Security, con más de 33,000 estrellas en GitHub, es el escáner de vulnerabilidades de referencia para equipos de DevSecOps en todo el mundo. Lo usan para detectar vulnerabilidades en containers, misconfigurations en Kubernetes, secrets expuestos, y riesgos de la cadena de suministro.
Desde el 19 de marzo de 2026, Trivy ha sido el atacante.
En lo que se ha convertido en uno de los ataques a la cadena de suministro más sofisticados del año, un actor malicioso comprometió las credenciales de un mantenedor de Aqua Security y publicó versiones maliciosas de Trivy, trivy-action, y setup-trivy — 75 tags de GitHub secuestrados en total. El payload: un infostealer diseñado para robar exactamente el tipo de credenciales que los equipos de DevSecOps tienen en su entorno.
Cronología: Dos Semanas de Compromiso Silencioso
El ataque no fue espontáneo. Fue metódico:
- 1 de marzo, 2026: Primera intrusión. Un atacante obtiene acceso a credenciales del repositorio de Trivy — probablemente mediante phishing o compra de credentials en mercados de infostealer. No se activa ninguna alarma pública inmediata.
- 1 - 19 de marzo: Período de observación. El atacante tiene acceso pero espera, mapeando el repositorio, entendiendo el proceso de release, identificando qué versiones y tags generan mayor volumen de descargas en pipelines de CI/CD.
- 19 de marzo, 2026: El atacante publica releases maliciosas:
trivy v0.69.4,trivy-action, ysetup-trivymodificados. 75 tags de GitHub son secuestrados para apuntar a las versiones comprometidas. Aqua Security detecta la actividad anómala y comienza la respuesta al incidente. - 19 - 22 de marzo: A pesar de la detección, el ataque continúa expandiéndose. Images maliciosas de Docker son pusheadas a registros públicos.
- 23 de marzo, 2026: Reporte completo del alcance: el payload se ha convertido en un worm que se propaga entre contenedores y un wiper que destruye cargas de trabajo en Kubernetes.
Cómo Funciona el Payload: Malicioso Antes de Ser Legítimo
El diseño del ataque es elegante en su perversidad. El payload no reemplaza Trivy — lo envuelve.
Las versiones comprometidas incluyen un script entrypoint.sh de 204 líneas que se ejecuta antes de lanzar el escaneo legítimo de Trivy. Para el usuario o el pipeline de CI/CD, todo parece normal: Trivy corre, genera un reporte de vulnerabilidades, el job de CI termina verde (o con los hallazgos esperados). Mientras tanto, el script malicioso ya terminó su trabajo.
El infostealer opera en tres fases documentadas por los investigadores de Socket:
- Recolección dirigida: El script extrae sistemáticamente secretos del entorno: variables de entorno con credenciales cloud (AWS_ACCESS_KEY_ID, AZURE_CLIENT_SECRET, GCP_SERVICE_ACCOUNT_KEY), tokens de CI/CD (GITHUB_TOKEN, GITLAB_TOKEN, CIRCLE_TOKEN), archivos de configuración de Kubernetes (
~/.kube/config), y cualquier secreto montado como volumen en el contenedor. - Cifrado robusto: Los datos recolectados son cifrados antes de la exfiltración, haciendo que el tráfico parezca legítimo y dificultando el análisis forense posterior.
- Exfiltración silenciosa: Los datos se envían a infraestructura controlada por el atacante. El tráfico de red se mezcla con el tráfico normal de Trivy hacia sus fuentes de datos de vulnerabilidades.
El resultado: cada pipeline de CI/CD que ejecutó Trivy entre el 19 y el 23 de marzo usando versiones afectadas entregó sus secretos al atacante sin generar ninguna señal de alerta obvia.
El Worm y el Wiper: Cuando el Robo Escala a Destrucción
Lo que comenzó como un infostealer evolucionó. Las últimas variantes detectadas incluyen dos capacidades adicionales que elevan la severidad del incidente:
Componente worm: Una vez ejecutado en un contenedor con acceso a la red de cluster de Kubernetes, el payload intenta propagarse lateralmente, identificando otros pods accesibles e intentando ejecutarse en ellos usando las credenciales ya robadas o vulnerabilidades de configuración comunes. Un solo job de CI comprometido puede convertirse en el punto de entrada a decenas de workloads.
Componente wiper de Kubernetes: En entornos donde el payload obtiene privilegios suficientes, activa una función de destrucción: elimina deployments, configmaps, secrets, y persistent volume claims de namespaces de Kubernetes. No es ransomware — no hay demanda de rescate. Es destrucción pura, posiblemente diseñada para cubrir las huellas de la exfiltración o como sabotaje deliberado.
La combinación es devastadora: el atacante roba tus credenciales, se propaga por tu cluster, y luego borra evidencia — y posiblemente cargas de trabajo de producción en el proceso.
Versiones Afectadas: Qué Debes Verificar Ahora
Si tu organización usa Trivy en pipelines de CI/CD o como imagen de Docker, estas son las versiones confirmadas como comprometidas:
aquasecurity/trivy:v0.69.4(Docker Hub y otros registros)aquasecurity/trivy-actionen múltiples versiones afectadas de GitHub Actionsaquasecurity/setup-trivyen versiones correspondientes- 75 tags adicionales del repositorio oficial — la lista completa está en la discusión oficial de Aqua Security en GitHub
Aqua Security publicó versiones limpias y está revocando las comprometidas, pero los pipelines que ya ejecutaron versiones afectadas deben asumir compromiso de credenciales.
Plan de Respuesta: 6 Pasos para Equipos DevSecOps
Si usas Trivy en tu organización, este es el orden de operaciones:
- Identifica exposición. Revisa tus pipelines de CI/CD: ¿qué versión de Trivy, trivy-action, o setup-trivy se ejecutó entre el 19 y el 23 de marzo? Busca en los logs de tus jobs las referencias a versiones específicas.
- Rota TODAS las credenciales de los entornos afectados. Si un pipeline ejecutó Trivy en ese período, asume que sus secrets fueron exfiltrados. Rota AWS keys, tokens de GitHub/GitLab, service accounts de GCP/Azure, y cualquier secret montado en esos containers. No es opcional.
- Audita accesos con las credenciales robadas. Una vez rotadas las credenciales, revisa los logs de acceso de las viejas keys en busca de uso no autorizado — APIs llamadas desde IPs inusuales, accesos a recursos fuera de lo normal, creación de nuevos usuarios o roles.
- Revisa el estado de tus clusters de Kubernetes. Si tienes el worm, puede haber pivotado a otros namespaces. Busca pods o deployments inusuales, cambios en configmaps o secrets que no correspondan a tu equipo, y pérdida inexplicable de recursos.
- Actualiza a una versión limpia. Aqua Security ha publicado versiones verificadas. Pínea la versión exacta en tus pipelines (no uses
latest) y verifica el digest SHA del image. - Implementa verificación de integridad de supply chain. Herramientas como Cosign (del proyecto Sigstore) permiten verificar firmas criptográficas de imágenes y releases antes de ejecutarlos. Si no lo tienes ahora, este es el momento de implementarlo.
La Lección que el Sector Sigue Ignorando
Los ataques a herramientas de seguridad no son nuevos. El incidente de SolarWinds en 2020 comprometió software de monitoreo de red. El ataque a XZ Utils en 2024 backdooreó una biblioteca de compresión presente en casi todas las distribuciones Linux. Ahora Trivy.
El patrón tiene una lógica perversa: si atacas el escáner de seguridad, atacas a todos los que confían en él para encontrar sus vulnerabilidades. Son por definición equipos que se preocupan por la seguridad — y por tanto, tienen credenciales de alto valor: acceso a repositorios de código, clusters de producción, servicios cloud. El ROI para el atacante es máximo.
La defensa requiere un cambio de mentalidad: las herramientas de seguridad no son inherentemente confiables. Necesitan el mismo nivel de escrutinio que cualquier otra dependencia de tu supply chain de software. Eso significa:
- Pinear versiones exactas con digest SHA verificado, no tags flotantes
- Verificar firmas criptográficas cuando estén disponibles (Sigstore/Cosign)
- Ejecutar herramientas de seguridad con los mínimos privilegios necesarios — Trivy no necesita acceso a
~/.kube/configpara escanear una imagen - Monitorear el comportamiento de red de tus pipelines de CI/CD — una exfiltración debería generar tráfico anómalo detectable
- Tratar los secrets en CI/CD como credenciales de alto valor con rotación periódica
La ironía de un escáner de vulnerabilidades comprometido para explotar vulnerabilidades no es solo poética — es una señal de hacia dónde se dirigen los atacantes sofisticados. Los perímetros corporativos son cada vez más difíciles de vulnerar directamente. La cadena de suministro de software es el camino de menor resistencia.
Si tu equipo usa Trivy, Grype, Snyk, o cualquier herramienta de seguridad en tu pipeline y quieres entender cuál es tu exposición real ante este tipo de ataques, podemos hacer ese análisis contigo en Sable. Y si este caso te genera preguntas sobre el patrón más amplio de supply chain attacks — de Telus a Crunchyroll, de Trivy a tus clusters — nuestra cobertura de Crunchyroll ilustra cómo estos ataques en cadena escalan más allá del objetivo inicial.