Copilot reviewed CI failure and the Red Agent identified the risk

O que é o caso Snowflake e Copilot

Em 17 de agosto de 2026, a Wiz publicou uma análise de segurança sobre uma falha em um workflow de GitHub Actions do repositório público snowflakedb/snowflake-connector-net. O Red Agent, ferramenta autónoma de pesquisa da Wiz, identificou uma possibilidade de injeção de script e conseguiu avaliar o alcance do problema.

A falha estava em um workflow acionado quando uma issue era aberta. O título da issue era controlado por quem criava a issue e acabava sendo inserido diretamente em um comando de shell. Com isso, uma pessoa sem autenticação especial poderia tentar executar comandos no runner do GitHub Actions.

O detalhe que chamou a atenção da comunidade foi a participação do Copilot na revisão do pull request que levou o código vulnerável ao repositório. A atualização da própria Wiz esclarece que o Copilot foi coautor e marcou o código mesclado como aprovado, mas não é possível afirmar que a alteração inteira foi gerada por IA.

Como a falha funcionava

O workflow recebia eventos de abertura de issues e usava o título informado pelo usuário para montar uma operação de shell. Esse título era uma entrada externa, portanto deveria ser tratado como dado e não como parte da estrutura do comando.

O problema surgiu quando o código passou a expandir o valor dentro do script antes que a proteção contra caracteres especiais fosse aplicada de forma segura. Uma entrada criada para quebrar o contexto do comando poderia alterar o que o shell executava no runner.

O Red Agent encontrou o caminho ao analisar a configuração de CI/CD e depois validou o acesso ao ambiente de prova de conceito. A investigação informou que a falha permitia alcançar dados sensíveis no Jira interno da Snowflake, sem afirmar que houve exploração por terceiros.

Principais lições para quem usa CI/CD

A primeira lição é separar dados de comandos. Variáveis recebidas de eventos do GitHub devem ser passadas por ambiente ou por arquivos temporários com permissões controladas, sem interpolação direta dentro de uma string de shell.

A segunda é revisar o workflow como código de produção. O arquivo YAML pode receber tokens, acessar artefatos, publicar pacotes e alterar infraestrutura. Um pequeno erro de quoting pode ter impacto maior que um bug em uma função comum.

A terceira é combinar análise estática, testes e revisão humana. O CodeQL e o Copilot Autofix ajudam a encontrar e corrigir alertas, mas trabalham com cobertura e contexto limitados. Nenhuma dessas camadas substitui a leitura do fluxo completo.

• Entrada externa: trate como dado sem confiança.
• Runner: reduza permissões e não use privilégios desnecessários.
• Segredos: mantenha o escopo mínimo e evite expô-los em logs.

Como começar: auditoria segura do workflow

Comece listando todos os eventos que acionam seus workflows. Eventos como issues, pull_request_target e comentários podem ser influenciados por pessoas fora da equipe, e cada um exige uma análise diferente de confiança.

Depois, procure expressões do GitHub Actions dentro de blocos run:. O objetivo não é proibir expressões, mas evitar que valores controlados externamente sejam incorporados diretamente em comandos.

Por fim, confira as permissões do job, os segredos disponíveis, as actions usadas e os artefatos produzidos. Um workflow que só precisa ler o repositório não deveria receber permissão de escrita em conteúdo, pacotes ou configurações.

name: triage-issue\non:\n  issues:\n    types: [opened]\njobs:\n  triage:\n    runs-on: ubuntu-latest\n    permissions:\n      contents: read\n    steps:\n      - name: Ler título com segurança\n        env:\n          ISSUE_TITLE: ${{ GitHub.event.issue.title }}\n        run: |\n          printf '%s\n' "$ISSUE_TITLE"

O exemplo usa uma variável de ambiente para transportar o título até o processo. Ainda assim, o comando precisa ser simples, o valor não deve virar código e o job deve ter somente as permissões necessárias para sua tarefa.

Exemplo prático: corrigindo um fluxo de triagem

Imagine um workflow que adiciona uma etiqueta quando uma issue é aberta. A versão frágil monta um comando com o título dentro da própria linha de execução. Essa estrutura mistura configuração e dado, dificultando a análise e abrindo espaço para injeção.

