Guia
Como escanear código gerado por IA em busca de segredos vazados
Escaneie o snapshot do repositório, verifique a exposição no frontend e revise o histórico do Git à parte. O que o vetkit detecta e o que fazer se uma credencial vazar.
· 5 min de leitura · Pela equipe do vetkit
Para escanear código gerado por IA em busca de segredos vazados, rode um scanner de segredos na versão do repositório que você pretende publicar, revise a evidência de arquivo e linha e revogue qualquer credencial exposta. No vetkit, o Security Quick Scan inclui a detecção de segredos no repositório; o histórico do Git e a exposição de chaves no navegador exigem verificações separadas. Um relatório limpo cobre apenas os arquivos e as verificações que de fato rodaram.
1. Escolha o escopo do scan
Código gerado pode conter uma credencial copiada, um placeholder realista ou código que só expõe uma chave quando você faz o build do app. São problemas diferentes. Decida de que evidência você precisa antes de interpretar o resultado:
| Pergunta | Verificação relevante | Limitação |
|---|---|---|
| Há uma credencial nos arquivos do repositório escaneado? | Segredos (gitleaks), incluído no Security Quick Scan | Detecção baseada em padrões no checkout, não uma prova de que nenhuma credencial está presente |
| Uma credencial foi apagada dos arquivos atuais, mas ficou nos commits? | O analisador separado secrets-history, quando disponível no escopo de auditoria selecionado | Histórico limitado; não faz parte do Quick Scan |
| A configuração de build pode expor uma chave de provedor ao navegador? | Verificações de apps com LLM para os padrões de código suportados, mais a sua própria inspeção do build | Não faz parte do Quick Scan; uma auditoria de código-fonte não inspeciona os assets em produção |
2. Escaneie a versão certa do repositório
- Conecte o repositório no vetkit e então selecione o Security Quick Scan ou um escopo de auditoria disponível que inclua detecção de segredos.
- Confirme o repositório e a ref de destino. Scans de repositórios remotos não enxergam buffers não salvos do editor nem arquivos locais que você não fez push. Não commite um segredo suspeito só para que ele possa ser escaneado.
- Aguarde a conclusão e verifique nos resultados dos analisadores se houve erros ou verificações puladas antes de ler os achados. Um scanner indisponível não é uma verificação aprovada.
Se você trabalha por meio de um assistente, o guia de MCP para Claude Code e Cursor explica como escolher um repositório e inspecionar os resultados da auditoria. Use placeholders nos prompts; nunca cole uma credencial real no assistente para perguntar se ela é válida.
3. Revise cada achado
Leia a regra, a severidade, o caminho do arquivo e a linha. Os achados de segredos do vetkit usam trechos mascarados; inspecione o código-fonte em privado para distinguir uma credencial real de dados de teste sintéticos. Padrões genéricos podem gerar falsos positivos, e formatos desconhecidos podem passar despercebidos. Uma correspondência por si só não mostra se a credencial ainda está ativa.
Priorize credenciais que dão acesso a recursos de nuvem, repositórios, publicação de pacotes ou dados de produção. Registre o serviço afetado e o responsável pela correção sem copiar o segredo para um ticket, uma captura de tela ou um chat. Não descarte um achado só porque o assistente chama o valor de exemplo.
4. Verifique a exposição no navegador e o histórico
Uma chave pode ficar fora do Git e mesmo assim chegar aos usuários por um build de frontend. Revise o uso de variáveis de ambiente públicas, as chamadas a SDKs de provedores e a configuração do bundler e então inspecione os assets gerados para o navegador em um ambiente sob o seu controle. Veja o guia sobre chaves de API no frontend para exemplos. O scan do repositório não faz automaticamente o build do seu app com os segredos de deploy nem examina os bundles do site no ar.
Se uma credencial pode ter sido commitada antes, inclua a verificação separada de histórico quando o seu escopo de auditoria permitir. A janela padrão dela é de no máximo 500 commits e pode ser menor quando o histórico do checkout é mais raso. Não é uma busca exaustiva em todas as branches, forks ou cópias do repositório.
5. Corrija e escaneie de novo
- Revogue ou rotacione a credencial exposta junto ao provedor. Apagar uma linha ou reescrever um commit não invalida uma chave que já foi copiada.
- Coloque a substituta em um cofre de segredos adequado no servidor ou no ambiente de execução. Garanta que ela não possa ser empacotada no código do navegador nem impressa nos logs.
- Revise os registros de acesso e de uso do provedor em busca de atividade inesperada. Coordene qualquer limpeza do histórico com os colaboradores do repositório; a rotação continua sendo necessária.
- Rode um novo scan na versão corrigida e repita as verificações de build ou de histórico pertinentes. Guarde a versão-alvo da auditoria junto com o registro da correção.
Fontes e limitações
Verificado em 1º de novembro de 2026 com base na configuração do Quick Scan do vetkit e nas implementações dos analisadores gitleaks, secrets-history e de apps com LLM. O Quick Scan executa posture, gitleaks e OSV; ele não inclui todos os analisadores de uma auditoria completa. A integração com o gitleaks pula, por padrão, arquivos maiores que 5 MB, e os scans estão sujeitos a limites de repositório, de arquivos e de tempo. Revise a cobertura e os avisos da execução real.
A documentação descreve o fluxo de auditoria, e o catálogo público de verificações documenta as regras próprias. Esse catálogo não é uma lista completa das assinaturas de terceiros do gitleaks. Este guia descreve etapas de detecção e correção; nem um scan limpo nem uma nota alta garantem que um app é seguro.