GitHub Actions: onde seu pipeline pode expor código e credenciais

Um pipeline é uma sequência automatizada que prepara e entrega software: instala dependências, executa testes e gera arquivos para distribuição, chamados artefatos, como um pacote ou uma aplicação compilada. Para fazer esse trabalho, pode acessar código privado, tokens de repositório e credenciais de outros sistemas.

Esse conjunto de permissões transforma a automação em uma parte sensível da operação. Durante o build, a preparação do software para distribuição, um comando pode ter acesso a muito mais do que os arquivos que precisa processar.

No GitHub Actions, um workflow descreve a automação em um arquivo YAML. Ele reúne jobs, grupos de etapas como instalar dependências e testar a aplicação. Cada job roda em um runner, a máquina que executa esses comandos.

A revisão de segurança deve acompanhar o caminho entre a entrada de código, os recursos disponíveis no runner e o que chega à publicação. No artigo sobre supply chain no npm, mostramos como dependências e automações podem se tornar pontos de entrada. Aqui, vamos aprofundar a parte que testa, constrói e distribui o software.

Um exemplo: testes de contribuições e publicação no mesmo fluxo

Neste exemplo hipotético, uma equipe recebe pull requests, propostas de alteração no código, e publica um pacote após aprovação. Uma contribuição externa muda um script executado durante a instalação das dependências.

Para avaliar a proposta, a automação baixa o código e instala essas dependências antes dos testes. Porém, o job também recebe um token capaz de publicar o pacote. Se o script alterado for malicioso, poderá tentar capturar ou usar essa credencial enquanto roda no runner.

A alteração nem precisa ser aprovada ou chegar à etapa formal de publicação para expor o token: basta que seu código seja executado no ambiente que o recebeu. Para a empresa, a consequência pode incluir suspender entregas, substituir credenciais e investigar quais versões ou recursos foram afetados.

O fluxo deve permitir testar a contribuição com os recursos necessários à validação e reservar a credencial de publicação para uma etapa controlada, que usa código aprovado. Essa separação precisa alcançar as máquinas e os arquivos que passam entre elas; dar nomes diferentes aos jobs não cria isolamento por si só.

Esse exemplo orienta a revisão: por quais caminhos o código de uma contribuição ainda em avaliação pode chegar a um ambiente capaz de publicar ou acessar recursos internos?

Configure o GITHUB_TOKEN para o trabalho de cada job

O GITHUB_TOKEN permite que o workflow interaja com o repositório. As permissões necessárias para ler o código são diferentes das usadas para publicar pacotes, criar releases (registros de versões publicadas) ou escrever em pull requests.

A documentação de autenticação do GitHub explica como configurar permissions no workflow ou por job. Uma action, componente reutilizável que realiza uma tarefa da automação, pode acessar esse token pelo contexto github.token, mesmo que ele não seja passado explicitamente como entrada.

Um job que apenas lê o código não precisa dos mesmos poderes de outro que cria uma release. Declare o acesso mínimo para cada tarefa e confira se as configurações da organização e do repositório permitem o que foi definido no YAML. Assim, uma falha na etapa de testes terá menos caminhos para alterar o projeto.

Esse controle se aplica ao GITHUB_TOKEN. No exemplo inicial, se a publicação usa um token pessoal, limitar o token do GitHub não resolve sua exposição. Chaves de deploy e credenciais de outros serviços também conservam as permissões que receberam fora desse ajuste.

Código de pull request exige um contexto adequado

O evento pull_request_target executa o workflow no contexto do repositório base. Isso permite automações como adicionar rótulos ou comentar em contribuições externas, mas exige cuidado com o que será processado.

É aqui que o fluxo do exemplo pode se tornar vulnerável: um workflow privilegiado busca o código da contribuição externa e instala suas dependências. O script alterado passa a rodar com os acessos daquele job. Testes e configurações carregadas por ferramentas também podem executar código, mesmo sem uma etapa explicitamente chamada de publicação.

A orientação específica do GitHub sobre pull_request_target detalha esse risco. Ela também descreve proteções de checkout e suas limitações: outras formas de buscar e executar código não ficam automaticamente cobertas.

O gatilho deve corresponder à tarefa. Use pull_request para testar contribuições que não precisam do contexto privilegiado. Quando uma automação exige permissões elevadas, defina quais dados ela recebe e como os processa, impedindo que uma entrada externa passe a determinar os comandos executados com essas credenciais.

O evento workflow_run, acionado por atividades de outro workflow, também exige esse cuidado. Um teste concluído pode deixar arquivos produzidos pela contribuição. Seu resultado não torna esses artefatos confiáveis para execução em uma etapa com credenciais.

Caches e artefatos podem atravessar fronteiras de confiança

