Recentemente, a ActiveState divulgou um estudo que revelou um padrão de ataque em GitHub Actions que escapa por completo dos scanners de segurança de integração contínua (CI) mais comuns. O relatório, publicado em abril de 2024, destaca que cerca de 30 por cento das pipelines de grandes empresas que utilizam GitHub Actions contêm vulnerabilidades que não são detectadas por ferramentas de análise estática ou dinâmica. O que torna esse cenário ainda mais alarmante é que o ataque não depende de uma falha de código, mas sim da manipulação de variáveis de ambiente e da sequenciação de jobs dentro do fluxo de trabalho.
O padrão em questão explora a capacidade de GitHub Actions de executar scripts em ambientes compartilhados, onde cada job pode receber variáveis que são passadas de um job para outro. Um atacante malicioso pode, por exemplo, injetar um comando que eleva privilégios para um job posterior, usando um token de acesso que foi concedido por erro de configuração. Quando o pipeline termina, o token pode estar comprometido e o código malicioso pode persistir no repositório ou na infraestrutura de deploy. Esse ataque passa despercebido porque os scanners tradicionais verificam apenas o código fonte e não a lógica de execução de pipelines.
Para o cenário brasileiro, a ameaça traz consequências diretas para empresas de todos os tamanhos que adotam GitHub Actions como parte de seus pipelines de DevOps. Pequenos negócios que dependem de serviços em nuvem para entrega contínua podem ter suas credenciais expostas sem nem perceber, enquanto grandes corporações enfrentam o risco de vazamento de dados sensíveis, como chaves de API, informações de clientes e dados pessoais. No contexto da LGPD, a exposição de dados pessoais sem consentimento pode acarretar multas pesadas e danos à reputação, além de comprometer a confiança dos consumidores.
Do ponto de vista técnico, o ataque funciona em três etapas: (1) a criação de um job malicioso que modifica variáveis de ambiente que serão usadas em jobs subsequentes; (2) a execução de um script que salva essas variáveis em arquivos temporários ou em um repositório comprometido; e (3) a propagação do token comprometido para o ambiente de produção através de um job que faz deploy. Como os scanners de CI normalmente analisam apenas os arquivos .yml e o código, eles não detectam a alteração dinâmica das variáveis, nem a execução de scripts que são carregados em tempo de execução.
Para mitigar esse risco, as empresas devem adotar uma estratégia de governança de CI/CD que inclua (a) o uso do GitHub OIDC (OpenID Connect) para reduzir o número de tokens de acesso permanentes, (b) a aplicação de regras de policy que limitem o que pode ser executado em cada job, e (c) a implementação de monitoramento em tempo real que verifique alterações inesperadas em variáveis de ambiente. Além disso, ferramentas como o GitHub Advanced Security e o Dependabot podem ser configuradas para escanear os workflows em busca de padrões suspeitos, como a modificação de variáveis de ambiente.
Em suma, a mensagem da ActiveState é clara: passar um scanner não garante a segurança de uma pipeline. As organizações precisam tratar os workflows de CI/CD como ativos críticos, aplicando controles de acesso rigorosos e monitoramento contínuo. Investir em treinamento de desenvolvedores e operadores para reconhecer padrões de ataque em GitHub Actions também é essencial.
Nos próximos dias, espera-se que o GitHub anuncie melhorias em suas ferramentas de segurança, incluindo um scanner de workflows que verifique a integridade das variáveis de ambiente e a sequência de jobs. Enquanto isso, os profissionais de segurança devem revisar imediatamente suas políticas de CI/CD e considerar a adoção de soluções que ofereçam visibilidade total do fluxo de trabalho, reduzindo assim o risco de ataques que escapam dos scanners tradicionais.