CISA filtra credenciales de AWS GovCloud en GitHub durante 6 meses

La agencia estadounidense responsable de defender la infraestructura crítica de Estados Unidos contra ataques cibernéticos filtró sus propias credenciales en GitHub — y quedaron accesibles al público durante seis meses. El repositorio fue descubierto el 15 de mayo de 2026 por Guillaume Valadon, investigador de la firma GitGuardian, quien notificó a CISA. La historia llegó al conocimiento público a través de Krebs on Security días después, y generó una reacción inmediata del Congreso estadounidense.

Qué había en el repositorio

El repositorio público se llamaba “Private-CISA” — el nombre ya dice todo sobre el nivel de control aplicado. Lo mantenía un empleado de Nightwing, empresa contratista con sede en Dulles, Virginia. Estuvo accesible desde el 13 de noviembre de 2025 hasta que fue eliminado el 18 de mayo de 2026: 184 días de exposición.

En 844 megabytes de datos había:

• Credenciales de administrador de tres cuentas AWS GovCloud — las nubes gubernamentales que alojan sistemas sensibles de CISA
• Contraseñas en texto plano de decenas de sistemas internos, almacenadas en un archivo CSV
• Claves SSH y archivos de configuración de Kubernetes
• Workflows de GitHub Actions
• Una clave RSA privada con acceso a todos los repositorios de código de CISA-IT
• Documentación detallada de los procesos internos de build y deploy

Para poner esto en perspectiva: CISA coordina la defensa cibernética de toda la infraestructura crítica estadounidense — plantas de energía, sistemas de salud, redes electorales. Quien tuviera acceso a este repositorio tenía, potencialmente, acceso al pipeline que produce las herramientas que protegen esos sistemas.

El error técnico detrás de la filtración

No fue un exploit sofisticado ni un zero-day. El contratista desactivó manualmente la configuración predeterminada de GitHub que bloquea la publicación de secretos y claves en repositorios públicos — la función de secret scanning que cualquier cuenta tiene habilitada por defecto.

El resultado es lo que la comunidad de seguridad llama static secrets: credenciales almacenadas como texto plano en archivos versionados, en lugar de gestionadas por un vault dedicado. OWASP lista la mala gestión de secretos entre las fallas más comunes en desarrollo de software desde hace años. La diferencia acá es quién cometió el error y cuál era el objetivo.

La respuesta que llegó tarde

Después de recibir la notificación de GitGuardian el 15 de mayo, CISA retiró el repositorio tres días después. Pero revocar las credenciales no fue tan rápido:

• Algunas claves de AWS GovCloud siguieron funcionando durante 48 horas después de que se eliminara el repositorio
• La clave RSA privada quedó sin revocar durante al menos cinco días después de que CISA recibiera la primera notificación

Esto importa porque cualquier actor que hubiera clonado el repositorio antes de la eliminación seguiría teniendo acceso válido durante días. La exposición no termina cuando el repositorio se vuelve privado — termina cuando cada credencial individual se revoca y se reemplaza.

El Congreso pidió explicaciones

Legisladores de ambas cámaras del Congreso enviaron reclamos formales a la agencia. La cuestión central no es solo el error del contratista: es cómo una clave de administrador de AWS GovCloud terminó en un CSV dentro de un repositorio público sin que ningún sistema de detección disparara una alerta durante los 184 días anteriores.

CISA es la misma agencia que publica lineamientos de hardening para el resto del gobierno estadounidense. La pregunta obvia que hacen los legisladores es: si ni ustedes los siguen, ¿por qué debería hacerlo el resto?

Qué puede aprender cualquier equipo de esto

Este caso es didáctico porque el error es simple y el impacto es máximo. Algunas prácticas que habrían evitado la filtración:

1. Nunca almacenes credenciales en texto plano
Contraseñas en CSV, tokens en archivos .env commiteados, claves directamente en el código — todo eso debe ir a un secrets manager. AWS Secrets Manager, Azure Key Vault, HashiCorp Vault o Bitwarden Secrets Automation para equipos más chicos. La regla es simple: si es un secreto, no va en el repositorio.

2. No desactives el secret scanning
GitHub ofrece detección automática de secretos en repositorios públicos y privados. Desactivar esa función en un entorno gubernamental es el equivalente a apagar el detector de humo antes de encender la chimenea. En entornos corporativos, conviene sumar herramientas complementarias como Gitleaks o TruffleHog en el pipeline de CI.

3. Rota las credenciales con regularidad
Las claves que permanecen activas durante meses sin rotación son un riesgo incluso sin una filtración activa. Con una filtración, son una ventana abierta. La regla general es: cuanto más privilegiada la credencial, menor debe ser su tiempo de vida.

4. Audita lo que publican los contratistas
Nightwing es una empresa tercera. Una política de DLP (Data Loss Prevention) aplicada al código de terceros habría detectado la publicación antes de que Valadon encontrara el repositorio. Los contratistas con acceso privilegiado necesitan controles equivalentes a los de los empleados internos.

La lección mayor no es que los gobiernos sean incompetentes — es que los static secrets son un problema estructural que afecta a organizaciones de cualquier tamaño, desde la startup hasta el gobierno federal. Lo que cambia es el costo del error.

Si administrás infraestructura, vale la pena entender cómo los logs de auditoría de Windows pueden detectar accesos no autorizados antes de que el daño se agrave. Para ver cómo los pipelines de build comprometidos se convierten en vector de ataque, el caso de JDownloader es un ejemplo reciente y directo. Y si tu equipo usa GitHub como repositorio de código interno, el ataque vía extensión de VS Code a GitHub muestra cuánto puede costar un descuido en un repositorio.