La première chose que la plupart des gens font lorsqu'ils essaient un outil de détection de secrets est la suivante :
AWS_SECRET_KEY = "FAKEAWSSECRETKEY123456"
PASSWORD = "password123"Ils lancent le scan, rien n'est signalé, et la réaction immédiate est quelque chose du genre :
« Quel outil inutile. Mon chien aurait pu le trouver. »
Cela semble si évident. Sûrement que trouver des secrets est la partie la plus facile de la sécurité, n'est-ce pas ? Il suffit de chercher « password= », d'ajouter quelques regex, et le tour est joué. À quel point cela peut-il être difficile ?
Et d'une certaine manière, vous avez raison. Trouver des chaînes qui ressemblent à des secrets est facile. Trouver de vrais secrets sans être noyé sous les faux positifs est la partie difficile.
Examinons pourquoi les tests sont plus difficiles qu'il n'y paraît, pourquoi les pires solutions ressemblent souvent aux meilleures, et comment vous devriez réellement évaluer ces outils.
Comment fonctionne la détection de secrets
Il existe deux approches principales pour la détection de secrets : la correspondance de motifs basée sur des règles et les statistiques d'entropie.
La détection basée sur des règles s'appuie sur des expressions régulières (regex) pour repérer les secrets ayant une structure définie. Les clés AWS en sont un exemple classique. Elles commencent toujours par le même préfixe et ont une longueur fixe, donc une regex comme celle-ci les détectera :
AKIA[0-9A-Z]{16}
On se sent puissant quand on le voit signaler une clé dans le code. Jusqu'à ce que l'on réalise qu'il signale également chaque placeholder qui y ressemble.
AWS_ACCESS_KEY_ID="AKIA1234567890123456"
Ce n'est pas si mal pour une seule clé, mais introduisez des milliers de règles et cela devient rapidement très bruyant. Les regex sont utiles, mais elles ne peuvent pas séparer les vraies clés des fausses, ce qui conduit à un système fragile et chaotique.
Filtrage par validation de secrets
L'un des meilleurs moyens de réduire les faux positifs est de valider les secrets après leur détection. Cela implique généralement d'effectuer un appel API sécurisé. Par exemple, une clé AWS peut être testée avec :
aws sts get-caller-identity --access-key <KEY> --secret-key <SECRET>
Si l'appel réussit, vous avez une clé active. S'il échoue, vous pouvez rétrograder l'alerte en toute sécurité.
C'est excellent, car cela permet de ratisser très large et d'affiner par la suite. Mais voici le hic : lorsque vous testez un outil, vous ne poussez pas de vraies clés AWS sur GitHub. Vous utilisez de fausses clés. Un outil qui valide les clés les rejettera comme invalides, vous affichant zéro résultat. Pendant ce temps, l'outil moins rigoureux qui signale tout semble plus performant.
Filtrage par statistiques d'entropie
Je suppose qu'ici, nous devons rapidement expliquer ce que signifie l'entropie. Les chaînes à haute entropie désignent une chaîne avec une grande quantité d'aléatoire ; plus d'aléatoire = plus d'entropie.
La plupart des secrets ne peuvent pas être validés, c'est pourquoi les outils s'appuient sur d'autres méthodes pour réduire le bruit. Les statistiques d'entropie sont l'une des plus efficaces.
L'idée est simple : les vrais secrets semblent aléatoires. Les placeholders non. Considérez cette fausse clé Stripe :
StripeKey = "SK_123456789"
Elle correspond à la regex, mais elle n'est pas assez aléatoire pour être réelle. Une clé authentique a une entropie beaucoup plus élevée, quelque chose que les humains ont beaucoup de mal à simuler.
Le filtrage par mots anglais aide également. Les vraies clés API ne contiennent presque jamais de mots lisibles. Si vous voyez quelque chose comme :
TEST823hufb934
vous pouvez être assez confiant qu'il s'agit d'un placeholder ou d'un identifiant de test. Les bons outils déclasseront ou ignoreront les chaînes qui mélangent une haute entropie avec des mots de dictionnaire évidents comme TEST, PASSWORD ou DEMO. Cela pose souvent des problèmes lors des tests, car simuler l'entropie est en fait très difficile pour un humain ; nous suivons naturellement des schémas lorsque nous tapons, même si nous n'en sommes pas conscients.
Malheureusement, ce n'est pas toujours aussi simple : bien que les clés API soient des chaînes à haute entropie, les UUID, les hachages et les noms de fichiers le sont aussi, sans être des secrets. Il est donc important d'introduire également du contexte autour du secret. Les meilleures solutions combinent l'entropie, le contexte et le filtrage par mots. Cela pose cependant des problèmes lors des tests, car si vous ajoutez de faux identifiants qui ne correspondent pas au contenu dans lequel ils se trouvent, ils seront également ignorés.
Pourquoi les pires outils semblent les meilleurs
C'est le paradoxe. Les pires solutions, celles qui alertent à la moindre chaîne de caractères suspecte, se distinguent lors des tests rapides. Elles détectent sans problème vos clés et mots de passe factices. Les outils plus intelligents semblent défectueux parce qu'ils ignorent discrètement vos faux positifs.
À moins de tester avec des données réalistes, vous finissez par louer l'outil bruyant et par rejeter celui qui serait réellement utile en production.
Comment bien tester la détection de secrets
Si vous voulez une évaluation juste, vous avez besoin de meilleures données de test.
Une option est l'utilisation de honey tokens. Des services comme CanaryTokens vous permettent de générer des identifiants inoffensifs mais réalistes. Un bon outil devrait les détecter instantanément.
Une autre approche consiste à créer de vraies clés sans permissions, à exécuter vos tests, puis à les révoquer. Cela vous fournit une entrée sûre mais valide qui déclenchera la logique de validation.
La meilleure méthode, cependant, est d'exécuter l'outil sur de véritables bases de code. Les secrets sont courants dans les dépôts, surtout en profondeur dans l'historique des commits. L'analyse de projets réels révèle comment un outil se comporte dans des conditions réalistes et vous fournit un benchmark fiable.
Qu'est-ce qui fait un bon outil de détection de secrets
Un bon outil de détection de secrets devrait faire tout ce qui suit :
- Valider les secrets lorsque c'est possible
Confirmer les secrets réels avec des appels API sécurisés lorsque les fournisseurs le permettent. - Prendre en charge des modèles de secrets spécifiques
Détecter les clés structurées comme celles d'AWS, Stripe et Twilio en utilisant des expressions régulières ou des règles de motifs. - Gérer les secrets génériques avec l'entropie et le contexte
Utiliser la notation de l'aléatoire et l'analyse du code environnant pour détecter les secrets sans motifs fixes. - Filtrer les identifiants factices ou de test
Déclasser les clés contenant des mots de dictionnaire évidents comme TEST ou PASSWORD. - Couvrir un large éventail de types de secrets
Au-delà des clés API, inclure les certificats, les clés SSH, les mots de passe de base de données, et plus encore. - Arrêter les fuites avant qu'elles ne se produisent
Fournir des hooks de pré-commit ou des intégrations IDE pour empêcher les secrets d'entrer dans le contrôle de version. - Mettre à l'échelle sur les dépôts et les pipelines
Fonctionner efficacement en CI/CD, à travers les historiques, et à l'échelle de l'entreprise.
Pour conclure
La détection de secrets semble simple, mais la tester est tout sauf cela. Les outils bruyants qui signalent chaque faux secret peuvent sembler impressionnants, tandis que les outils plus intelligents qui valident et filtrent donnent l'impression d'en faire moins.
Si vous voulez tester correctement, utilisez des honey tokens, des clés à accès limité ou de vrais dépôts. Et lors de l'évaluation, recherchez les qualités qui comptent en production : la validation, la détection de motifs, l'analyse d'entropie, le filtrage par dictionnaire, une large couverture, et surtout, la prévention avant le commit.
Car la fausse clé AWS que vous avez placée pour les tests n'est pas dangereuse. C'est la vraie, cachée à la vue de tous, qui l'est.
