GitHub secret scanning agora detecta segredos em logs do Actions (preview)

O GitHub anunciou em 9 de novembro de 2026, no GitHub Changelog, que o secret scanning passou a varrer os logs de execução do GitHub Actions, além de issues, wikis, discussions e pull requests. O recurso está em preview público e vale para empresas no GitHub Enterprise Cloud com GitHub Secret Protection ou GitHub Advanced Security, inclusive com residência de dados no GHE.com.

A política vem desligada por padrão. Para usar, o enterprise owner precisa ativar a opção manualmente. Como é preview, o comportamento ainda pode mudar, conforme a documentação do GitHub Enterprise Cloud.

O que o secret scanning cobria antes e o que entra agora

Antes dessa novidade, o secret scanning já cobria o histórico Git de todos os branches, além de issues, pull requests, discussions e wikis, segundo a página About secret scanning. O que entra agora são os logs de workflow do GitHub Actions.

O funcionamento é direto: quando uma execução de workflow termina, o GitHub varre o log dela em busca de padrões de provedores (os chamados provider patterns). Se encontrar algo, o achado vira um alerta na lista de secret scanning do repositório, junto dos alertas de código e de outros conteúdos.

Cada alerta traz um link de volta para o log do workflow onde o segredo apareceu. Para os tipos de segredo suportados, rodam também os validity checks.

E tem um detalhe importante: o alerta continua disponível mesmo depois que o log é apagado.

O recurso também aparece no roadmap público do GitHub como "Secret scanning detects secrets in Actions logs", marcado como Public Preview, na issue #1282 do github/roadmap.

Por que isso importa para quem roda agentes e scripts no CI

O log de CI é um lugar onde token vaza com facilidade, porque tudo que o job imprime fica registrado ali. Pense em cenários hipotéticos: um script com echo esquecido, uma ferramenta em modo debug ou um agente de IA rodando dentro do workflow podem, em tese, jogar uma credencial na saída sem ninguém perceber.

Até agora, esse canal ficava fora da varredura do secret scanning. Ou seja, o código podia estar limpinho e o vazamento acontecer justamente na execução.

Se liga no ponto da persistência: como o alerta sobrevive à exclusão do log, apagar o log não apaga o registro do vazamento. Isso ajuda na resposta ao incidente, porque o time continua sabendo o que vazou e onde, mesmo depois da limpeza.

Vale lembrar que apagar o log não resolve o problema em si. Na nossa avaliação, se o segredo foi exposto, o caminho mais prudente é tratar a credencial como comprometida, isso não está nas fontes oficiais do anúncio, é recomendação editorial.

Como ativar a varredura de logs do GitHub Actions

Quem ativa é o enterprise owner, pelas configurações da enterprise. O caminho confirmado no anúncio é este:

1. Abra as configurações da enterprise (Enterprise settings).
2. Selecione Policies e depois Advanced Security.
3. Na opção Secret scanning for Actions workflow logs, escolha Enabled no menu suspenso All repositories.

O erro comum aqui é esperar que a política cubra todos os repositórios automaticamente. Ela só se aplica a repositórios que já têm secret scanning habilitado sob as licenças de Secret Protection ou Advanced Security. Repositório sem secret scanning ativo continua fora.

Para checar se está funcionando, espere novas execuções de workflow terminarem e confira a lista de alertas de secret scanning do repositório. É ali que os achados dos logs aparecem.

Limitações do preview: o que a varredura não pega

Não há varredura retroativa. Só são varridas as execuções que terminam depois da ativação. Logs que já existiam não são processados.

Padrões genéricos e customizados ficam de fora. A varredura de logs do Actions trabalha só com provider patterns, então generic patterns e custom patterns não são detectados.

Segredos detectados por IA também não entram. A detecção baseada em IA do secret scanning não se aplica aos logs do Actions neste preview.

Valores já mascarados pelo Actions não geram alerta. Se o GitHub Actions já mascarou o valor no log, ele não é detectado pela varredura.

Não há notificações durante o preview. Alertas vindos de logs do Actions não disparam notificação, então é preciso consultar a lista de alertas de secret scanning do repositório diretamente.

O recurso pode mudar. Por estar em preview público, o comportamento está sujeito a alterações.

Próximo passo para o seu time

Se a sua empresa está no GitHub Enterprise Cloud com Secret Protection ou Advanced Security, o primeiro movimento é pedir ao enterprise owner que habilite a política. Sem isso, nada é varrido.

Depois, combine quem vai olhar a lista de alertas e com que frequência. Como não existe notificação no preview, alerta que ninguém abre é alerta perdido.

E não conte com os logs antigos: tudo que rodou antes da ativação continua fora da varredura.

Para detalhes de configuração e escopo, a referência é a documentação de secret scanning.

Veja mais exemplos práticos no canal Hora de Codar. Se quiser aprofundar o contexto, veja A Skill #1 Do GitHub Que Pesquisa A Internet Inteira Por Você (/last30days).