Na versão mais segura, o workflow recebe o título em uma variável de ambiente e chama uma ferramenta que aceita o valor como argumento ou entrada de dados. A rotina não precisa avaliar o texto como shell, nem fazer uma sequência improvisada de substituições.

Antes de mesclar a correção, crie testes com títulos que contenham espaços, aspas, acentos, cifrões, barras e quebras de linha. O objetivo é verificar se o workflow continua tratando tudo como texto. Também confira os logs para garantir que o título não vaze junto com tokens.

Comparação com as camadas de proteção

O CodeQL é a camada determinística para padrões de vulnerabilidade que a análise consegue modelar. Ele pode apontar fluxos perigosos e alimentar alertas no repositório, mas a qualidade depende da consulta, da linguagem e da configuração usada.

O Copilot Autofix transforma alertas de análise em sugestões de alteração e explicações. A documentação do GitHub descreve o recurso como uma recomendação direcionada, não como uma garantia de que o problema foi resolvido em todos os cenários.

A revisão humana completa o processo ao avaliar intenção, permissões, contexto operacional e impacto. Em workflows de CI/CD, essa camada é especialmente importante porque o risco não está apenas no código, mas também nos eventos, runners, segredos e serviços acessados.

• CodeQL: bom para padrões analisáveis e alertas repetíveis.
• Autofix: útil para acelerar propostas de correção.
• Revisão humana: essencial para validar ameaça, contexto e blast radius.

Pontos positivos e limitações da IA na revisão

Ferramentas de IA podem acelerar a leitura de arquivos grandes, explicar um alerta e sugerir uma correção inicial. Isso reduz o tempo até uma primeira resposta e ajuda equipes menores a começar uma investigação.

A limitação é que a IA pode deixar passar relações que dependem do ambiente. Um workflow aparentemente simples pode herdar permissões, segredos e eventos de outros arquivos. A ferramenta também pode interpretar como seguro um padrão que só funciona quando a entrada é totalmente confiável.

O próprio caso analisado pela Wiz é um lembrete prático: a presença de uma revisão assistida por IA não transforma o pull request em seguro por definição. O resultado precisa ser testado, revisado e observado depois da publicação.

Casos de uso reais

Em projetos open source, issues são uma entrada pública e podem ser abertas por qualquer pessoa. Workflows de triagem devem assumir que títulos e descrições podem conter conteúdo hostil, mesmo quando a intenção do projeto é apenas organizar tickets.

Em empresas, comentários de pull request e nomes de branches também podem cruzar fronteiras de confiança. Um workflow usado por forks ou contribuições externas precisa separar tarefas de validação de tarefas que acessam recursos internos.

Em pipelines de publicação, o cuidado deve ser ainda maior. Um job que compila código pode ter acesso a tokens de registro, chaves de assinatura ou credenciais de nuvem. Se a entrada externa chegar até esse job, uma falha de injeção pode transformar um processo de build em um caminho para dados sensíveis.

Dicas e boas práticas

Use permissões explícitas em cada job e comece com o conjunto mínimo. Prefira contents: read quando o job só precisa consultar o código. Se uma etapa precisa escrever, restrinja o escopo e documente o motivo.

Evite executar texto externo com shell quando uma biblioteca ou uma ferramenta com argumentos estruturados resolve o problema. Se o shell for indispensável, passe valores por ambiente, use quoting correto e teste caracteres especiais.

Monitore os logs de execução e mantenha um inventário de actions, runners e permissões. Quando houver um alerta, registre o que foi acessado, quais credenciais foram rotacionadas e quais jobs foram revisados.

Vale a pena confiar em revisão assistida por IA?

Vale a pena usar IA como parte de uma defesa em camadas. Ela pode encontrar padrões, acelerar a investigação e sugerir mudanças que um desenvolvedor consegue revisar com mais rapidez.

Não vale a pena transformar o selo de aprovação da ferramenta em uma decisão automática. O caso Snowflake mostra que um workflow vulnerável pode chegar ao repositório mesmo quando uma revisão assistida por IA participou do processo.

O próximo passo é simples: audite seus workflows, reduza permissões, trate eventos públicos como entrada hostil e combine CodeQL, testes e revisão humana. Segurança de CI/CD é uma propriedade do fluxo inteiro, não apenas do código que aparece no pull request.