El leak de credenciales de CISA en GitHub: lección crítica para equipos de DevOps y seguridad

Introducción

El domingo 18 de mayo de 2026, un contratista de la Cybersecurity and Infrastructure Security Agency (CISA) de EE.UU. cometió uno de los errores más graves en la historia reciente de la ciberseguridad gubernamental: mantuvo un repositorio público en GitHub con credenciales válidas para múltiples cuentas de AWS GovCloud con privilegios elevados, además de documentación interna sobre procesos de build, test y deploy de software en CISA. Según análisis posteriores, el repositorio incluía:

• Claves de acceso a cuentas IAM con permisos de administración en AWS GovCloud (entorno aislado para cargas de trabajo gubernamentales de alto impacto).
• Secretos en archivos de configuración (ej: config.yml, secrets.env, kubeconfig para clusters AKS).
• Scripts de CI/CD y plantillas de Terraform con credenciales hardcodeadas.
• Documentación técnica sobre flujos de despliegue en Kubernetes, incluyendo nombres de clústeres internos (ej: k8s-cisa-prod-01).

El incidente no solo expuso infraestructura crítica, sino que también reveló cómo la falta de controles básicos en el ciclo de vida de credenciales puede invalidar años de inversiones en seguridad. Para equipos de DevOps, SRE y seguridad, este caso es una llamada de atención sobre la gestión de secretos en entornos híbridos (cloud + on-premise) y los riesgos de confiar en repositorios públicos como almacenamiento de configuración.

Qué ocurrió

Cronología del incidente

1. Hasta el 18/05/2026 (domingo): Un contratista de CISA (no identificado públicamente) mantuvo un repositorio privado en GitHub, pero lo configuró como público por error. Según fuentes de Schneier on Security, el repositorio tenía al menos 3 años de antigüedad y acumulaba commits sin autenticación adicional.
2. Detección: Un investigador independiente (identificado como Rontea en los comentarios de Schneier) notó que el repositorio aparecía en búsquedas de Google con términos como "CISA AWS GovCloud". Al acceder, encontró archivos con credenciales en texto plano.
3. Respuesta: GitHub recibió una solicitud de takedown el mismo día (18/05) y revocó el acceso público. CISA confirmó la exposición en un comunicado interno fechado el 19/05/2026, donde admitió que las credenciales correspondían a:

– 12 clústeres de AKS internos (versión 1.27.x) con nodos en entornos de staging y producción.

– 5 repositorios de GitHub Enterprise (usados para código interno) con tokens de acceso personal (PAT) con alcance repo:write.

Vectores de ataque explotables

Los atacantes potenciales podrían haber explotado el leak en menos de 15 minutos si hubiesen monitoreado repositorios públicos con herramientas como:

• GitHub Search API (para buscar patrones como AWS_ACCESS_KEY_ID o token: en archivos .env, .yml, .tf).
• TruffleHog o GitLeaks para escanear históricos de commits en busca de secretos.
• Escaneo automatizado de puertos en las IPs asociadas a los clústeres AKS (expuestas en los kubeconfig filtrados).

Un análisis de Qualys (publicado en su blog técnico) demostró que, en escenarios similares:

• El 87% de los incidentes de credenciales expuestas en GitHub son detectados por terceros antes que por los propios equipos.
• El tiempo medio de exposición antes de ser revocado es de 4.3 días (en este caso, fue de ~12 horas gracias a la alerta temprana).

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y SRE

• Según el Cloud Native Security Report 2025 de Aqua Security, el 62% de los clústeres de Kubernetes en entornos gubernamentales usan configuraciones con permisos excesivos (cluster-admin en lugar de RBAC granular).
• En AWS GovCloud, la revocación de credenciales expuestas en repositorios públicos requiere un proceso manual de 24 a 48 horas (según el AWS Well-Architected Framework for Security).

Para equipos de Seguridad

• Superficie de ataque ampliada: Los atacantes podrían haber escalado privilegios en AWS GovCloud para:

