GitHub Actions do Snowflake expõe credenciais do Jira em falha

O GitHub Actions se tornou uma peça central na automação de testes, validações e entregas de software, mas também passou a representar um alvo cada vez mais atraente para ataques contra cadeias de desenvolvimento. Um caso recente envolvendo um repositório público da Snowflake mostrou como uma alteração aparentemente simples em um workflow pode transformar uma entrada controlada por usuários em uma porta de acesso a recursos internos.

A falha estava no fluxo .github/workflows/jira_issue.yml e permitia uma forma de injeção de comandos em workflow. Durante um teste autorizado, o Red Agent, ferramenta autônoma de validação ofensiva da Wiz, conseguiu explorar o problema a partir de uma issue criada no GitHub e chegar a um token usado para acesso ao Jira interno da Snowflake.

O episódio também ganhou atenção por envolver o GitHub Copilot Autofix, levantando uma discussão importante: até que ponto ferramentas de inteligência artificial podem introduzir ou aprovar mudanças inseguras em componentes críticos de CI/CD? A análise do histórico do Git, porém, exige uma distinção importante entre participação da IA em um Pull Request e autoria comprovada das linhas vulneráveis.

Como funcionou a falha no GitHub Actions

O problema estava relacionado à maneira como o workflow processava informações provenientes de GitHub Issues. Dados como github.event.issue.title e github.event.issue.body são controlados pelo usuário que cria ou edita a issue e, portanto, devem ser tratados como entrada não confiável.

O risco aparece quando esses valores são inseridos diretamente dentro de um bloco run:. O GitHub avalia as expressões ${{ }} antes de entregar o script ao shell executado pelo runner. Dessa forma, um conteúdo especialmente construído pode deixar de ser apenas texto e acabar alterando a interpretação do comando.

Em termos simplificados, a diferença de segurança está entre tratar uma informação como dado ou permitir que ela participe da construção de um comando executável.

Esse comportamento é particularmente perigoso em workflows acionados por eventos públicos, como abertura de issues. O atacante não precisa necessariamente ter acesso de gravação ao repositório: basta conseguir controlar o conteúdo utilizado pelo workflow.

Outro problema identificado na lógica era uma tentativa de validar github.event.pull_request.user.login em um fluxo associado à abertura de issues. A verificação não oferecia a proteção esperada porque o evento e o contexto avaliados não correspondiam à fonte efetiva da entrada utilizada pelo workflow.

Esse tipo de erro demonstra uma regra fundamental de DevSecOps: validações precisam considerar não apenas o conteúdo recebido, mas também qual evento o executou, quem pode controlá-lo e quais privilégios estarão disponíveis durante a execução.

O próprio GitHub classifica campos como issue.title, issue.body, títulos e corpos de Pull Requests e comentários como possíveis fontes de entrada controlada por atacantes.

O ataque do Red Agent e a exposição do token do Jira

A descoberta não veio de um ataque criminoso contra a infraestrutura da Snowflake. Ela ocorreu durante uma avaliação autorizada de segurança realizada pela Wiz, utilizando o Red Agent, agente de IA desenvolvido para simular caminhos reais de ataque e validar se vulnerabilidades teóricas são efetivamente exploráveis.

A exploração começou com uma issue especialmente preparada no repositório público. A partir da injeção no workflow, o agente conseguiu executar comandos no ambiente do runner e investigar os recursos disponíveis naquele contexto.

O resultado mais relevante foi a obtenção de um token de API associado a uma conta de QA do Jira. Segundo as informações divulgadas sobre o caso, esse token permitia leitura de projetos internos relacionados a áreas como engenharia, conformidade e bug bounty.

Isso muda completamente a avaliação do problema. Uma falha que poderia inicialmente parecer restrita ao processamento de uma issue acabou criando uma cadeia de ataque envolvendo repositório público → workflow privilegiado → execução de comandos → credencial → sistema corporativo interno.

Esse é justamente o tipo de caminho que ferramentas de segurança ofensiva autônomas procuram encontrar.

A resposta da Snowflake foi rápida. A empresa recebeu o relatório por meio do HackerOne e realizou a rotação do token em aproximadamente 24 horas. A investigação também não encontrou evidências de acesso externo não autorizado ao token durante o período de exposição informado, de cerca de cinco dias.

É importante diferenciar, portanto, explorabilidade de comprometimento confirmado. O Red Agent demonstrou que o caminho de ataque funcionava, mas isso não significa que um invasor externo tenha utilizado a vulnerabilidade antes da correção.

O papel da IA no código vulnerável: mito versus realidade

A participação do GitHub Copilot Autofix é um dos aspectos mais interessantes do incidente, mas também exige cautela.