Um cache guarda arquivos para reutilização em outras execuções e acelerar o build. Esses arquivos, porém, podem ser carregados e executados por ferramentas. Uma chave baseada no lockfile, o arquivo que registra as versões das dependências, ajuda a encontrar o cache correspondente; não comprova a integridade de seu conteúdo.

A documentação de caches do GitHub alerta que pull requests de forks, cópias do repositório usadas para desenvolver contribuições, podem acessar caches da branch base. Guardar uma credencial nesses caminhos pode expô-la a quem consegue ler esse cache.

A documentação atual também restringe, por padrão, a escrita no cache da branch padrão para certos gatilhos de menor confiança, como pull_request_target e workflow_run. Uma configuração explícita de cache-mode com escrita pode remover essa restrição.

O ponto de investigação é a relação entre quem produz os arquivos e quem os utiliza. Um cache criado por pull_request só pode ser restaurado em novas execuções daquele PR; ele não fica disponível para a branch base. Para identificar um risco real, é necessário conferir os gatilhos, o escopo e as configurações do fluxo.

No exemplo inicial, mover a publicação para outro workflow seria insuficiente se ele baixasse um script produzido pelo PR e o executasse com o token de publicação. A origem e o uso dos artefatos precisam fazer parte da separação entre teste e entrega.

OIDC reduz credenciais permanentes, mas precisa de isolamento

Quando a integração suporta OpenID Connect, o workflow pode apresentar sua identidade e obter credenciais temporárias, conforme a política do serviço de destino. Isso reduz a necessidade de guardar chaves permanentes no GitHub.

A documentação de OIDC do GitHub descreve a relação de confiança e a validação das informações do token.

A política do destino deve limitar quais repositórios, referências ou ambientes podem obter credenciais. No workflow, reserve id-token: write aos jobs que precisam solicitar o token. Essa permissão permite pedir a identidade OIDC; o serviço de destino ainda precisa aceitá-la e autorizar o acesso.

Trocar a chave permanente do exemplo por uma credencial temporária reduz a duração da exposição. Se o mesmo job continuar executando o script malicioso, porém, ele ainda poderá tentar usar a credencial enquanto ela estiver válida. O isolamento continua necessário.

Revise actions, scripts e runners

Uma action de terceiros traz código de outro projeto para o pipeline. Fixar sua referência em um SHA completo, o identificador de um commit, mantém a versão escolhida mesmo que uma tag seja movida. Essa fixação não comprova que o código seja seguro: a escolha ainda exige conhecer sua origem, o que faz e quais permissões utiliza.

Títulos de PRs e nomes de branches também merecem atenção. Se forem inseridos diretamente em um comando shell, usado para executar instruções no runner, caracteres dessa entrada podem alterar o comando. Passe essas informações como dados e trate adequadamente os parâmetros e as variáveis.

A referência de uso seguro do GitHub Actions reúne esses cuidados e alerta para a persistência de comprometimento em runners próprios.

Em runners próprios, mantidos pela equipe, o fim de um job não garante que a máquina esteja limpa. Arquivos deixados pelos testes, credenciais locais ou acesso à rede interna podem alcançar uma execução posterior. A reutilização entre projetos exige uma definição clara de limpeza, isolamento e recursos disponíveis em cada etapa.

Um checklist para revisar os workflows

1. Entradas: identifique os gatilhos, quem pode acioná-los e quais dados controla.
2. Permissões: confira GITHUB_TOKEN, credenciais externas e acesso a recursos internos por job.
3. Execução: localize scripts, dependências e configurações capazes de executar código da contribuição.
4. Transferências: revise origem, escopo e consumo de caches e artefatos.
5. Publicação: use código aprovado, credenciais limitadas e condições explícitas para liberar a versão.
6. Runners: verifique isolamento, limpeza e acesso à rede.
7. Registros: confira logs e artefatos para exposição de dados; o mascaramento de segredos não cobre todas as transformações possíveis.

Se houver suspeita de comprometimento, suspenda a publicação afetada, preserve evidências e investigue quais credenciais e artefatos ficaram expostos. Apenas repetir o build não resolve um acesso indevido já ocorrido.

Mantenha a revisão após mudanças nos workflows, preservando a fronteira entre contribuições em avaliação e operações autorizadas a distribuir software.

Como a Fidalgo IT Solutions pode ajudar

A Fidalgo IT Solutions pode apoiar a revisão de permissões, gatilhos, runners e integrações dos pipelines.

O trabalho pode incluir isolamento da publicação, controle de caches e artefatos e procedimentos de resposta, melhorando como o software é construído e entregue. Conheça nossa oferta de DevOps e automação de entregas ou converse com a Fidalgo sobre o fluxo que sua equipe utiliza hoje.