Do push ao alerta em minutos: fechando a janela do segredo commitado

Nos dois posts anteriores desta série, o problema foi ficando mais preciso. Primeiro a chave visível no bundle JavaScript, que qualquer visitante baixa. Depois a chave presa no histórico do Git, que git rm não remove e que só a rotação resolve.

Falta a variável que decide o tamanho do estrago: quanto tempo passa entre o commit e a descoberta.

A janela é o que determina o prejuízo

Um segredo commitado não é um estado, é uma corrida. De um lado, você descobrindo e revogando. Do outro, varredura automatizada encontrando e usando. O vazamento em si já aconteceu; o que ainda está em disputa é o intervalo.

E o intervalo depende inteiramente de como você procura. A ordem de grandeza, não os números exatos, é o que importa aqui:

A linha da fatura não é piada. Chave de LLM drenada é silenciosa por desenho: o app continua funcionando, nada quebra, nenhum erro aparece no log. O sintoma é financeiro, e chega no fim do ciclo.

Por que a auditoria completa não serve para isso

O caminho óbvio seria: chegou push, roda a auditoria inteira. É o que a maioria das plataformas faz, e tem um problema prático.

Uma auditoria de segurança completa são dezenas de checagens — cabeçalhos, TLS, DNS, cookies, portas, CVE, mais a parte pesada que clona o repositório e roda SAST em milhares de arquivos. Isso leva dezenas de minutos e ocupa uma fila que é, por necessidade, serializada. Um segredo commitado às nove da manhã podia ser avisado no dia seguinte — não por lentidão, mas porque estava atrás de trabalho legítimo de outros alvos.

A resposta que a gente implementou foi separar as duas coisas. O push passou a disparar também uma lane curta: uma ferramenta só, clone raso do commit que acabou de chegar, teto de tempo próprio, fila própria. Ela existe para responder uma pergunta única — entrou segredo neste push? — e responder rápido.

O que essa lane deliberadamente não faz

Aqui está a decisão de projeto que mais vale explicar, porque é contraintuitiva e é o tipo de coisa que separa um alerta confiável de um número inventado.

A lane curta não gera nota de segurança. Não cria relatório. Não altera o histórico de auditoria.

O motivo: ela roda uma ferramenta. Se o resultado dela virasse um run de auditoria, esse run diria "nota A" — porque as outras dezenas de checagens não rodaram, e o que não roda não tem como reprovar. Você receberia uma nota excelente calculada por alguém que olhou 2% do alvo. Um número desses é pior que número nenhum: ele passa confiança que não tem lastro, e ainda contamina a série histórica que você usa para provar evolução.

Então a divisão é explícita:

• A lane curta alerta. Emite um evento na linha do tempo, abre incidente, dispara notificação. É operação.
• A auditoria completa pontua. O achado formal, com severidade e peso na nota, nasce no próximo run completo. É medição.

O mesmo raciocínio vale para o silêncio. Quando a lane não acha nada, ela não manda "tudo certo" — um "nada encontrado" a cada push viraria ruído diário, e ruído diário treina o time a ignorar a notificação que importa. Mas quando a varredura falha (a ferramenta estourou o tempo, a saída veio ilegível), isso não é tratado como "nada encontrado": fica registrado. Varredura que não rodou não é varredura limpa — é a mesma regra do post anterior, aplicada aqui.

O que chega até você

O alerta nomeia o suficiente para você agir, e só isso:

• Qual regra disparou — o tipo da credencial (aws-access-token, stripe-api-key), que é o que decide em qual painel você vai revogar.
• Qual arquivo e qual commit foi varrido de verdade — não o commit que veio no webhook. Entre o push e o clone pode entrar outro commit, e nomear o do webhook faria o aviso apontar para algo que ninguém olhou.
• Quem foi o autor do commit.

E nunca o segredo. O payload do evento passa pela mesma máscara do resto do produto: no máximo quatro caracteres do começo, o fim nunca. Um alerta de vazamento que carrega a credencial dentro — por e-mail, por Slack, por webhook — é um segundo vazamento, com o agravante de estar num canal onde mais gente lê.

Repetição também é tratada: o mesmo conjunto de segredos dentro da janela de deduplicação não gera um segundo alerta. Cinco pushes na mesma tarde com a mesma chave não viram cinco notificações.

Não é substituto de hook de pre-commit — e nem tenta ser

Vale dizer com todas as letras, porque é a comparação natural: existem ferramentas que rodam na sua máquina, como hook de pre-commit, e impedem o commit de acontecer. Elas são úteis e a gente recomenda usar.

O Sentinela não faz isso, e não é omissão: é escopo. A gente não é ferramenta de estação de trabalho. O hook depende de cada pessoa instalar, manter e não pular com --no-verify; ele não vê o que o assistente de IA commitou direto pela integração do provedor, não vê o commit feito pela interface web do GitHub, e não vê o que já está no histórico desde antes de você instalar o hook.

As duas coisas cobrem janelas diferentes. O hook tenta impedir a entrada; a varredura do lado do servidor te avisa do que entrou de qualquer jeito — e é a única das duas que também olha o histórico inteiro e o que está publicado no seu site.

Onde isso encaixa no resto

O alerta de push não vive sozinho. Ele entra na mesma linha do tempo operacional onde caem os outros sinais do seu domínio — queda de uptime, certificado vencendo, mudança de DNS, deploy detectado — e vira incidente com o mesmo tratamento: notificação pelos canais que você já configurou (e-mail, Slack, Discord, Telegram, webhook), com a mesma deduplicação.

Isso importa mais do que parece na hora do incidente. Segredo vazado raramente é evento isolado: costuma vir junto de um deploy, e o que você quer é ver os dois lado a lado, na ordem em que aconteceram, para saber o que entrou junto.

A série inteira, em três linhas

• O que está publicado — a chave no bundle JS, visível a qualquer visitante. Post 1.
• O que está no repositório — a chave no histórico do Git, que remover não remove. Post 2.
• A velocidade — o tempo entre commitar e saber, que é o que decide o prejuízo. Este post.

São três lugares diferentes com um problema só. Cobrir dois deles e deixar o terceiro aberto é o padrão que a gente mais encontra em auditoria.

Como ligar

Os três estão no plano Business:

• Auditorias ilimitadas — audite a cada deploy, não quatro vezes por mês. É o que faz a varredura de bundle valer alguma coisa, já que o bundle muda a cada build.
• Conexão do repositório Git — Gitleaks no histórico, Semgrep, Trivy, Hadolint e análise dos workflows do GitHub Actions.
• Alerta de segredo por push — a lane curta deste post, ligada ao webhook do seu provedor.
• Histórico de 365 dias e até 5 pessoas na conta, para o achado e a correção ficarem provados no tempo.

Tudo isso olhando o seu site e o seu repositório de fora, sem agente instalado no servidor. Em real, com nota fiscal.

Ver planos e assinar o Business.