Neste artigo, abordaremos como entender e proteger fluxos de trabalho no GitHub Actions, desde o modelo de ameaças até mecanismos de controle de segurança. Em março de 2025, um popular GitHub Action, o tj-actions/changed-files, foi comprometido. De acordo com o GitHub Advisory Database, o incidente afetou mais de 23.000 repositórios. Os atacantes alteraram as tags de versão para que apontassem para um commit malicioso que vazava segredos de CI/CD para os logs do GitHub Actions. Em dezembro de 2024, o projeto ultralytics sofreu um ataque à cadeia de suprimentos (supply chain attack): invasores comprometeram o GitHub Actions workflow e o token da API PyPI, após o que versões maliciosas do pacote foram publicadas no PyPI. De acordo com o PyPI, os releases afetados 8.3.41, 8.3.42, 8.3.45 e 8.3.46 foram removidos; usuários também relataram que o wheel publicado executava um minerador XMRig.
Em março de 2026, o Trivy, um popular scanner de vulnerabilidades open source da Aqua Security, foi comprometido. De acordo com a análise final da Aqua, o acesso inicial foi obtido através de um workflow vulnerável com pull_request_target: o atacante roubou segredos em nível de organização e de repositório, e então usou o acesso para comprometer o Trivy e seus GitHub Actions associados. Todas as três histórias ilustram diferentes facetas de um mesmo problema: o GitHub Actions é frequentemente percebido como "apenas CI", quando na prática é um ambiente de execução de código completo com acesso a tokens, segredos, artefatos e dependências da cadeia de suprimentos. É por isso que erros em gatilhos, processamento de entrada do usuário e inclusão de actions de terceiros podem rapidamente se transformar em comprometimento de todo o pipeline. Na primeira parte, detalharei o modelo geral de segurança do GitHub Actions, discutirei erros típicos e como eles se manifestaram em ataques conhecidos. A segunda parte será dedicada ao cenário emergente de ameaças relacionadas a actions baseados em IA. Nela, expandirei o modelo de ameaças, discutirei riscos comuns e apresentarei minha própria abordagem para análise de segurança, com a qual foi possível descobrir novos riscos e vulnerabilidades.
Modelo de Ameaças para GitHub Actions
O GitHub Actions executa código em resposta a eventos no repositório. A principal questão de segurança aqui é: quem controla o código que é executado e com quais privilégios? Em repositórios públicos do GitHub, a fronteira de confiança é traçada entre: a zona confiável (proprietários do repositório, contribuidores do projeto, membros da organização, bots aprovados que podem fazer commits em main, acessar segredos de CI/CD, executar e modificar fluxos de trabalho) e a zona não confiável (espectadores, autores de pull requests de forks, criadores de issues, autores de comentários, bots externos e GitHub Apps que podem abrir pull requests de forks, criar issues, postar comentários e dar estrelas). Existem maneiras de cruzar as fronteiras de confiança, por exemplo, através de credenciais comprometidas de um mantenedor do projeto. Mas a tarefa clássica de segurança e o foco principal desta pesquisa é contornar a fronteira de confiança: um cenário em que um participante da zona não confiável obtém controle sobre a execução do código no contexto do repositório do GitHub Actions. Se um invasor conseguir cruzar ou contornar essas zonas de segurança, ele poderá controlar a execução do Action e usar o contexto disponível conforme a situação. Abaixo está um esquema útil de alto nível que ilustra os principais conceitos de segurança do GitHub Actions.
Conceitos Chave: Do Acesso Inicial às Consequências
O GitHub Actions permite que até mesmo participantes não confiáveis iniciem fluxos de trabalho através de várias ações, como: enviar um pull request de um fork com código e conteúdo arbitrários; comentar em issues e pull requests, tanto os próprios quanto os de terceiros; criar novas issues, discussões e muito mais. Este nível inicial de acesso, combinado com um erro de configuração do fluxo de trabalho e as potenciais consequências, como acesso a segredos, execução de código ou persistência em um runner auto-hospedado, além de commits maliciosos, cria uma vulnerabilidade. Na próxima seção, detalharemos os riscos e erros de configuração mais significativos, além de fornecer exemplos de ataques e incidentes decorrentes de tais vulnerabilidades.
pull_request_target e Outros Gatilhos Perigosos
O risco mais crítico e, ao mesmo tempo, frequentemente mal compreendido de CI/CD é o erro de configuração pull_request_target no GitHub Actions. À primeira vista, ele quase não difere do gatilho pull_request padrão, mas em termos de segurança, as consequências são significativamente diferentes: pull_request executa uma versão do fluxo de trabalho a partir do branch de origem do PR. Isso pode parecer perigoso, pois um atacante pode modificar o código do fluxo de trabalho em seu fork para executar comandos maliciosos. No entanto, o GitHub mitiga esse risco: tais fluxos de trabalho não recebem acesso a segredos, e seus privilégios são concedidos apenas para leitura. Além disso, no nível da organização, existe um mecanismo de controle de segurança chamado "Approval for running fork pull request workflows from contributors" (Aprovação manual para execução de workflows de pull request de forks) com três opções de configuração. Embora isso não seja uma proteção absoluta: invasores podem contorná-la se transformando em um contribuinte pela primeira vez com uma edição sintática trivial, como demonstrado por pesquisadores da Praetorian no caso de comprometimento do PyTorch – esse mecanismo torna o pull_request relativamente seguro. Em contraste, pull_request_target executa uma versão do fluxo de trabalho a partir do branch base, por exemplo, main. Como o próprio código do fluxo de trabalho não pode ser facilmente substituído pelo participante do projeto, o GitHub considera esse contexto "confiável". Portanto, este gatilho não possui verificações restritivas no nível da organização, mas tem acesso a segredos do repositório e privilégios de gravação por padrão. A ideia é que os mantenedores possam automatizar tarefas para pull requests de forks externos sem expor a lógica do fluxo de trabalho à substituição. O perigo surge no cenário clássico de modelagem de ameaças: um participante externo faz um fork do repositório para enviar um PR. Mesmo que o código do fluxo de trabalho não possa ser modificado, o autor do pull request pode influenciar a execução desse fluxo de trabalho através de artefatos obtidos durante o checkout (obtenção do código). O próximo exemplo mostra um padrão vulnerável clássico: um fluxo de trabalho com acesso a um segredo sensível extrai código de um fork e, em seguida, executa ações sobre ele. O código malicioso do atacante é executado com os segredos do repositório base. O actions/checkout@v4 com ref: ${{ github.event.pull_request.head.sha }} extrai o código do atacante. O some-action@v1 com api-key: ${{ secrets.API_KEY }} tem acesso ao segredo. O comando make build usa o código extraído. Como o comando make build usa o código extraído, o atacante obtém controle sobre a execução. Este padrão – uma combinação de pull_request_target com checkout do branch de origem do pull request – está na base da classe de ataques "Pwn Request".
Ataque
Esta configuração específica é um vetor de ataque conhecido. Isso foi demonstrado pelo recente comprometimento da cadeia de suprimentos do Trivy. O incidente começou com um workflow vulnerável, embora seus autores considerassem a configuração segura. Na prática, o fluxo de trabalho extraiu código controlado pelo atacante e, em seguida, executou-o através de um action escrito dentro do projeto. Ao substituir o código do action setup-go, o atacante conseguiu executar código e roubar um token de alto privilégio em nível de organização. A partir daí, o ataque se desenvolveu a partir desse ponto.
Proteção
Não existe uma estratégia única e definitiva de proteção contra erros de configuração ao usar pull_request_target. O conselho mais simples é não usá-lo. Ao mesmo tempo, deve-se reconhecer que essa abordagem nem sempre é prática, especialmente quando cenários automatizados precisam ser executados no código de um pull request. Nos casos em que pull_request_target é realmente necessário, as medidas de mitigação de risco devem incluir: desativar forks, executar o fluxo de trabalho apenas após verificação manual, recusar a execução de comandos arbitrários sobre o código obtido durante o checkout. Nenhuma dessas medidas é incondicionalmente confiável.
Outros Gatilhos Perigosos
pull_request_target é o gatilho perigoso mais discutido, e isso é merecido, dada sua ligação intrínseca com o código que ele executa e com o qual interage. No entanto, não é o único. Além de pull_request_target, existem outros sete gatilhos com as mesmas propriedades perigosas: não exigem privilégios de gravação no repositório para serem acionados; o fluxo de trabalho acionado é executado no contexto do branch principal, com acesso total a segredos e privilégios de gravação. A lista inclui oito gatilhos diferentes, agrupados por similaridade, bem como um vetor de ataque típico: Gatilho: pull_request_target, Vetor de Ataque: Conteúdo malicioso do PR. Gatilho: issues, issue_comment, Vetor de Ataque: Título/corpo/comentário malicioso da issue. Gatilho: discussion, discussion_comment, Vetor de Ataque: Discussão/comentário malicioso. Gatilho: fork, watch, Vetor de Ataque: Eventos de fork/estrela iniciados pelo atacante. Gatilho: workflow_run, Vetor de Ataque: Herda riscos do fluxo de trabalho pai. Por exemplo, um workflow que processa o conteúdo de uma issue e executa código embutido nele pode parecer um cenário improvável até que você se lembre de workflows baseados em IA, onde o conteúdo da issue é usado como entrada para o modelo. Este cenário será discutido na segunda parte. O gatilho workflow_run cria um risco separado: ele constrói uma cadeia a partir de outros fluxos de trabalho e consome seus resultados. Se um atacante puder influenciar os artefatos do fluxo de trabalho pai, ele poderá envenenar execuções subsequentes. Devido a grafos de dependência complexos, isso se torna uma fonte comum de erros de configuração.
Injeção de Script
Para aqueles familiarizados com ataques de injeção de comandos, o ataque de injeção de script, também conhecido como injeção de expressão (expression injection), será intuitivamente compreensível. Assim como um aplicativo web fornece campos de entrada (nome de usuário, senha, pesquisa), os workflows também aceitam parâmetros de entrada, como nomes de branches, títulos de issues, corpos de pull requests, etc. E assim como um aplicativo web pode ser vulnerável à injeção de comandos, um fluxo de trabalho pode ser vulnerável à injeção de script quando código malicioso é adicionado a um campo de entrada. Se um usuário de uma zona não confiável puder acionar um fluxo de trabalho com tais dados de entrada, ele obterá execução no contexto desse fluxo de trabalho. Um exemplo clássico desse ataque é um fluxo de trabalho que exibe o título de uma issue. Como visto, na primeira etapa, através de echo, o título da issue é exibido. Isso significa que uma carga útil maliciosa, semelhante à usada no incidente com tj-actions, executará este comando curl no contexto do runner onde a tarefa está sendo executada. Observe o truque com ${IFS}: este é um truque clássico para contornar WAF, que agora também é encontrado em cargas úteis de CI/CD.
Ataque
Em dezembro de 2024, a Ultralytics, organização por trás dos extremamente populares modelos de visão computacional YOLO, enfrentou um sério ataque à cadeia de suprimentos de software. Invasores comprometeram os releases do projeto no PyPI, infectando milhares de desenvolvedores e aplicações downstream com o minerador de criptomoedas XMRig. A causa raiz foi rastreada até uma configuração insegura dentro de um action composto personalizado usado no repositório ultralytics/actions. Assim como no exemplo acima, o fluxo de trabalho pegava dados de entrada controlados pelo usuário, especificamente o nome do branch Git (${{ github.head_ref }} ou ${{ github.ref }}), e os inseria diretamente em um bloco bash run sem limpeza prévia e sem mapeamento intermediário para uma variável de ambiente. O atacante se aproveitou disso, abrindo um pull request com um nome de branch malicioso. O atacante conseguiu roubar tokens do GitHub, roubar credenciais para publicar o projeto no PyPI e, como resultado, envenenar os pacotes lançados.
Proteção
A proteção contra injeção de comandos é construída principalmente de duas maneiras: vinculando dados de entrada a variáveis de ambiente: este é o método mais direto. Se uma variável de ambiente for acessada através da sintaxe padrão do shell, como "$MY_VAR", o shell interpretará automaticamente o conteúdo da variável como uma string comum. Limpeza de dados de entrada não confiáveis: dependendo do cenário de uso, até mesmo uma variável entre aspas pode ser transformada em uma arma. Nesses casos, os dados de entrada precisam ser limpos e verificados. Para isso, antes de executar o comando, é necessário garantir rigorosamente que a string de entrada corresponda a um padrão seguro, por exemplo, uma expressão regular com uma lista de valores permitidos: apenas letras, números e hifens em um shell como o bash.
Componentes de Terceiros do GitHub Actions Comprometidos
O GitHub Actions executa duas funções principais que são frequentemente confundidas: é simultaneamente um sistema CI/CD completo e um conjunto de blocos de construção reutilizáveis para fluxos de trabalho, comumente chamados de actions. O exemplo mais popular do segundo tipo é o action oficial actions/checkout, que é necessário para obter o código do repositório. Observamos isso em 100% dos ambientes de clientes da WizCode. Agora, imagine que este action seja comprometido. Isso levaria a consequências colossais para todo o ecossistema do GitHub Actions, pois nenhum fluxo de trabalho poderia mais ser considerado seguro. O ataque ao tj-actions no ano passado foi um alerta real sobre tais consequências.
Ataque
Em 15 de março de 2025, o action tj-actions/changed-files, que na época era usado em mais de 22.000 repositórios públicos, foi comprometido por um invasor. Durante a janela de ataque, os fluxos de trabalho afetados registraram inadvertidamente segredos codificados em base64 nos logs, levando a um vazamento de dados não autorizado em larga escala e publicamente visível. Embora o incidente público tenha sido amplamente divulgado, a investigação subsequente da Unit 42 mostrou que o objetivo inicial era a Coinbase, e o atacante realizou um ataque à cadeia de suprimentos de software, comprometendo sequencialmente quatro actions diferentes para atingir o objetivo final. Esta rede de actions comprometidos no ataque ao tj-actions demonstra o quão interconectados são os componentes reutilizáveis no GitHub Actions. Ela também destaca que mesmo fluxos de trabalho que são configurados de forma segura por si só podem se tornar vulneráveis devido às dependências em que se baseiam.
Proteção
A principal recomendação para proteção contra actions de terceiros comprometidos é fixar links para actions por SHA de commit. Embora isso nem sempre resolva o problema completamente, por exemplo, pode ser ineficaz para workflows reutilizáveis e actions aninhados, essa abordagem continua sendo a medida de proteção mais comum e conhecida. Para resumir: nesta parte, abordamos o nível básico – gatilhos perigosos, injeção de scripts e riscos da cadeia de suprimentos. Na segunda parte, surgirá uma variável que os modelos de ameaças tradicionais não levam em consideração: inteligência artificial, que pode ser manipulada através do próprio conteúdo para o qual se destina o processamento. Veremos como os actions oficiais da OpenAI, Anthropic e Google lidam com essa tarefa, onde eles ainda têm pontos fracos e o que descobri ao examinar seu código. Se o tema de segurança de CI/CD for relevante para suas tarefas, você pode continuar a discussão em aulas abertas relacionadas. Lá, conversaremos com especialistas práticos sobre incidentes, Bash e dívida de segurança acumulada – ou seja, sobre o que frequentemente transforma um erro em um workflow em um problema real. Em 26 de maio, às 20:00. "Os primeiros 60 minutos de um incidente de segurança: como um CISO age". Inscreva-se. Em 4 de junho, às 20:00. "Bash Avançado". Inscreva-se. Em 16 de junho, às 20:00. "Dívida Técnica de Segurança: O que consertar primeiro". Inscreva-se. A lista completa de aulas gratuitas de professores de cursos já está disponível no calendário de eventos.
