Bloqueie segredos antes do commit — o Push Protection evita a rotação

8 de outubro de 2026 às 03:00|Autor: Equipe editorial da QUASA|6 min de leitura

Para ativar o Push Protection no repositório, siga as instruções do GitHub para repositórios: abra Settings → Advanced Security, habilite Secret Protection se necessário e, na mesma seção, habilite Push protection. A proteção bloqueia o envio de segredos reconhecidos e cria um alerta quando alguém contorna o bloqueio do repositório.

Na interface web do GitHub, o bloqueio pode impedir a criação de um commit que contenha um segredo detectado. Pelo terminal, o commit já pode existir localmente: o Push Protection barra sua entrada no repositório remoto. Se o valor nunca foi exposto por outro caminho, removê-lo do histórico local antes de enviar evita a necessidade de trocar uma credencial por causa daquele push.

Habilite no repositório e entenda a cobertura

Proprietários do repositório ou da organização, gestores de segurança e usuários com função administrativa podem habilitar a configuração, conforme suas permissões. Se a opção não aparecer, confira o acesso da conta e se o repositório está sujeito a uma configuração de segurança administrada pela organização. Em repositórios privados ou internos de organizações, o acesso aos recursos depende do GitHub Secret Protection; em repositórios públicos, o Push Protection está disponível sem essa contratação.

Depois de habilitar a opção, confirme que ela aparece como ativa no repositório que receberá os pushes. Essa configuração protege os colaboradores desse destino e permite registrar alertas de bypass nele. O recurso examina padrões de segredos que consegue reconhecer; sua ativação, por si só, não garante a detecção de toda senha, chave interna ou versão antiga de token.

Aplique a regra à organização e confira a proteção pessoal

Para cobrir vários repositórios, entre em Settings da organização e abra Security → Advanced Security → Configurations. Crie ou edite uma configuração de segurança, defina Push protection como Enabled em Secret scanning, salve e aplique a configuração aos repositórios desejados. Confira a lista de repositórios abrangidos: salvar uma configuração sem aplicá-la não estende a proteção à equipe.

Na conta pessoal, abra a foto do perfil → Settings → Code security e procure Push protection for yourself na seção User. Essa proteção vem ativada por padrão para pushes da conta a repositórios públicos. Ela ajuda quando o repositório de destino não tem a própria proteção habilitada, mas um bypass feito somente pela proteção pessoal não cria um alerta de bypass no repositório. Para investigar exceções de forma centralizada, mantenha a configuração no repositório.

Teste com uma sequência fictícia

Um teste sem credencial ativa exige um repositório de teste elegível para padrões personalizados, com GitHub Secret Protection habilitado. Em Settings → Advanced Security → Secret Protection → Custom patterns, crie um padrão exclusivo para o ensaio. A documentação de padrões personalizados orienta a fornecer uma amostra, executar Save and dry run, publicar o padrão e habilitar Push protection para ele. Essa última opção só fica disponível após a publicação.

Como exemplo inteiramente fictício, use a expressão TESTE_PUSH_[A-Z0-9]{12} e a amostra TESTE_PUSH_ABCDEF123456. A sequência não deve autenticar nenhum serviço. Escolha um formato exclusivo para o repositório de teste, para evitar que texto comum de outros arquivos corresponda ao padrão.

Confirme que o padrão foi publicado, que seu Push protection está habilitado e que o repositório de teste está coberto pela proteção.
Em uma ramificação de teste, adicione a sequência fictícia a um arquivo, crie um commit local e tente enviar a ramificação. O resultado esperado é a recusa do push, com a localização do valor detectado.
Remova a sequência de todos os commits barrados antes de tentar novamente. Se ela entrou apenas no último commit, altere o arquivo e refaça esse commit com git commit --amend --all.

Um novo commit que apenas apaga a linha deixa o valor no commit anterior que também seria enviado. Se a sequência apareceu em commits mais antigos, será preciso corrigir esse histórico antes do push. O ensaio verifica o bloqueio do padrão criado; ele não mede a cobertura dos formatos de tokens de fornecedores.

Determine quem pode abrir uma exceção

Com bypass delegado, a equipe pode restringir quem autoriza o envio de um segredo detectado. Nas instruções para bypass delegado, o caminho no repositório é Settings → Advanced Security → Push protection → Who can bypass push protection for secret scanning → Specific roles or teams. Depois, use Add role or team para escolher os responsáveis. Se a organização já definiu o bypass centralmente, a configuração do repositório fica indisponível.

Para aplicar a política pela organização, edite uma configuração de segurança em Advanced Security → Configurations. Mantenha Push protection como Enabled, escolha Specific actors em Bypass privileges, selecione os atores, salve e aplique a configuração aos repositórios. Uma isenção completa faz os pushes daquele ator passarem sem o bloqueio; reserve-a para automações que realmente precisem desse tratamento e acompanhe seu alcance.

Ao avaliar um pedido, confirme se a string é um falso positivo ou uma credencial de teste sem acesso real e registre o motivo. Um segredo ativo não se torna seguro porque alguém escolheu corrigir depois. No repositório, um bypass por falso positivo ou uso em testes pode deixar um alerta já encerrado; um segredo real marcado para correção posterior permanece em aberto. Por isso, a revisão das exceções precisa incluir também os alertas encerrados e as notificações configuradas para os responsáveis.

Se uma chave real passou, revogue e substitua

Se uma credencial ativa entrou no repositório após um bypass, trate-a como exposta. Identifique o serviço emissor e o dono da chave, revogue a credencial antiga e gere uma substituta; atualize os sistemas que dependem dela. Quando a continuidade do serviço exigir uma troca coordenada, prepare a substituta antes da revogação, reduzindo ao mínimo o período em que a chave exposta continua válida.

Em seguida, examine o alerta, o motivo do bypass e os registros do serviço para avaliar onde a credencial apareceu e se houve uso indevido. Remova o valor do código e avalie, com os responsáveis pelo repositório, a limpeza do histórico e de outras cópias acessíveis. Apagar a linha em um commit posterior não invalida a chave nem elimina sua presença nos commits anteriores; a revogação é o passo que retira sua capacidade de acesso.