GitHub trava workflow suspeito antes da primeira linha rodar

O GitHub passou a exigir aprovação humana para determinadas execuções do Actions em repositórios públicos. Na prática, o workflow identificado como potencialmente malicioso fica parado. Antes disso, o alerta chegava depois do estrago.

A mudança nasce de um problema conhecido por quem mantém pipeline público. Credenciais vazam, alguém entra na conta e edita um arquivo em .github/workflows. Em seguida, a automação faz o resto do trabalho pelo invasor.

Por que um job vale mais que o código do repositório – GitHub

Pense no que seu pipeline alcança hoje. Ele roda testes, compila, gera releases, publica pacotes e conversa com nuvem. Ou seja, quem controla o workflow controla a esteira inteira de entrega.

Além disso, existe o material sensível guardado ali. O GITHUB_TOKEN nasce a cada job com permissões definidas por você. Junto dele aparecem secrets de registry, credenciais de deploy e chaves de serviços externos.

Um workflow adulterado com acesso a esse conjunto usa as credenciais fora do repositório afetado. Portanto, o dano raramente para no projeto de origem.

Como a aprovação funciona quando o GitHub segura a execução

O fluxo é simples de descrever. Primeiro, o GitHub interrompe a execução sinalizada. Depois, ela permanece pausada até revisão.

Quem aprova precisa ser colaborador com permissão de escrita. A confirmação acontece por sessão web autenticada. Enquanto a revisão estiver pendente, nada roda.

Aprovado, o job segue o caminho normal do Actions. Nenhuma configuração prévia é necessária, já que o GitHub aplica a proteção de forma automática. Vale registrar o limite de escopo: apenas repositórios públicos no GitHub.com, sem cobertura para GitHub Enterprise Server.

GitHub: O critério de detecção continua sendo uma caixa fechada

Aqui mora o ponto que incomoda time de plataforma. O GitHub não detalhou quais sinais levam um workflow a ser marcado como suspeito.

Consequentemente, você não consegue prever qual push vai parar na fila de revisão. Também não existe promessa de cobertura total. A empresa limita a proteção às execuções que seus próprios sistemas detectam.

Traduzindo para o dia a dia: essa camada soma, e sua responsabilidade permanece. Controle de acesso, revisão de código e permissão mínima seguem valendo igual.

O caso que mostrou como um token viaja longe

A OpenSSF documentou o encadeamento entre dois incidentes recentes. No primeiro, o código malicioso varreu a memória do runner em busca de secrets. Os resultados saíram expostos nos logs do workflow.

Entre os dados vazados estavam credenciais de uma conta de bot. Em seguida, essas credenciais abriram acesso a outro repositório, o da Action changed-files.

O detalhe que amplia o alcance é a tag. As alterações maliciosas foram associadas a versões já referenciadas por terceiros. Assim, quem apontava para aquela tag executou código adulterado sem tocar no próprio arquivo de workflow.

O que fazer no seu repositório GitHub ainda nesta semana

Comece pelo GITHUB_TOKEN. Declare permissões por job e conceda somente o necessário.

Depois, separe os mundos. Workflows que processam contribuição externa não deveriam ter escrita nem acesso a secrets. Nunca execute código de pull request não confiável em job privilegiado.

Em terceiro lugar, fixe Actions de terceiros em commit hash completo. O hash aponta para uma versão específica do código. Dessa forma, uma tag mutável redirecionada depois deixa de virar porta de entrada.

Por fim, restrinja quais Actions são permitidas no repositório e revise as permissões de cada job com calma.

npm entra na fila de verificação e seu deploy sente

O GitHub também ampliou controles em volta da cadeia de dependências. O Dependabot agora consome avisos de malware do repositório de pacotes maliciosos da OpenSSF, com cobertura extra em ecossistemas como npm e PyPI. Repositórios que já tinham o alerta de malware ativo recebem isso de forma automática.

Além disso, todo pacote novo publicado no npm passa por varredura antes de ficar disponível. O resultado define o destino: liberação normal, revisão manual ou bloqueio.

Atenção ao relógio, porque aqui a mudança quebra automação. O processo adiciona cerca de cinco minutos entre publicação e disponibilidade. Em pico, ou com pacotes grandes, o intervalo passa de quinze minutos.

Enquanto a verificação corre, operações que dependem da versão publicada ficam bloqueadas. É o caso de npm deprecate e npm unpublish. Logo, revise qualquer script de release que assuma disponibilidade imediata.

Pacote de segurança precisa se declarar antes de publicar

Existe uma categoria que sempre acende alarme falso em varredura automática. São os pacotes com função legítima de segurança que simulam comportamento malicioso.

Para esses casos, o npm criou uma exigência de transparência. O mantenedor declara o conteúdo de uso duplo pelo campo contentPolicy no package.json. Junto disso, entra um arquivo DISCLOSURE em texto puro descrevendo a funcionalidade e o uso pretendido.

A publicação precisa de método com autenticação de dois fatores. Valem publicação confiável via OpenID Connect, sessão interativa protegida ou o processo de publicação em etapas do npm.

Um alerta para as versões seguintes: campo e arquivo devem permanecer no pacote. O npm rejeitará releases que removam qualquer um dos dois, conforme a exigência avança.

O recado para quem mantém pipeline público

A revisão obrigatória muda o momento da defesa. Antes, o time descobria o incidente lendo log. Agora, o workflow espera por um humano.

Ainda assim, o trabalho de fundo continua com você. Permissão mínima, secrets bem escopados, Actions fixadas em hash e separação entre contribuição externa e publicação.

Comece hoje pelo pipeline que publica seus pacotes, porque ele carrega as credenciais mais caras do seu projeto.

Acompanhe nosso perfil no Instagram!