A primeira coisa que a maioria das pessoas faz ao experimentar uma ferramenta de detecção de segredos é esta:
AWS_SECRET_KEY = "FAKEAWSSECRETKEY123456"
PASSWORD = "password123"Eles executam o scan, nada é sinalizado, e a reação imediata é algo como:
“Que ferramenta inútil. Meu cachorro teria percebido isso.”
Parece tão óbvio. Certamente encontrar Secrets é a parte mais fácil da segurança, certo? Basta procurar por password=, adicionar algumas regexes e pronto. Quão difícil pode ser?
E, de certa forma, você está certo. Encontrar strings que se parecem com Secrets é fácil. Encontrar Secrets reais sem ser soterrado por falsos positivos é a parte difícil.
Vamos analisar por que o teste é mais difícil do que parece, por que as piores soluções muitas vezes parecem as melhores e como você deve realmente avaliar essas ferramentas.
Como a detecção de segredos funciona
Existem duas abordagens principais para detectar Secrets: correspondência de padrões baseada em regras e estatísticas de entropia.
A detecção baseada em regras depende de expressões regulares para identificar Secrets com uma estrutura definida. Chaves AWS são um exemplo clássico. Elas sempre começam com o mesmo prefixo e têm um comprimento fixo, então uma regex como esta as detectará:
AKIA[0-9A-Z]{16}
Parece poderoso quando você o vê sinalizar uma chave no código. Até você perceber que ele também sinaliza todo placeholder que se parece com uma.
AWS_ACCESS_KEY_ID="AKIA1234567890123456"
Não é tão ruim para uma chave, mas introduza milhares de regras e rapidamente gera muito ruído. Regex é útil, mas não consegue separar chaves reais de chaves fictícias e você acaba com um cenário frágil e com muito ruído.
Filtragem com Validação de Secrets
Uma das melhores formas de reduzir falsos positivos é validando Secrets após a detecção. Isso geralmente significa fazer uma chamada de API segura. Por exemplo, uma chave AWS pode ser testada com:
aws sts get-caller-identity --access-key <KEY> --secret-key <SECRET>
Se a chamada for bem-sucedida, você tem uma chave ativa. Se falhar, você pode rebaixar o alerta com segurança.
Isso é ótimo porque você pode lançar uma rede muito ampla e refiná-la depois. Mas aqui está a reviravolta. Quando você testa uma ferramenta, você não está enviando chaves AWS reais para o GitHub. Você está usando chaves falsas. Uma ferramenta que valida chaves as descartará como inválidas, mostrando zero resultados. Enquanto isso, a ferramenta mais "preguiçosa" que sinaliza tudo parece estar com um desempenho melhor.
Filtragem com Estatísticas de Entropia
Acho que aqui precisamos explicar rapidamente o que entropia significa. Strings de alta entropia se referem a uma string com uma grande quantidade de aleatoriedade; mais aleatoriedade = mais entropia.
A maioria dos Secrets não pode ser validada, então as ferramentas dependem de outros métodos para reduzir o ruído. Estatísticas de entropia são um dos mais eficazes.
A ideia é simples: Secrets reais parecem aleatórios. Placeholders não. Considere esta chave Stripe falsa:
StripeKey = "SK_123456789"
Corresponde à regex, mas não é aleatório o suficiente para ser real. Uma chave genuína tem uma entropia muito maior, algo que os humanos são péssimos em falsificar.
A filtragem de palavras em inglês também ajuda. Chaves de API reais quase nunca contêm palavras legíveis. Se você vir algo como:
TEST823hufb934
você pode ter certeza de que é um placeholder ou uma credencial de teste. Boas ferramentas irão rebaixar ou ignorar strings que misturam alta entropia com palavras óbvias de dicionário como TEST, PASSWORD ou DEMO. Isso frequentemente causa problemas em testes porque falsificar entropia é realmente muito difícil para um humano; nós naturalmente seguimos padrões quando digitamos, mesmo que não tenhamos consciência disso.
Infelizmente, isso nem sempre é tão direto, embora as chaves de API sejam strings de alta entropia. UUIDs, hashes e nomes de arquivos também são strings de alta entropia e não Secrets. É importante então introduzir contexto em torno do Secret. As melhores soluções combinam entropia, contexto e filtragem de palavras. Isso causa problemas em testes, no entanto, porque se você estiver adicionando credenciais falsas que não se encaixam no conteúdo em que estão, elas também serão ignoradas.
Por Que as Piores Ferramentas Parecem as Melhores
Este é o paradoxo. As piores soluções, aquelas que gritam a cada string suspeita, brilham em testes rápidos. Elas capturam alegremente suas chaves e senhas de teste. As ferramentas mais inteligentes parecem quebradas porque ignoram silenciosamente suas falsificações.
A menos que você teste com dados realistas, você acaba elogiando a ferramenta barulhenta e descartando aquela que realmente ajudaria em produção.
Como Testar a detecção de segredos da Maneira Certa
Se você quer uma avaliação justa, você precisa de dados de teste melhores.
Uma opção são os honey tokens. Serviços como CanaryTokens permitem gerar credenciais inofensivas, mas realistas. Uma boa ferramenta deve detectá-los instantaneamente.
Outra abordagem é criar chaves reais sem permissões, executar seus testes e revogá-las depois. Isso fornece uma entrada segura, mas válida, que acionará a lógica de validação.
O melhor método, no entanto, é executar a ferramenta em codebases reais. Secrets são comuns em repositórios, especialmente nas profundezas do histórico de commits. A varredura de projetos reais revela como uma ferramenta se comporta em condições realistas e fornece um benchmark confiável.
O Que Torna uma Boa Ferramenta de detecção de segredos
Uma ferramenta robusta de detecção de segredos deve fazer tudo o que se segue:
- Validar Secrets sempre que possível
Confirmar Secrets reais com chamadas de API seguras quando os provedores permitirem. - Suportar padrões de Secrets específicos
Detectar chaves estruturadas como AWS, Stripe e Twilio usando regex ou regras de padrão. - Lidar com Secrets genéricos usando entropia e contexto
Usar pontuação de aleatoriedade mais análise de código circundante para capturar Secrets sem padrões fixos. - Filtrar credenciais falsas ou de teste
Rebaixar chaves que contêm palavras óbvias de dicionário como TEST ou PASSWORD. - Cobrir uma ampla gama de tipos de Secrets
Além de chaves de API, incluir certificados, chaves SSH, senhas de banco de dados e muito mais. - Parar vazamentos antes que aconteçam
Fornecer pre-commit hooks ou integrações IDE para evitar que Secrets entrem no controle de versão. - Escalar em repositórios e pipelines
Funcionar eficazmente em CI/CD, através de históricos e em escala empresarial.
Conclusão
A detecção de segredos parece simples, mas testá-la é tudo menos isso. As ferramentas barulhentas que sinalizam cada Secret falso podem parecer impressionantes, enquanto as ferramentas mais inteligentes que validam e filtram parecem estar fazendo menos.
Se você quer testar adequadamente, use honey tokens, chaves de acesso limitado ou repositórios reais. E ao avaliar, procure as qualidades que importam em produção: validação, detecção de padrões, análise de entropia, filtragem por dicionário, ampla cobertura e, acima de tudo, prevenção antes do commit.
Porque a chave AWS falsa que você plantou para teste não é perigosa. A real, escondida à vista de todos, é.
