Compromiso de Trivy en GitHub Actions: 75 etiquetas secuestradas para robar secretos de CI/CD

Resumen del incidente

Trivy, el popular escáner de vulnerabilidades de código abierto mantenido por Aqua Security, fue comprometido por segunda vez en el plazo de un mes para distribuir malware diseñado para robar secretos de pipelines de CI/CD. El incidente afectó a las acciones de GitHub «aquasecurity/trivy-action» y «aquasecurity/setup-trivy», utilizadas para escanear imágenes Docker en busca de vulnerabilidades y para preparar Trivy en flujos de trabajo de GitHub Actions. Según los informes iniciales, el atacante logró secuestrar 75 etiquetas (tags) de las acciones para propagar el código malicioso.

Antecedentes y contexto: por qué importa

Las acciones de GitHub (GitHub Actions) se han consolidado como una pieza central de los pipelines de CI/CD para millones de desarrolladores y organizaciones. Permiten automatizar pruebas, compilaciones y despliegues con componentes reutilizables mantenidos por terceros. Esa misma conveniencia es la que convierte a las acciones en un vector atractivo para atacantes interesados en la cadena de suministro del software.

• Trivy es ampliamente usado para detectar vulnerabilidades en imágenes de contenedores y en artefactos de desarrollo; su compromiso significa que herramientas de seguridad pueden convertirse en un punto de entrada para el robo de credenciales.
• El hecho de que sea el segundo compromiso en un mes indica un problema persistente en la seguridad del canal de distribución y en los mecanismos de integridad de componentes reutilizables.
• Los ataques a la cadena de suministro del software han escalado en visibilidad desde incidentes ampliamente conocidos como SolarWinds y Codecov, que demostraron el alcance y el impacto potencial de comprometer componentes de confianza.

Análisis técnico y comentarios para profesionales

Los detalles publicados hasta ahora indican que el atacante modificó versiones/tags de las GitHub Actions de Aqua Security para incluir código con funcionalidad de exfiltración de secretos. Aunque las investigaciones completas requieren acceso a artefactos forenses y a los registros de GitHub/Aqua, estos vectores suelen seguir patrones conocidos:

• Compromiso de cuentas con privilegios (p. ej., cuentas de mantenimiento del repositorio) o explotación de la cadena de publicación de releases para introducir artefacto malicioso en versiones oficiales.
• Uso de versiones etiquetadas (tags) que más tarde se propagan a flujos de trabajo existentes en repositorios de terceros; como muchas acciones no están fijadas a un SHA específico, una vez que una etiqueta se vuelve maliciosa, los consumidores que usan esa etiqueta reciben la versión comprometida.
• El objetivo primario suele ser exfiltrar tokens y secretos disponibles en el entorno de ejecución de GitHub Actions (por ejemplo, secrets de repositorio, variables de entorno con credenciales, tokens de acceso a servicios externos), aprovechando los permisos otorgados por la configuración del workflow.

Para los operadores de CI/CD: asumir que una acción externa puede ser comprometida y aplicar controles compensatorios redunda en menor riesgo operativo.

Riesgos e implicaciones para equipos DevOps y seguridad

El robo de secretos de CI/CD puede permitir a un atacante moverse lateralmente dentro de la infraestructura de una organización, desplegar código malicioso, manipular imágenes contenedorizadas, o acceder a entornos de producción. Las implicaciones concretas incluyen:

• Acceso no autorizado a repositorios y a secretos asociados (tokens de despliegue, credenciales de registries, claves de API).
• Distribución de imágenes o artefactos comprometidos a entornos de producción a través de pipelines automatizados.
• Riesgo reputacional y necesidad de respuesta coordinada (rotación de credenciales, auditoría de logs, notificación a clientes/usuarios si procede).

Además, la recurrencia del compromiso demuestra que las mitigaciones reactivas pueden no ser suficientes: es necesario fortalecer tanto la protección de los procesos de publicación de las acciones como los controles en los repositorios que las consumen.

Recomendaciones prácticas y acciones inmediatas

Las siguientes medidas están orientadas a reducir la superficie de ataque y a contener el impacto si ya se han filtrado secretos:

• Auditar dependencias de GitHub Actions: identificar dónde se usan «aquasecurity/trivy-action» y «aquasecurity/setup-trivy» en su organización y bloquear o reemplazar temporalmente esas integraciones.
• Pinear acciones a commits SHA específicos: evitar usar etiquetas flotantes o versiones mayores indefinidas; usar referencias inmutables reduce la probabilidad de ejecutar código modificado en una etiqueta comprometida.
• Minimizar permisos de workflows: aplicar el principio de menor privilegio en la sección permissions del workflow de GitHub Actions y limitar el acceso a secrets solo a los jobs que lo necesiten.
• Rotar credenciales y secretos expuestos: si existe la menor sospecha de que un workflow comprometido pudo leer secrets, proceder a su rotación inmediata y a invalidar tokens comprometidos.
• Adoptar OIDC y credenciales efímeras: cuando sea posible, usar OpenID Connect (OIDC) para emitir tokens de acceso temporal a servicios en nube en lugar de incrustar secretos de larga duración.
• Habilitar revisión humana/entornos protegidos: exigir aprobaciones para ejecuciones en ramas protegidas o para el uso de secretos en entornos con riesgos elevados.
• Monitoreo y detección: añadir controles para detectar salidas de red inusuales desde runners, y habilitar alertas en logs de acciones y accesos a repositorio.
• Considerar soluciones de hardening de la cadena de suministro: usar firmas de acciones, verificar sumas de integridad y seguir marcos como SLSA para elevar el nivel de garantía.

Casos comparables y lecciones aprendidas

Este incidente encaja en una tendencia mayor de ataques a la cadena de suministro del software. Casos previos de alto impacto han demostrado varios vectores y consecuencias:

• SolarWinds (2020): compromisos en el proceso de construcción de software que permitieron la distribución de un backdoor a clientes.
• Codecov (2021): modificación de un script de upload en una imagen de soporte que expuso tokens y datos, afectando a clientes que usaban sus servicios en CI.
• Typosquatting y paquetes maliciosos en ecosistemas de paquetes: mantienen la presión sobre mantenedores y consumidores para validar dependencias.

La lección recurrente es que la confianza en componentes externos debe estar acompañada de defensas multicapa: controles preventivos en la publicación de artefactos, y controles de limitación y detección en los consumidores.

Conclusión

El segundo compromiso en un mes de componentes de Trivy para GitHub Actions —con 75 etiquetas secuestradas para propagar malware que roba secretos de CI/CD— subraya la fragilidad de la confianza en la cadena de suministro del software. Para reducir el riesgo es necesario combinar prácticas de higiene (fijar versiones, rotar secretos, permisos mínimos) con arquitecturas que favorezcan credenciales efímeras y controles de integridad. Las organizaciones que dependen de acciones mantenidas por terceros deberían asumir que cualquiera de esos componentes puede fallar y diseñar sus pipelines en consecuencia: detección temprana, respuesta rápida y limitación del alcance son imprescindibles.

Source: thehackernews.com