CISA vaza credenciais AWS GovCloud no GitHub por 6 meses

A agência americana responsável por defender a infraestrutura crítica dos Estados Unidos contra ataques cibernéticos vazou as próprias credenciais no GitHub — e ficaram acessíveis ao público por seis meses. O repositório foi descoberto em 15 de maio de 2026 por Guillaume Valadon, pesquisador da firma GitGuardian, que notificou a CISA. A história chegou ao conhecimento público via Krebs on Security dias depois, gerando reação imediata do Congresso americano.

O que estava no repositório

O repositório público se chamava “Private-CISA” — o nome já diz tudo sobre o nível de controle aplicado. Era mantido por um funcionário da Nightwing, empresa contratada sediada em Dulles, Virgínia. Esteve acessível desde 13 de novembro de 2025 até ser removido em 18 de maio de 2026: 184 dias de exposição.

Em 844 megabytes de dados havia:

• Credenciais de administrador de três contas AWS GovCloud — as nuvens governamentais que hospedam sistemas sensíveis da CISA
• Senhas em texto plano de dezenas de sistemas internos, armazenadas num arquivo CSV
• Chaves SSH e arquivos de configuração do Kubernetes
• Workflows do GitHub Actions
• Uma chave RSA privada com acesso a todos os repositórios de código da CISA-IT
• Documentação detalhada dos processos internos de build e deploy

Para colocar em perspectiva: a CISA coordena a defesa cibernética de toda a infraestrutura crítica americana — usinas de energia, sistemas de saúde, redes eleitorais. Quem tinha acesso a esse repositório tinha, potencialmente, acesso ao pipeline que produz as ferramentas que protegem esses sistemas.

O erro técnico por trás do vazamento

Não foi um exploit sofisticado nem um zero-day. O contratado desativou manualmente a configuração padrão do GitHub que bloqueia a publicação de segredos e chaves em repositórios públicos — a funcionalidade de secret scanning que qualquer conta tem habilitada por padrão.

O resultado é o que a comunidade de segurança chama de static secrets: credenciais armazenadas como texto puro em arquivos versionados, em vez de gerenciadas por um vault dedicado. OWASP lista o mau gerenciamento de segredos entre as falhas mais comuns em desenvolvimento de software há anos. A diferença aqui é quem cometeu o erro e qual era o alvo.

A resposta que chegou tarde

Depois de receber a notificação da GitGuardian em 15 de maio, a CISA retirou o repositório do ar três dias depois. Mas revogar credenciais não foi tão rápido:

• Algumas chaves AWS GovCloud continuaram funcionando por 48 horas depois que o repositório foi removido
• A chave RSA privada ficou sem revogação por pelo menos cinco dias após a CISA receber a primeira notificação

Isso importa porque qualquer ator que tivesse clonado o repositório antes da remoção continuaria com acesso válido por dias. A exposição não termina quando o repositório é tornado privado — termina quando cada credencial individual é revogada e substituída.

O Congresso pediu explicações

Parlamentares de ambas as câmaras do Congresso enviaram cobranças formais à agência. A questão central não é só o erro do contratado: é como uma chave de administrador de AWS GovCloud chegou a um CSV num repositório público sem que nenhum sistema de detecção disparasse um alerta nos 184 dias anteriores.

A CISA é a mesma agência que publica diretrizes de hardening para o resto do governo americano. A pergunta óbvia que os parlamentares fazem é: se nem vocês seguem, por que o resto deveria?

O que qualquer equipe pode extrair disto

Este caso é didático porque o erro é simples e o impacto é máximo. Algumas práticas que teriam impedido o vazamento:

1. Nunca armazene credenciais em texto plano
Senhas em CSV, tokens em arquivos .env commitados, chaves diretamente no código — tudo isso precisa ir para um secrets manager. AWS Secrets Manager, Azure Key Vault, HashiCorp Vault ou Bitwarden Secrets Automation para equipes menores. A regra é simples: se for um segredo, não vai no repositório.

2. Não desabilite o secret scanning
O GitHub oferece detecção automática de segredos em repositórios públicos e privados. Desabilitar essa função num ambiente governamental é o equivalente a desligar o detector de fumaça antes de acender a lareira. Em ambientes corporativos, considere ferramentas complementares como Gitleaks ou TruffleHog no pipeline de CI.

3. Rotacione credenciais com regularidade
Chaves que ficam ativas por meses sem rotação são um risco mesmo sem vazamento ativo. Com vazamento, são uma janela aberta. A regra geral é: quanto mais privilegiada a credencial, menor deve ser seu tempo de vida.

4. Audite o que contratados publicam
A Nightwing é uma empresa terceira. Uma política de DLP (Data Loss Prevention) aplicada ao código de terceiros teria detectado a publicação antes que Valadon encontrasse o repositório. Contratados com acesso privilegiado precisam de controles equivalentes aos funcionários internos.

A lição maior não é que governos são incompetentes — é que static secrets são um problema estrutural que afeta organizações de qualquer tamanho, do startup ao governo federal. O que muda é o custo do erro.

Se você gerencia infraestrutura, vale entender como logs de auditoria do Windows podem detectar acesso não autorizado antes que o estrago se agrave. Para ver como pipelines de build comprometidos viram vetor de ataque, o caso do JDownloader é um exemplo recente e direto. E se sua equipe usa GitHub como repositório de código interno, o ataque via extensão VS Code ao GitHub mostra o quanto um descuido em repositório pode custar.