Detecção de Segredos… O que procurar ao escolher uma ferramenta

A primeira coisa que a maioria das pessoas faz quando experimenta uma ferramenta secrets é isto:

AWS_SECRET_KEY = "FAKEAWSSECRETKEY123456"
PASSWORD = "password123"‍

Eles executam a verificação, nada é sinalizado e a reação imediata é algo como:

Que ferramenta inútil. O meu cão poderia ter apanhado isso.

Parece tão óbvio. Certamente, encontrar secrets a parte mais fácil da segurança, certo? Basta procurar por password=, inserir algumas expressões regulares e pronto. Quão difícil pode ser?

E, de certa forma, tem razão. Encontrar sequências que parecem secrets fácil. Encontrar secrets reais secrets se perder em falsos positivos é que é difícil.

Vamos analisar por que os testes são mais difíceis do que parecem, por que as piores soluções muitas vezes parecem as melhores e como você deve realmente avaliar essas ferramentas.

Como funciona Secrets

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 uma estrutura definida. As chaves AWS são um exemplo clássico. Elas sempre começam com o mesmo prefixo e têm um comprimento fixo, portanto, uma expressão regular como esta irá identificá-las:

AKIA[0-9A-Z]{16}

É impressionante quando você vê ele sinalizar uma chave no código. Até você perceber que ele também sinaliza todos os placeholders que se parecem com uma.

AWS_ACCESS_KEY_ID="AKIA1234567890123456"

Não é tão mau para uma chave, mas introduza milhares de regras e rapidamente se torna muito ruidoso. Regex é útil, mas não consegue separar chaves reais das falsas e acaba por ficar com uma confusão frágil e ruidosa.

Filtragem com validação secreta

Uma das melhores formas de reduzir os falsos positivos é validar secrets a deteçã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ê terá uma chave ativa. Se falhar, você poderá reduzir o nível do alerta com segurança. 

Isso é ótimo porque você pode lançar uma rede muito ampla e refiná-la posteriormente. Mas há uma reviravolta. Quando você testa uma ferramenta, não está enviando chaves AWS reais para o GitHub. Você está usando chaves falsas. Uma ferramenta que valida chaves irá descartá-las como inválidas, mostrando zero resultados. Enquanto isso, a ferramenta mais preguiçosa que sinaliza tudo parece ter um desempenho melhor.

Filtragem com estatísticas de entropia

‍

Acho que aqui precisamos explicar rapidamente o que significa entropia. Strings de alta entropia referem-se a uma string com uma grande quantidade de aleatoriedade; mais aleatoriedade = mais entropia. 

‍

A maioria secrets ser validada, por isso as ferramentas recorrem a outros métodos para reduzir o ruído. As estatísticas de entropia são um dos mais eficazes.

A ideia é simples: secrets reais secrets aleatórios. Os espaços reservados, não. Considere esta chave Stripe falsa:

StripeKey = "SK_123456789"

Corresponde à expressão regular, mas não é suficientemente aleatório para ser real. Uma chave genuína tem uma entropia muito mais elevada, algo que os humanos têm muita dificuldade em falsificar.

 A filtragem de palavras em inglês também ajuda. Chaves API reais quase nunca contêm palavras legíveis. Se vir algo como:

TESTO823hufb934

pode ter quase a certeza de que se trata de um espaço reservado ou credencial de teste. Boas ferramentas irão rebaixar ou ignorar sequências de caracteres que misturam alta entropia com palavras óbvias do dicionário, como TEST, PASSWORD ou DEMO. Isso muitas vezes causa problemas nos testes, porque simular entropia é realmente muito difícil para um ser humano; naturalmente seguimos padrões quando digitamos, mesmo que não tenhamos consciência disso. 

Infelizmente, isso também nem sempre é tão simples, embora as chaves API sejam cadeias de caracteres de alta entropia. UUIDs, hashes e nomes de ficheiros também são cadeias de caracteres de alta entropia e não são secrets. É importante, então, introduzir também o contexto em torno do segredo. As melhores soluções combinam entropia, contexto e filtragem de palavras. Isso causa problemas nos testes, porque se você adicionar credenciais falsas que não se encaixam no conteúdo em que estão inseridas, elas também serão ignoradas. 

Por que as piores ferramentas parecem as melhores

Este é o paradoxo. As piores soluções, aquelas que simplesmente gritam a cada sequência suspeita, brilham em testes rápidos. Elas alegremente capturam as suas chaves e palavras-passe falsas. As ferramentas mais inteligentes parecem defeituosas porque ignoram silenciosamente as suas falsificações.

A menos que você teste com dados realistas, você acaba elogiando a ferramenta ruidosa e descartando aquela que realmente ajudaria na produção.

Como testar Secrets da maneira correta

Se quiser uma avaliação justa, precisa de dados de teste melhores.

Uma opção são os tokens honey. Serviços como o CanaryTokens permitem gerar credenciais inofensivas, mas realistas. Uma boa ferramenta deve detectá-las instantaneamente.

Outra abordagem é criar chaves reais sem permissões, executar os seus testes e revogá-las posteriormente. Isso fornece uma entrada segura, mas válida, que acionará a lógica de validação.

O melhor método, porém, é executar a ferramenta em bases de código reais. Secrets comuns em repositórios, especialmente no histórico de commits. A análise de projetos reais revela como uma ferramenta se comporta em condições realistas e fornece uma referência confiável.

O que torna uma ferramenta Secrets boa

Uma ferramenta eficaz secrets deve fazer tudo o seguinte:

1. Valide secrets possível
   Confirme secrets reais secrets chamadas de API seguras quando os fornecedores permitirem.
   
   
2. Suporte a padrões secretos específicos
   Detecte chaves estruturadas como AWS, Stripe e Twilio usando regras regex ou padrão.
   
   
3. Lide secrets genéricos secrets entropia e contexto
   Use pontuação de aleatoriedade e análise do código circundante para detectar secrets padrões fixos.
   
   
4. Filtre credenciais falsas ou de teste
   Rebaixe as chaves que contêm palavras óbvias do dicionário, como TEST ou PASSWORD.
   
   
5. Cubra uma ampla variedade de tipos de segredos
   Além de chaves API, inclua certificados, chaves SSH, senhas de bases de dados e muito mais.
   
   
6. Evite fugas antes que elas aconteçam
   Forneça ganchos pré-confirmação ou integrações IDE impedir secrets entrem no controlo de versão.
   
   
7. Escala em repositórios e pipelines
   Trabalhe de forma eficaz em CI/CD, em históricos e em escala empresarial.
   
   

Conclusão

Secrets parece simples, mas testá-la não é nada fácil. As ferramentas barulhentas que sinalizam todos os segredos falsos podem parecer impressionantes, enquanto as ferramentas mais inteligentes que validam e filtram parecem fazer menos.

Se quiser testar corretamente, use tokens de mel, chaves de acesso limitado ou repositórios reais. E ao avaliar, procure as qualidades que importam na produção: validação, deteção de padrões, análise de entropia, filtragem de dicionário, ampla cobertura e, acima de tudo, prevenção antes do commit.

Porque a chave AWS falsa que colocou para testar não é perigosa. A verdadeira, que está escondida à vista de todos, é que é perigosa.

‍