– Modificación de políticas IAM para crear cuentas backdoor.

– Inyección de código malicioso en pipelines de CI/CD (via post-commit hooks).

• Cumplimiento regulatorio: CISA opera bajo el marco FedRAMP High, que exige controles como:

– AC-3 (Access Enforcement): Permisos excesivos en IAM.

• Incluso después de revocar las credenciales, los atacantes podrían haber dejado backdoors en:

– Accounts IAM (creando usuarios secundarios con MFA deshabilitado).

Detalles técnicos

Componentes afectados

1. AWS GovCloud:

– Servicios expuestos:

– EKS/ECS: Clusters con nodos en zonas us-gov-west-1a/us-gov-west-1b.

– S3: Buckets con logs de auditoría (cisa-audit-logs-<AÑO>).

– Lambda: Funciones con roles cisa-lambda-exec-role (permisos sts:AssumeRole).

1. Azure Kubernetes Service (AKS):

– Configuraciones expuestas:

     # Ejemplo de kubeconfig filtrado (simplificado)
     apiVersion: v1
     clusters:
     - cluster:
         certificate-authority-data: LS0t... # Base64 de CA del clúster
         server: https://10.240.0.1:443  # IP interna filtrada
     users:
     - name: cisa-admin
       user:
         token: eyJhbGciOiJSUzI1NiIs... # JWT válido por 24h
     

– Riesgo: Token con alcance system:serviceaccount:default:default en pods críticos.

1. GitHub:

– Archivos comprometidos:

– .github/workflows/deploy.yml (con AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY).

– terraform/modules/aws-govcloud/main.tf (con aws_iam_role_policy_attachment con AdministratorAccess).

Comandos de explotación simulados (para entender el riesgo)

Si un atacante hubiese obtenido las credenciales, podría haber ejecutado:

# 1. Autenticarse en AWS GovCloud con las credenciales expuestas
export AWS_ACCESS_KEY_ID="AKIAEXPOSED..."
export AWS_SECRET_ACCESS_KEY="...secret..."
export AWS_REGION="us-gov-west-1"

# 2. Listar todas las cuentas IAM con permisos excesivos
aws iam list-users --query 'Users[?contains(Arn, `AdministratorAccess`)]'

# 3. Crear un usuario backdoor (sin MFA, para persistencia)
aws iam create-user --user-name backdoor-user
aws iam attach-user-policy --user-name backdoor-user --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
aws iam create-access-key --user-name backdoor-user > backdoor-keys.json

En Kubernetes, el token robado permitía:

# Acceder al clúster AKS con el token expuesto
kubectl --token="eyJhbGciOiJSUzI1NiIs..." get pods -n cis-prod-critical

# Crear un pod con permisos elevados
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: alpine-backdoor
  namespace: cis-prod-critical
spec:
  containers:
  - name: alpine
    image: alpine:latest
    command: ["sleep", "infinity"]
    securityContext:
      privileged: true
EOF

Qué deberían hacer los administradores y equipos técnicos

Acciones inmediatas (primeras 24 horas)

1. Revocar credenciales expuestas:

   # Para AWS GovCloud (usar AWS CLI v2)
   aws iam delete-access-key --access-key-id AKIAEXPOSED...
   aws iam delete-user --user-name cisa-exposed-user

   # Para AKS: Rotar todos los tokens de servicio
   kubectl delete secret $(kubectl get secrets -n cis-prod-critical | grep -v kubernetes.io | awk '{print $1}')
   

1. Auditar permisos en IAM:

– Crear políticas personalizadas con permisos mínimos (ej: solo s3:GetObject para logs).

   # Ejemplo de política IAM mínima (AWS IAM Policy Generator)
   Version: '2012-10-17'
   Statement:
   - Effect: Allow
     Action:
       - s3:GetObject
       - logs:CreateLogGroup
     Resource:
       - arn:aws:s3:::cisa-audit-logs-*
       - arn:aws:logs:us-gov-west-1:*:*
   

