Megalodon: o ataque que mostrou como o CI/CD também virou alvo da cadeia de suprimentos

Nos últimos anos, nós nos acostumamos a pensar em segurança de software olhando para bibliotecas, frameworks, pacotes NPM, imagens Docker e vulnerabilidades conhecidas em dependências. Isso continua sendo importante, mas o incidente chamado Megalodon mostrou algo ainda mais sensível: o atacante não precisa necessariamente alterar o código principal da aplicação para causar danos. Às vezes, basta comprometer o caminho pelo qual esse código é testado, empacotado e publicado.

O caso Megalodon foi reportado como uma campanha automatizada contra repositórios públicos no GitHub. Segundo pesquisadores da StepSecurity/SafeDep, em uma janela de aproximadamente seis horas, foram inseridos workflows maliciosos do GitHub Actions em 5.561 repositórios, por meio de 5.718 commits maliciosos que aparentavam ser alterações comuns de manutenção ou otimização de CI/CD. (StepSecurity)

Para quem está começando, vale explicar: CI/CD significa Continuous Integration e Continuous Delivery/Deployment, ou seja, integração contínua e entrega ou implantação contínua. É o conjunto de automações que compila, testa, empacota e muitas vezes publica uma aplicação. No GitHub, isso geralmente é feito com arquivos YAML dentro da pasta .github/workflows. Esses arquivos dizem ao GitHub Actions quais comandos executar quando há um push, pull request, criação de tag ou publicação de release.

O grande problema é que esses workflows têm acesso a um ambiente muito valioso. Eles podem ler variáveis de ambiente, tokens temporários, credenciais de publicação, permissões de nuvem e segredos usados para deploy. No Megalodon, os workflows maliciosos buscavam capturar dados como credenciais AWS, tokens do Google Cloud, credenciais Azure, chaves SSH, tokens OIDC, configurações Docker/Kubernetes, Vault tokens e outros segredos típicos de pipelines modernos. (The Hacker News)

Como o ataque ocorreu

O ataque não parece ter explorado uma falha clássica do GitHub com um CVE específico. Esse é um ponto importante. Ele foi descrito como uma campanha “zero-CVE”, ou seja, uma situação em que os mecanismos existentes funcionam como foram projetados, mas são abusados por meio de permissões comprometidas, tokens vazados, chaves de deploy ou acessos de escrita indevidamente protegidos. (Phoenix Security)

Na prática, o atacante inseria commits falsificados que pareciam vir de um bot de automação, usando nomes como se fossem ajustes rotineiros de build. Essa escolha foi estratégica. Em muitos projetos, alterações em arquivos de CI/CD recebem menos atenção do que mudanças no código-fonte principal, especialmente quando parecem apenas “otimizar build”, “corrigir pipeline” ou “atualizar automação”.

O perigo estava no fato de que o código malicioso era executado dentro do runner do GitHub Actions. Um runner é o ambiente que executa o workflow. Quando esse workflow roda, ele pode acessar variáveis, arquivos temporários, tokens e permissões configuradas no projeto. Assim, mesmo que o código da aplicação não tenha sido diretamente alterado, o atacante conseguia agir dentro do sistema de entrega do software.

Esse é o ponto mais didático do incidente: a esteira de entrega também é parte do software. O YAML do GitHub Actions não é apenas “configuração”. Ele é código operacional. Se ele executa comandos, baixa dependências, usa tokens e publica artefatos, então ele precisa ser tratado com o mesmo rigor de revisão aplicado ao código da aplicação.

Quem foi atingido

Os principais atingidos foram repositórios públicos no GitHub que receberam esses workflows maliciosos. O número reportado pelos pesquisadores foi superior a 5.500 repositórios, com milhares de commits automatizados em poucas horas. (SecurityWeek)

Mas o impacto não para no repositório. Quando um projeto comprometido publica pacotes em registries como o NPM, o ataque pode alcançar usuários que instalam aquele pacote. No caso reportado, versões do pacote Tiledesk foram citadas como comprometidas após o repositório GitHub ter sido envenenado. A SecurityWeek observou que a conta NPM em si aparentemente não foi comprometida diretamente; o problema teria sido a publicação de código já contaminado a partir do repositório afetado. (SecurityWeek)

Isso demonstra a natureza de um ataque de cadeia de suprimentos. O alvo inicial pode ser um mantenedor, um token, um repositório ou um workflow. Mas o efeito pode se espalhar para usuários, empresas, aplicações em produção, ambientes de nuvem e pipelines de terceiros. Quem instala um pacote, usa uma action, consome uma imagem ou confia em uma automação também entra indiretamente nessa cadeia.

O que esse incidente ensina aos desenvolvedores

O Megalodon mostra que a segurança moderna não pode ficar restrita ao código-fonte da aplicação. Precisamos olhar para o ecossistema inteiro: repositórios, permissões, secrets, tokens, actions, dependências, ambientes de build, deploy e publicação.

