Rode um scan de segredo no seu repositório antes que um ex-prestador rode
Semana passada abri o histórico de um repositório que rodava fazia quase três anos e achei 23 segredos commitados. Seis ainda funcionavam: uma chave de AWS de 19 meses atrás, uma credencial de gateway de pagamento e uma URL de banco com senha em texto puro.
O detalhe que me marcou não foi o segredo em si. Foi que três pessoas que já tinham saído do projeto continuavam com acesso ao org do GitHub. Uma delas havia ido embora fazia oito meses.
Se você nunca fez essa varredura no seu projeto, aqui vai um mini-checklist pra rodar hoje:
- Scan no histórico do git (gitleaks ou trufflehog). Chave revertida no commit seguinte continua viva no histórico.
- Inventário de quem alcança o quê: GitHub org, console da AWS, integrações no Slack. Cruze com quem ainda está no projeto.
- Conta root compartilhada: se cinco pessoas usam a mesma senha de admin, você não tem auditoria, tem esperança.
- Segredo no código vira variável de ambiente + cofre (Secrets Manager, Vault, 1Password). E o scan entra no CI, pra chave nova nem chegar no main.
- Saída de pessoa vira checklist de revogação no mesmo dia.
O ponto contraintuitivo: reverter um commit com segredo não resolve nada. O git guarda o histórico inteiro, e quem clonou o repo tem a chave. A única saída é rotacionar o segredo na origem, não deletar o commit.
Um adendo honesto sobre o meu número: dos seis segredos "válidos", dois eram de sandbox — descobri só depois de rotacionar tudo. Mesmo assim, quatro chaves de produção vivas era quatro a mais do que deveria.
Versão completa, com o passo a passo de como a gente trata isso num diagnóstico, no blog: https://revin.com.br/pt/blog/seu-fornecedor-antigo-ainda-esta-logado-na-producao