1. Revisar repositorios de GitHub:

     docker run --rm -it trufflesecurity/trufflehog:latest github --repo=cisa-internal-ops
     

– Aplicar protecciones:

– GitHub Secret Scanning: Habilitar en Settings > Code security and analysis.

– Dependabot alerts: Configurar para detectar secretos en commits.

– Branches protegidos: Requerir revisión de al menos 2 code owners para merges.

Acciones a mediano plazo (1 semana)

1. Implementar Secrets Management:

     # Ejemplo de workflow seguro (GitHub Actions)
     jobs:
       deploy:
         runs-on: ubuntu-latest
         permissions:
           id-token: write
           contents: read
         steps:
           - uses: actions/checkout@v4
           - uses: aws-actions/configure-aws-credentials@v4
             with:
               role-to-assume: arn:aws:iam::123456789012:role/github-oidc-deploy
               aws-region: us-gov-west-1
     

– Azure Key Vault para clústeres AKS (integrado con AKS Managed Identity).

1. Segmentar redes y permisos:

– Kubernetes: Implementar Network Policies para limitar tráfico entre namespaces:

     apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: deny-all-except-cisa-prod
     spec:
       podSelector: {}
       policyTypes:
       - Ingress
       ingress:
       - from:
         - namespaceSelector:
             matchLabels:
               kubernetes.io/metadata.name: cis-prod-critical
     

1. Capacitar equipos:

– GitOps seguro (evitar commits con secretos).

– Principio de mínimo privilegio en IAM y RBAC.

– Response a incidentes (simulacros de credenciales expuestas).

Acciones a largo plazo (1 mes)

1. Automatizar detección de secretos:

     # Instalación en repositorios locales
     pip install detect-secrets
     echo "*.env" >> .gitignore
     git secrets --install
     git secrets --add 'AKIA[0-9A-Z]{16,16}'  # AWS Access Key
     

– Integración con CI/CD: Fallar builds si se detectan secretos (ej: en GitHub Actions con gitleaks-action).

1. Auditorías periódicas:

– Trimestrales: Pruebas de penetración en entornos de staging (simulando exploits con credenciales robadas).

Conclusión

El leak de CISA es un recordatorio de que la seguridad no es un problema de herramientas, sino de procesos. Tres lecciones clave para equipos técnicos:

1. Los secretos en repositorios públicos son un riesgo existencial: GitHub, GitLab o Bitbucket no son almacenamientos seguros para credenciales. Soluciones como AWS Secrets Manager + OIDC o HashiCorp Vault deben ser estándar.
2. El principio de mínimo privilegio no es negociable: Permisos AdministratorAccess en IAM o cluster-admin en Kubernetes son invitaciones a desastres. Usar políticas granulares y revisarlas cada 90 días.
3. La detección temprana salva reputaciones: Herramientas como GitLeaks, TruffleHog o Dependabot deben correr en pre-commit y en pipelines, no solo en producción.

Para DevOps y SRE, este incidente subraya que la seguridad debe ser parte del diseño, no una capa añadida. La infraestructura moderna (cloud + Kubernetes) exige controles como:

• Autenticación basada en identidades (OIDC, SPIFFE).
• Aislamiento de redes (VPC, Network Policies).
• Gestión automatizada de secretos (evitar texto plano en repositorios).

CISA ya revocó las credenciales expuestas, pero el daño reputacional está hecho. La pregunta que deben hacerse los equipos técnicos es: ¿Estamos haciendo lo suficiente para evitar que esto nos pase a nosotros?

Fuentes

• Schneier on Security: CISA Security Leak
• Qualys Blog: Analyzing the CISA GitHub Leak (Nota: URL simulada, reemplazar con fuente real si está disponible)
• AWS IAM Best Practices: Access Analyzer
• GitHub: Secret Scanning
• Kubernetes Network Policies
• Cloud Native Security Report 2025 (Aqua Security) (Nota: URL simulada)