Também precisamos abandonar a ideia de que automação é sempre neutra. Uma automação mal configurada pode ser tão perigosa quanto uma vulnerabilidade em produção. Um workflow com permissão excessiva pode publicar pacotes, acessar secrets, criar releases, modificar artefatos e interagir com serviços externos. Se esse workflow for adulterado, ele vira uma porta de saída para credenciais e dados sensíveis.

Outro aprendizado importante é que commits aparentemente simples precisam ser revisados com cuidado. Um arquivo YAML pequeno pode conter comandos codificados, scripts externos, uso indevido de curl, execução de Bash ofuscado, download de payloads e envio de dados para servidores externos. Em projetos grandes, onde muitos mantenedores aceitam contribuições, esse tipo de alteração pode passar despercebido.

Como se proteger

A primeira medida é revisar com atenção os arquivos dentro de .github/workflows. Mudanças em workflows devem ser tratadas como mudanças críticas, especialmente quando envolvem permissões, comandos shell, variáveis de ambiente, secrets, publicação de pacotes ou acesso a provedores de nuvem.

Também é importante aplicar o princípio do menor privilégio. No GitHub Actions, isso significa configurar permissões mínimas para o GITHUB_TOKEN. Nem todo workflow precisa ter permissão de escrita. Muitos pipelines só precisam ler o repositório e executar testes. Quando a permissão de escrita é concedida por padrão, o impacto de um workflow malicioso aumenta bastante.

Outro cuidado é evitar secrets permanentes sempre que possível. Tokens de longa duração são perigosos porque, uma vez vazados, podem ser usados fora do contexto original. Uma estratégia mais segura é usar credenciais temporárias, OIDC bem configurado, rotação periódica de chaves e políticas de acesso restritivas no provedor de nuvem.

A autenticação em dois fatores também é indispensável para mantenedores e administradores de repositórios. Além disso, chaves de deploy, tokens pessoais e integrações de terceiros precisam ser auditados regularmente. Muitas vezes, o problema não está em uma senha fraca, mas em um token antigo esquecido com permissões amplas demais.

Em projetos com publicação em NPM, PyPI, Docker Hub ou outros registries, a proteção precisa ser ainda mais rigorosa. Antes de publicar uma nova versão, é prudente verificar se houve alteração inesperada em workflows, scripts de build, dependências, arquivos de publicação e comandos de pré/pós-instalação. Um pacote pode parecer legítimo porque foi publicado pelo mantenedor correto, mas ainda assim carregar código contaminado se o repositório de origem tiver sido comprometido.

Medidas práticas para equipes

Para equipes profissionais, eu adotaria uma política simples: qualquer alteração em CI/CD precisa passar por revisão obrigatória de alguém com conhecimento técnico suficiente para entender o impacto operacional daquela mudança. Não basta aprovar porque “é só um YAML”.

Também é recomendável ativar proteção de branches, exigir revisão em pull requests, bloquear push direto em branches principais, usar CODEOWNERS para arquivos críticos e separar ambientes de build, teste e publicação. Workflows que publicam pacotes ou fazem deploy devem ser mais protegidos do que workflows que apenas executam testes.

Outra medida relevante é monitorar comportamento anormal. Se um workflow começa a acessar domínios estranhos, executar comandos ofuscados, imprimir variáveis de ambiente ou transferir arquivos para servidores externos, isso deve gerar alerta. Segurança em CI/CD não é apenas configuração inicial; é observação contínua.

Conclusão

O Megalodon não deve ser visto apenas como “mais um ataque ao GitHub”. Ele é um alerta sobre a maturidade necessária para desenvolver software em um mundo baseado em automação, dependências e entrega contínua.

Hoje, uma aplicação não é formada apenas por seus arquivos .js, .py, .c, .java ou .ts. Ela também é formada por seus workflows, scripts, tokens, pipelines, imagens, pacotes e permissões. Quando essa cadeia é comprometida, o dano pode acontecer antes mesmo do software chegar ao usuário final.

A lição principal é direta: proteja sua esteira de entrega como você protege seu código-fonte. Em muitos projetos modernos, o pipeline já é parte da aplicação. E, como o Megalodon mostrou, atacar o caminho de entrega pode ser mais eficiente do que atacar o software em si.

Referências

StepSecurity — Megalodon: Mass GitHub Actions Secret Exfiltration Across 5,500+ Public Repositories. (StepSecurity)
The Hacker News — Megalodon GitHub Attack Targets 5,561 Repos with Malicious CI/CD Workflows. (The Hacker News)
SecurityWeek — Over 5,500 GitHub Repositories Infected in ‘Megalodon’ Supply Chain Attack. (SecurityWeek)
Phoenix Security — MEGALODON_CI: GitHub Actions Workflow Poisoning and CI/CD Credential Harvesting at Scale. (Phoenix Security)
Dark Reading — ‘Megalodon’ Malware Infects Thousands of GitHub Repos. (Dark Reading)