Resposta rápida
Desde 9 de novembro de 2026, o GitHub pode procurar segredos nos logs de novos workflows do Actions depois que cada execução termina. A função está em prévia pública, vem desativada e precisa ser habilitada pelo proprietário do enterprise em Policies, Advanced Security, Secret scanning for Actions workflow logs.
A cobertura exige GitHub Enterprise Cloud com GitHub Secret Protection ou GitHub Advanced Security e só alcança repositórios em que o secret scanning já está ativo. Durante a prévia, os alertas não enviam notificações: a equipe precisa abrir a lista de secret scanning do repositório e revisar os achados diretamente.
O que o GitHub passa a verificar
Quando um workflow novo termina, o GitHub examina seu log em busca de formatos conhecidos de provedores. Se o mesmo segredo aparecer em vários jobs ou execuções, um único alerta pode reunir várias localizações e apontar para o arquivo do workflow e para a linha do log em que o valor foi impresso.
O alerta não mostra uma prévia inline do conteúdo sensível. Para tipos compatíveis, o GitHub também pode executar uma verificação de validade e indicar se a credencial está ativa, inativa ou com estado desconhecido. Esse estado ajuda a priorizar, mas não substitui a revogação nem prova que não houve uso indevido.
Como ativar no enterprise
A política é centralizada e se aplica apenas aos repositórios elegíveis que já usam secret scanning. Antes de habilitar para todos, confirme licença, responsáveis pelos alertas e um processo de rotação; ativar detecção sem alguém acompanhando a fila cria visibilidade, mas não reduz sozinho o tempo de exposição.
- Abra as configurações do enterprise no GitHub Enterprise Cloud ou no domínio GHE.com com data residency.
- Selecione Policies e depois Advanced Security.
- Localize Secret scanning for Actions workflow logs.
- No menu All repositories, escolha Enabled.
- Confirme em um repositório piloto que secret scanning e a licença de segurança estão ativos.
- Execute um workflow de teste sem credencial real e revise Security and quality, Secret scanning após a conclusão.
Onde encontrar os alertas
Durante a prévia, não espere e-mail, notificação web ou aviso automático do alerta de log. Abra o repositório, entre em Security and quality e selecione Secret scanning. Use o detalhe do alerta para localizar o workflow, o job e a linha de origem, sem copiar o valor para tickets, chats ou novos logs.
Alertas continuam disponíveis mesmo depois que o log do workflow é excluído. Apagar a execução pode reduzir a exposição daquele artefato, mas não invalida a credencial e não encerra o alerta. Trate a rotação no provedor como a primeira ação de contenção.
Como responder a um segredo encontrado
Considere comprometida uma credencial real que foi impressa no log. Revogue ou gire no serviço emissor, atualize cada consumidor conhecido e procure uso suspeito nos registros do provedor. Só depois corrija o workflow e resolva o alerta com uma justificativa auditável.
- Identifique o provedor e o responsável pela credencial sem reproduzir o valor.
- Revogue ou rotacione o segredo no provedor e confirme que o valor antigo deixou de funcionar.
- Revise logs de acesso do serviço desde a primeira exposição conhecida.
- Atualize secrets, ambientes e integrações que dependiam da credencial antiga.
- Remova comandos, flags de debug ou actions que imprimiram o valor.
- Execute novamente o workflow, confira o alerta e registre a remediação antes de fechá-lo.
O que a prévia não detecta
A varredura de logs cobre apenas padrões de provedores. Padrões genéricos, padrões personalizados do enterprise, segredos detectados por IA e valores que o próprio GitHub Actions já mascarou no log ficam fora dessa análise. Logs de execuções anteriores à ativação também não são processados retroativamente.
Por isso, a ausência de alerta não demonstra que o log está limpo. Uma senha interna, uma connection string sem formato conhecido ou uma chave transformada pode continuar exposta. Para esses casos, revise a origem do workflow, minimize permissões e evite qualquer comando que imprima variáveis de ambiente ou respostas autenticadas.
Por que um segredo pode não aparecer
Se o recurso foi ativado depois da execução, rode novamente o workflow de teste: não há backfill. Se o repositório não tem secret scanning habilitado, não possui a licença exigida ou pertence fora do enterprise configurado, a política não o torna elegível. Se o valor está mascarado, usa padrão genérico ou personalizado, ou não corresponde a um provedor suportado, essa prévia não o detectará.
Quando vários repositórios deixam de processar workflows ou páginas de segurança ao mesmo tempo, consulte o GitHub Status antes de alterar permissões. Uma indisponibilidade do Actions ou do serviço de segurança exige diagnóstico diferente de uma política desabilitada ou de um padrão sem cobertura.
Como reduzir novos vazamentos em logs
Mantenha segredos no mecanismo próprio do Actions, conceda permissões mínimas e trate saída de ferramentas de terceiros como dado potencialmente sensível. Evite set -x, impressão de ambientes completos, respostas HTTP com headers e dumps de configuração em jobs que recebem credenciais.
- Revise os workflows por echo, printenv, env, set -x, curl -v e logs de debug de SDKs.
- Fixe actions de terceiros por commit e confira se elas registram entradas, headers ou contexto completo.
- Use ambientes separados e credenciais curtas para teste, homologação e produção.
- Restrinja o GITHUB_TOKEN e cada segredo somente aos jobs e permissões necessários.
- Associe a fila de secret scanning a um responsável e a um prazo de resposta documentado.
Limitações e próxima ação útil
Este guia foi verificado em 10 de novembro de 2026. A função está em prévia pública, pode mudar, depende de licença e não envia notificações para alertas de logs. Ela também não substitui push protection, regras de merge, padrões personalizados, revisão de actions ou monitoramento no provedor da credencial.
A próxima ação é escolher um repositório piloto, confirmar secret scanning, habilitar a política no enterprise e revisar a lista de alertas após um workflow concluído. Em paralelo, procure comandos de debug que imprimem contexto e documente quem revoga, gira, investiga e fecha cada alerta antes de ampliar para todos os repositórios.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- Secret scanning detects secrets in GitHub Actions workflow logsGitHub Changelog
- Secret scanningGitHub Docs
- Enforcing policies for code security and analysis for your enterpriseGitHub Docs
- Validity checksGitHub Docs
- Resolving alerts from secret scanningGitHub Docs
- GitHub StatusGitHub