GitHub agora bloqueia merge de pull request com segredo exposto

A regra nova atua uma camada depois, no momento do merge. Ela existe justamente para pegar os casos que a push protection não pegou ou não estava configurada para pegar. O exemplo que o GitHub dá é o cenário mais realista de todos: um time pode manter a push protection desligada para segredos de generic pattern (que geram falso positivo com frequência e travariam pushes legítimos), mas ainda assim manter um ruleset que bloqueia o merge desses mesmos tipos de segredo. Você troca a fricção do push (que atinge o dev individual, a toda hora) pela fricção do merge (que acontece uma vez, com o revisor por perto).

Em resumo, as duas ferramentas resolvem o mesmo problema em pontos diferentes do ciclo de vida do código:

A leitura que faço: elas não competem, se empilham. Push protection é a primeira linha; a regra de merge é a rede de segurança para o que passou por baixo dela.

Como configurar

O caminho pela interface é o mesmo de qualquer ruleset. Nas configurações do repositório, da organização ou da enterprise, vá em Repository > Rulesets, crie ou edite um ruleset mirando as branches que você quer proteger e marque Require secret scanning alerts are resolved.

Para quem prefere gerir isso como código (o caminho que eu seguiria em qualquer org com mais de um punhado de repositórios), dá para usar o REST API com o tipo de regra require_secret_scanning_alert_resolution e um parâmetro secret_types para controlar quais categorias entram no bloqueio. Um recorte conceitual de um ruleset com essa regra fica assim:

{
  "type": "require_secret_scanning_alert_resolution",
  "parameters": {
    "secret_types": ["provider", "custom", "generic"]
  }
}

Gerir ruleset por API é o que torna essa proteção escalável: você aplica a mesma política a centenas de repositórios de uma vez, no nível da organização ou da enterprise, em vez de depender de cada time lembrar de ligar o botão. Esse, aliás, é o ponto central de rulesets desde que substituíram os branch protection rules antigos.

O que muda na prática (e onde ela não resolve nada)

Para o time brasileiro que trata o PR como o portão de qualidade antes da produção, essa regra fecha uma brecha concreta: até então, o secret scanning te avisava do vazamento, mas não impedia o merge por si só. Você dependia de um check obrigatório configurado à mão ou da disciplina do revisor. Agora o bloqueio é nativo do ruleset, no mesmo lugar onde você já exige status checks, aprovações e linear history.

Mas vale ser honesto sobre os limites, porque nenhuma dessas ferramentas é bala de prata:

• O segredo já vazou. Se a push protection estava desligada, a credencial já está no branch do PR e no histórico do Git. Bloquear o merge não desvaza nada. Resolver o alerta significa, obrigatoriamente, rotacionar a credencial e limpar o histórico. Um segredo que ficou exposto num branch público por algumas horas deve ser considerado comprometido, ponto.
• É pago. Sem Secret Protection ou Advanced Security, essa regra não existe para você. Times em plano free continuam dependendo do secret scanning básico e de disciplina de processo.
• Bypass é uma faca de dois gumes. Quem tem permissão de bypass fura o bloqueio. Bem usado, é o escape hatch para emergências; mal governado, vira o furo por onde todo mundo passa. Vale auditar quem tem esse poder.
• Está em public preview. Comportamento e nomenclatura podem mudar antes do GA, então trate como algo para testar em repositórios não críticos primeiro.

O GitHub aponta a documentação de secret scanning e push protection e a de rulesets para os detalhes de aplicação e bypass. Para quem já vive dentro do ecossistema Advanced Security, ligar essa regra num ruleset de organização é ganho fácil. Para quem não tem, o recado indireto é o de sempre: o segredo mais seguro é o que nunca foi commitado, e isso continua sendo problema de processo (variáveis de ambiente, secret managers, .gitignore bem-feito), não só de ferramenta.

Fonte: GitHub Changelog