12 Pasos para Asegurar GitHub Actions Ahora
En marzo 2026, atacantes comprometieron Trivy, uno de los scanners de vulnerabilidades más usados del mundo, usando su GitHub Action como punto de entrada. Forzaron la reescritura de 75 de 76 tags de versiones a commits maliciosos y robaron credenciales AWS, GCP y SSH de todos los workflows que ejecutaban la acción comprometida. El incidente tuvo CVSS 9.4 y fue el paso final de una cadena de ataques que dura 16 meses (desde noviembre 2024). La realidad: tu cuenta cloud es el verdadero objetivo, y el código es solo el medio.
En 30 segundos
- El ataque Trivy de marzo 2026 robó credenciales cloud de 10,000+ workflows porque los atacantes querían acceso a AWS, no a código
- SHA pinning (anclar actions a hashes completos de 40 caracteres) hubiera detenido el ataque — es el paso 1 de 12 pasos de hardening
- OIDC (OpenID Connect) reemplaza credenciales de larga duración por tokens que expiran en 1 hora, reduciendo la ventana de exposición
- Principio de mínimos privilegios: limitar permisos de workflow a solo lo necesario (contents: read, id-token: write)
- Auditar qué actions usas en tu org y bloquear actions no aprobadas con GitHub Actions policies
El ataque Trivy: cuándo los scanners de seguridad se convierten en armas
Ponele que usás Trivy en tu workflow de CI/CD para escanear vulnerabilidades de imágenes Docker. Subís código, GitHub Actions dispara Trivy, ejecuta el análisis, y todo pasa sin problemas. El problema: entre noviembre 2024 y marzo 2026, una cadena de ataques coordinados fue comprometiendo action tras action, cada una más crítica que la anterior.
La cronología es inquietante: primero un Personal Access Token olvidado en SpotBugs (noviembre 2024), luego tj-actions/changed-files que apuntaba a Coinbase (marzo 2025, CVE-2025-30066), después el ataque Nx/s1ngularity augmentado con IA (agosto 2025), la campaña GhostAction que robó 3,325 secretos de 817 repositorios (septiembre 2025), y finalmente Trivy en marzo 2026. No fue aislado. Fue construcción.
Con Trivy, los atacantes fueron directo al punto: 75 de 76 version tags reescritos a commits maliciosos, forzaban a quien usaba la action a ejecutar código malicioso con los permisos del workflow. El payload no buscaba el código de tu aplicación (spoiler: nadie lo quería). Consultaba la AWS Instance Metadata Service en 169.254.169.254 y los endpoints de metadatos de ECS. Querían tus credenciales AWS.
Por qué tu cuenta AWS es el verdadero objetivo (no tu código)
Acá viene lo bueno: necesitás cambiar tu modelo mental sobre qué defienden los pipelines. No es el código. Es la infraestructura.
Un atacante con credenciales AWS robadas puede rotar tu infraestructura, exfiltrar datos de bases de datos, hacer mining de criptomonedas en tus instancias, lateralizarse a otros servicios en tu cuenta, o simplemente borrar todo. El código fuente de tu aplicación, honestamente, no vale nada. Tus acciones en GitHub valen oro porque son el acceso a los credentials que gobiernan tu nube. Sobre eso hablamos en ejecutar flujos de trabajo localmente.
Por eso cada ataque en los últimos 16 meses apuntó específicamente a credenciales cloud: buscaban AWS keys, service accounts de GCP, tokens de Azure. Si el flujo es: código en GitHub → credenciales en secretos de GitHub → credenciales ejecutadas en workflow → acceso a tu infra cloud, entonces el workflow es la puerta, y la puerta estaba abierta.
Paso 1: Anclar acciones a SHA completos (SHA pinning)
Esto es lo fundamental: cuando usás `uses: aquasecurity/[email protected]`, el tag `v0.35.0` es mutable. Un atacante puede mover ese tag a un commit malicioso, y tu workflow sigue usando la action “v0.35.0” que ahora apunta a código diferente.
SHA pinning lo resuelve: usás el hash SHA-256 completo de 40 caracteres en lugar del tag. Ejemplo:
uses: aquasecurity/trivy-action@5f16d4c6e88a1d7b3f9c2e1a4d6f8b2c9e3a5f7d # v0.35.0El comentario con el tag es legibilidad (nadie quiere leer hashes de memoria). Pero el hash es lo que GitHub ejecuta. Immutable. Dependabot entiende SHA pins y sigue actualizando el valor cuando hay nuevas versiones disponibles.
¿Esto hubiera detenido Trivy? Completamente. Un atacante no puede reescribir el hash SHA de un commit específico sin cambiar su contenido. Relacionado: proteger tu información en GitHub.
Pasos 2-4: Reemplazar credenciales largas con OIDC
GitHub secrets que almacenan AWS keys o service accounts de GCP son tokens de larga duración. Si se filtran, viven indefinidamente en poder de un atacante (hasta que los rotas manualmente, si es que lo notás).
OpenID Connect genera tokens OAuth 2.0 y JWT que expiran en 1 hora. Después se descartan. Si un atacante roba uno a mitad del workflow, tiene 60 minutos antes de que sea inútil.
Configuración con AWS: tu workflow asume un rol de IAM usando el token OIDC, obteniendo credenciales temporales. Configuración con Google Cloud: Workload Identity Federation vincula tu repositorio de GitHub directamente a GCP sin almacenar keys. El cambio es arquitectónico pero los beneficios son tangibles: ventana de exposición de 60 minutos en lugar de “indefinido”.
Pasos 5-7: Mínimos privilegios en workflows y jobs
Nunca uses `permissions: write-all` a nivel de workflow. Nunca.
Los permisos en GitHub Actions pueden limitarse por job: especificás `contents: read` para leer código, `id-token: write` solo en el job que necesita validar con OIDC, y `statuses: write` solo para actualizar commit status. Si un step es comprometido, su acceso está acotado a solo lo que ése necesita, no todo lo que el workflow podría hacer.
Mencioná que GitHub Actions policy ahora permite bloquear actions y forzar SHA pinning a nivel de organización, no individual. Eso es defensa en profundidad.
Pasos 8-10: Secretos seguros, rotación y detección
Tené en cuenta que cualquier usuario con acceso de escritura a tu repositorio ve todos los secrets. No los oculta el UI de GitHub — están disponibles en la API para quien tenga permisos. Por eso importa rotarlos regularmente: reducir la ventana de tiempo que alguien con acceso antiguo puede usarlos. Tema relacionado: herramientas seguras de IA y GPU.
Usar secrets context es obligatorio (no hardcodearlos en YAML). Monitoreá los logs de workflow en busca de filtraciones: si alguien hace un `echo ${{ secrets.AWS_ROLE }}`, va a los logs y está comprometido. GitHub Advanced Security detecta secrets filtrados en código y en logs automáticamente, e integra con Actions Data Stream para telemetría centralizada.
Pasos 11-12: Auditoría, revisión y políticas de organización
Auditar qué actions usas en tu org es más simple de lo que parece: GitHub proporciona un reporte de dependencias de actions. Revisá cada una y preguntate: ¿por qué la necesitamos? ¿Quién la autorizó? ¿Está pinneada a SHA?
Bloqueá actions no aprobadas con GitHub Actions policies a nivel org. Revieweá logs de ejecución regularmente (GitHub está introduciendo firewall Layer 7 para egress que inspecciona a dónde conectan tus workflows, útil para detectar data exfiltration). Y preferí `pull_request` sobre `pull_request_target`: el primero ejecuta en el contexto del PR, el segundo en el contexto del repo, mucho más riesgoso.
Tabla comparativa: métodos de autenticación en workflows
| Método | Duración del token | Rotación requerida | Complejidad setup | Recomendación |
|---|---|---|---|---|
| Secrets de AWS key/secret | Indefinida | Sí, manual frecuente | Baja | No — legacy, no usar para nuevos workflows |
| OIDC + assume-role | 1 hora | No, automática | Media | Sí — primera opción para AWS |
| GCP Service Account Key | Indefinida | Sí, manual | Baja | No — legacy |
| Workload Identity Federation | 1 hora | No, automática | Media-Alta | Sí — estándar para GCP |
| GitHub Token (GITHUB_TOKEN) | 1 hora | No, auto renovado | Nula | Sí — para permisos de repo, limitado por scope |
Errores comunes
1. Usar un único AWS key/secret para múltiples workflows
Centralizar credenciales en un único secret que tous los workflows comparten. Si se filtra, todo está comprometido. Mejor: una cuenta IAM por aplicación o por flujo crítico, con roles específicos.
2. Asumir que “la action está pinneada” porque está en un hash
No verificar realmente que el hash es válido. Los atacantes en ocasiones pueden generar collisions débiles o reescribir tags silenciosamente. Revisar manualmente de vez en cuando qué hash estás usando y compararlo con el repositorio oficial. Para más detalles técnicos, mirá alternativas de control de versiones.
3. Dar permisos `write` a todos los jobs cuando solo uno los necesita
Si tu workflow tiene 10 steps y solo 2 realmente necesitan escribir, pero los 10 tienen `write`, estás ampliando la superficie de ataque innecesariamente. Cada step adicional que podría estar comprometido tiene acceso a más de lo que debería.
Preguntas Frecuentes
¿Qué diferencia hay entre OIDC y almacenar secretos en GitHub?
OIDC genera tokens que expiran en 1 hora; los secrets son credenciales de larga duración que viven indefinidamente. OIDC requiere setup en tu proveedor cloud (AWS Identity Center, GCP Workload Identity), pero vale la pena porque reduce drasticamente la ventana de exposición si se filtra.
¿Cómo verifico si usé actions vulnerables en mi org?
GitHub proporciona un reporte bajo “Security → Dependabot” que lista todas las actions que usás y sus versiones. Revisá manualmente cada una y verificá que esté pinneada a SHA, no a tags.
¿SHA pinning realmente detiene ataques como Trivy?
Sí. El atacante puede reescribir tags, pero no puede cambiar el SHA de un commit específico sin modificar su contenido, lo que genera un SHA diferente. Si estás pinneado a un SHA, ejecutás exactamente ese código, punto.
¿Qué pasa si una action que pinneé a SHA tiene una vulnerabilidad?
Necesitás actualizar manualmente el SHA al hash de la versión nueva. Dependabot puede hacerlo automáticamente si está configurado para reconocer SHA pins (y lo hace por defecto desde 2024). Si la action tiene una vulnerabilidad crítica antes de que puedas actualizar, estás comprometido como con cualquier otro método — pero SHA pinning evita que alguien cambie el tag silenciosamente después de la publicación.
¿Esto aplica a mi hosting?
No directamente a tu hosting (que uses donweb.com o cualquier otro proveedor). Pero si tu CI/CD despliega a tu servidor desde GitHub Actions, proteger los workflows es proteger el canal por el que llega el código. Unas credenciales AWS comprometidas en un workflow pueden significar acceso total a tu infraestructura en la nube, aunque tu hosting sea tradicional.
Conclusión
El ataque Trivy no fue un incidente aislado, fue el eslabón final de una cadena de 16 meses de ataques coordinados a supply chains de GitHub Actions. La lección es clara: tu código no es el activo que los atacantes quieren. Quieren acceso a tu infraestructura cloud.
Los 12 pasos de hardening convergen en tres principios: inmutabilidad (SHA pinning), tokens corta duración (OIDC), mínimos privilegios (permisos acotados). Implementar estos tres realmente (no solo en teoría) reduce tu superficie de ataque de forma exponencial.
Si usás GitHub Actions en producción, el artículo completo de Haitham Ghazi detalla código copy-paste para cada paso. Es una lectura que vale dedicar 30 minutos: esos 30 minutos pueden ser la diferencia entre “estamos seguros” y “acaban de robar nuestras credenciales AWS”.
