Resposta rápida
Desde 9 de setembro de 2026, o GitHub oferece em prévia pública uma regra de ruleset que impede o merge de um pull request quando a análise do commit mais recente ainda não terminou ou quando os commits do pull request introduziram um alerta aberto de segredo.
A proteção se chama Require secret scanning alerts are resolved. Ela exige GitHub Secret Protection ou GitHub Advanced Security e secret scanning habilitado no repositório. A regra protege a entrada em branches selecionadas; ela não substitui a revogação imediata de uma chave que já apareceu no histórico.
O que a nova regra verifica antes do merge
O GitHub verifica se o secret scanning concluiu a análise do head commit e se não há alertas abertos, introduzidos pelos commits do pull request, que correspondam aos tipos de segredo configurados no ruleset. Sem permissão de bypass, a pessoa desenvolvedora precisa resolver esses alertas antes de concluir o merge.
Por padrão, a regra anunciada considera padrões de provedores, como formatos conhecidos de tokens e chaves. O administrador também pode selecionar padrões personalizados e genéricos. Segredos detectados por IA não são suportados por essa proteção durante a prévia pública.
Como ativar o bloqueio em um repositório
A configuração é feita em um branch ruleset, não em um push ruleset. Defina como alvo a branch que recebe os merges, normalmente a branch padrão, e mantenha a regra ativa depois de revisar quem pode ignorá-la.
- Confirme que GitHub Secret Protection ou GitHub Advanced Security e secret scanning estão habilitados no repositório.
- Abra Settings e, em Code and automation, acesse Rulesets e depois Rulesets.
- Crie ou edite um branch ruleset e selecione as branches que devem ser protegidas.
- Em Branch protections, marque Require secret scanning alerts are resolved.
- Selecione provider patterns e, se necessário, custom patterns e generic patterns.
- Revise a lista de bypass, coloque o ruleset como Active e salve.
Qual é a diferença para push protection
Push protection tenta impedir que um segredo alcance o repositório. Ela examina pushes pela linha de comando, commits e uploads feitos pela interface, chamadas da API REST e algumas interações com o GitHub MCP server. Quando encontra um padrão compatível, bloqueia o envio e orienta a remoção.
O novo ruleset atua em outra etapa: segura o merge do pull request. Essa camada pode capturar situações que a push protection não bloqueou ou não estava configurada para analisar, como padrões genéricos deixados fora da proteção de push. As duas medidas se complementam; habilitar uma não torna a outra desnecessária.
Como desbloquear o pull request com segurança
Abra o alerta em Security and quality e identifique o emissor da credencial. Revogue ou gire a chave no serviço de origem antes de qualquer outra correção. O GitHub orienta a rotação imediata porque apagar o texto do commit não impede o uso de uma credencial que já ficou exposta.
Depois, remova o valor do código, substitua-o por uma variável de ambiente ou secret gerenciado, envie a correção e resolva o alerta com a justificativa correspondente. O merge volta a ficar disponível quando todos os alertas abrangidos pelo ruleset estiverem resolvidos e a análise do head commit tiver terminado.
- Revogue ou rotacione a credencial no provedor que a emitiu.
- Remova o valor do código e das configurações versionadas.
- Armazene a nova credencial no mecanismo de secrets usado pelo ambiente.
- Envie um novo commit e aguarde a conclusão do secret scanning.
- Resolva o alerta somente depois de confirmar que a credencial antiga não funciona mais.
Por que o merge continua bloqueado
Se a interface mostra que a análise ainda está em andamento, aguarde o scan do head commit e confirme o estado do GitHub antes de alterar o ruleset. Se o alerta permanece aberto, abra os detalhes para localizar o commit e o tipo de segredo que ainda exige resolução.
Quando a opção não aparece nas configurações, verifique o plano, a habilitação de Secret Protection ou Advanced Security, o secret scanning e sua permissão para editar regras. Proprietários da organização, security managers e membros com função administrativa estão entre os perfis indicados pela documentação para configurar a proteção.
Configuração por API e uso em organizações
O anúncio informa que a regra também pode ser configurada pela API REST com o tipo require_secret_scanning_alert_resolution e um parâmetro secret_types, ou pelo GraphQL com REQUIRE_SECRET_SCANNING_ALERT_RESOLUTION. Em organizações, um ruleset pode ser direcionado a vários repositórios e branches.
Automatizar a configuração ajuda a manter a mesma barreira em muitos projetos, mas não elimine a revisão da lista de bypass. Uma exceção ampla permite que mudanças entrem na branch protegida sem resolver os alertas que o restante da equipe precisa corrigir.
Limitações verificadas
Este guia foi verificado em 10 de setembro de 2026 nas páginas oficiais do GitHub. A regra está em prévia pública, pode mudar e não cobre segredos detectados por IA. Também depende dos produtos de segurança e do secret scanning habilitados nos repositórios protegidos.
Um alerta indica que um valor se parece com uma credencial; não prova, sozinho, que houve uso indevido. Da mesma forma, resolver ou ignorar o alerta não invalida o segredo no provedor. Para uma credencial real, a ação segura continua sendo revogar, rotacionar e investigar acessos suspeitos.
Próxima ação útil
Abra o ruleset da branch padrão, ative a resolução obrigatória de alertas para provider patterns e revise cuidadosamente quem possui bypass. Em seguida, confirme a push protection e execute a avaliação de segredos da organização. Se a interface ou o scan estiver indisponível, consulte o GitHub Status antes de mudar proteções.
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.
- Block pull requests with exposed secrets from mergingGitHub Changelog
- Blocking pull request merges that contain secretsGitHub Docs
- Available rules for rulesetsGitHub Docs
- Secret scanningGitHub Docs
- Push protectionGitHub Docs
- About rulesetsGitHub Docs