A narrativa inicial poderia levar à conclusão de que o Copilot simplesmente escreveu o código vulnerável. A análise do histórico do Git apresentada após a descoberta mostra uma situação mais complexa.

O histórico registra alterações anteriores relacionadas aos workflows e, posteriormente, uma squash merge que reuniu mudanças em um único commit. O commit final registrava o Copilot Autofix como coautor, mas isso não comprova, isoladamente, que a IA tenha escrito as linhas vulneráveis de jira_issue.yml.

Essa distinção é fundamental.

O que o episódio demonstra com segurança é que uma alteração insegura passou pelo processo de desenvolvimento e acabou incorporada a uma mudança que também teve participação atribuída ao Copilot. A autoria exata das linhas vulneráveis e a participação específica da ferramenta na criação daquela lógica não podem ser determinadas simplesmente observando o campo de coautoria.

A lição para empresas não deveria ser “não use IA para programar”. O problema é outro: código gerado ou modificado por IA precisa passar pelo mesmo nível de revisão humana, testes e análise de segurança que qualquer código escrito manualmente.

Isso é especialmente importante para arquivos YAML de CI/CD. Um pequeno erro em uma aplicação pode afetar uma funcionalidade. Um pequeno erro em um workflow pode entregar tokens, segredos e permissões do ambiente de desenvolvimento.

Como proteger o GitHub Actions contra injeções

A correção recomendada para esse tipo de problema é relativamente simples, mas precisa ser aplicada de maneira consistente.

Em vez de inserir diretamente uma expressão não confiável dentro de run:, o valor deve ser colocado em uma variável de ambiente intermediária. O script passa então a trabalhar com a variável como dado, reduzindo o risco de que o conteúdo recebido seja interpretado como parte da estrutura do shell. O GitHub recomenda explicitamente esse padrão para mitigar injeções.

Outra abordagem é evitar scripts inline quando uma Action pode receber o valor como argumento. Nesse modelo, o contexto é transmitido para a ação sem participar diretamente da construção de um script shell.

No caso analisado, a correção também envolveu o uso de variáveis intermediárias e processamento seguro com jq, reduzindo a possibilidade de que conteúdo proveniente de issues fosse interpretado pelo shell.

Para equipes que administram workflows, algumas práticas devem ser consideradas obrigatórias:

• Trate todo conteúdo vindo de issues, Pull Requests e comentários como não confiável.
• Evite interpolar diretamente ${{ github.event.* }} dentro de comandos run:.
• Use variáveis de ambiente intermediárias para transportar entradas externas.
• Prefira Actions específicas quando elas eliminarem a necessidade de montar comandos shell dinamicamente.
• Aplique o princípio do menor privilégio às permissões do GITHUB_TOKEN e às credenciais utilizadas pelos workflows.
• Não disponibilize segredos para etapas que processam código ou dados não confiáveis.
• Revise workflows acionados por eventos públicos, principalmente issues, issue_comment e determinados eventos relacionados a Pull Requests.
• Roteie e revise alterações de CI/CD auxiliadas por IA, tratando arquivos de workflow como código sensível.
• Faça rotação periódica das credenciais, reduzindo a janela de exposição caso um segredo seja comprometido.

Também é recomendável estabelecer políticas centralizadas para controlar quais eventos podem executar workflows privilegiados. O GitHub possui mecanismos de proteção da execução de workflows justamente para restringir atores e eventos capazes de iniciar determinadas automações.

Conclusão: CI/CD também precisa ser tratado como código crítico

O caso da Snowflake mostra que a segurança de uma cadeia de desenvolvimento não termina no código da aplicação. Workflows do GitHub Actions são código executável, possuem acesso a infraestrutura, tokens e segredos e, por isso, precisam receber o mesmo rigor aplicado a APIs, servidores e componentes de produção.

O aspecto mais preocupante não foi apenas a existência de uma injeção de comandos. Foi a possibilidade de transformar uma ação aparentemente inofensiva, como abrir uma issue pública, em um caminho até uma credencial interna.

A participação do Red Agent também sinaliza uma mudança importante no cenário de segurança: agentes autônomos conseguem testar caminhos de ataque em velocidade e escala muito superiores às avaliações manuais tradicionais. Ao mesmo tempo, o episódio envolvendo o Copilot Autofix reforça que velocidade na geração de código não substitui revisão e validação.

Para desenvolvedores e equipes de DevOps e DevSecOps, o momento é ideal para revisar os arquivos .github/workflows/*.yml, especialmente aqueles acionados por usuários externos. Procure por entradas de github.event diretamente dentro de run:, revise permissões, limite o acesso a segredos e questione se cada workflow realmente precisa dos privilégios que possui.

No CI/CD, uma única linha insegura pode ser suficiente para transformar automação em superfície de ataque.