La première chose que font la plupart des gens lorsqu'ils essaient un détection de secrets est la suivante :
AWS_SECRET_KEY = « FAKEAWSSECRETKEY123456 »
PASSWORD = « password123 »Ils lancent l'analyse, rien n'est signalé, et la réaction immédiate est quelque chose comme :
« Quel outil inutile. Mon chien aurait pu attraper ça. »
Cela semble tellement évident. Trouver des secrets est sûrement la partie la plus facile de la sécurité, n'est-ce pas ? Il suffit de rechercher password=, d'ajouter quelques expressions régulières, et le tour est joué. Est-ce vraiment si 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 submergé par les faux positifs, voilà qui est difficile.
Voyons pourquoi les tests sont plus difficiles qu'il n'y paraît, pourquoi les pires solutions semblent souvent être les meilleures et comment vous devriez réellement évaluer ces outils.
Comment détection de secrets
Il existe deux approches principales pour détecter les secrets : la correspondance de modèles 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 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 expression régulière comme celle-ci permettra de les détecter :
AKIA[0-9A-Z]{16}
C'est impressionnant quand on voit qu'il signale une clé dans le code. Jusqu'à ce qu'on se rende compte qu'il signale également tous les espaces réservés qui y ressemblent.
AWS_ACCESS_KEY_ID="AKIA1234567890123456"
Ce n'est pas si grave pour une seule clé, mais introduisez des milliers de règles et cela devient rapidement très bruyant. Regex est utile, mais il ne peut pas séparer les clés réelles des clés factices et vous vous retrouvez avec un désordre fragile et bruyant.
Filtrage avec validation secrète
L'un des meilleurs moyens de réduire les faux positifs consiste à 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 à l'aide de :
aws sts get-caller-identity --access-key <KEY> --secret-key <SECRET>
Si l'appel aboutit, vous disposez d'une clé active. S'il échoue, vous pouvez sans risque réduire le niveau d'alerte.
C'est formidable, car vous pouvez ratisser très large et affiner ensuite vos recherches. Mais voici le hic. Lorsque vous testez un outil, vous n'envoyez pas de véritables clés AWS à GitHub. Vous utilisez des clés factices. Un outil qui valide les clés les rejettera comme non valides, ne vous affichant aucun résultat. En revanche, l'outil plus paresseux qui signale tout semble plus performant.
Filtrage à l'aide des statistiques d'entropie
Je pense qu'il faut ici expliquer rapidement ce que signifie l'entropie. Les chaînes à haute entropie désignent des chaînes présentant un degré élevé d'aléatoire ; plus d'aléatoire = plus d'entropie.
La plupart des secrets ne peuvent pas être validés, les outils s'appuient donc 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 espaces réservés ne le sont pas. Prenons l'exemple de cette fausse clé Stripe :
StripeKey = « SK_123456789 »
Elle correspond à l'expression régulière, mais elle n'est pas suffisamment aléatoire pour être réelle. Une clé authentique a une entropie beaucoup plus élevée, ce que les humains ont beaucoup de mal à simuler.
Le filtrage des mots anglais est également utile. Les clés API réelles ne contiennent presque jamais de mots lisibles. Si vous voyez quelque chose comme :
TEST823hufb934
vous pouvez être presque certain qu'il s'agit d'un espace réservé ou d'identifiants de test. Les bons outils vont déclasser ou ignorer les chaînes qui mélangent une entropie élevée avec des mots évidents du dictionnaire tels que TEST, MOT DE PASSE ou DÉMO. Cela pose souvent des problèmes lors des tests, car il est en réalité très difficile pour un être humain de simuler l'entropie ; nous suivons naturellement des schémas lorsque nous tapons, même si nous n'en sommes pas conscients.
Malheureusement, cela n'est pas toujours aussi simple, car les clés API sont des chaînes à haute entropie. Les UUID, les hachages et les noms de fichiers sont également des chaînes à haute entropie et ne constituent pas des secrets. Il est donc important d'introduire également un contexte autour du secret. Les meilleures solutions combinent entropie, contexte et filtrage des mots. Cela pose toutefois des problèmes lors des tests, car si vous ajoutez de fausses informations d'identification qui ne correspondent pas au contenu dans lequel elles se trouvent, elles seront également ignorées.
Pourquoi les pires outils semblent les meilleurs
C'est là tout le paradoxe. Les pires solutions, celles qui réagissent violemment à chaque chaîne suspecte, brillent dans les tests rapides. Elles détectent facilement vos clés et mots de passe factices. Les outils plus intelligents semblent défaillants, car ils ignorent discrètement vos faux éléments.
Si vous ne testez pas avec des données réalistes, vous finirez par louer l'outil bruyant et rejeter celui qui serait réellement utile en production.
Comment tester détection de secrets
Si vous voulez une évaluation équitable, vous avez besoin de meilleures données de test.
Une option consiste à utiliser des jetons miel. Des services tels que 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 autorisations, à exécuter vos tests, puis à les révoquer par la suite. Cela vous donne une entrée sûre mais valide qui déclenchera la logique de validation.
La meilleure méthode consiste toutefois à exécuter l'outil sur des bases de code réelles. Les secrets sont courants dans les référentiels, en particulier dans les profondeurs de l'historique des commits. L'analyse de projets réels révèle le comportement d'un outil dans des conditions réalistes et vous fournit un benchmark fiable.
Qu'est-ce qui fait un bon détection de secrets ?
détection de secrets efficace détection de secrets doit remplir toutes les conditions suivantes :
- Validez les secrets lorsque cela est possible
Confirmez les secrets réels à l'aide d'appels API sécurisés lorsque les fournisseurs le permettent. - Prise en charge de modèles secrets spécifiques
Détectez les clés structurées telles que AWS, Stripe et Twilio à l'aide de règles d'expression régulière ou de modèles. - Traitez les secrets génériques avec entropie et dans leur contexte
Utilisez la notation aléatoire et l'analyse du code environnant pour détecter les secrets sans modèles fixes. - Filtrez les identifiants faux ou de test
Dégradez les clés contenant des mots évidents du dictionnaire tels que TEST ou PASSWORD. - Couvrez un large éventail de types de secrets
Au-delà des clés API, incluez les certificats, les clés SSH, les mots de passe de base de données, etc. - Empêchez les fuites avant qu'elles ne se produisent
Fournissez des hooks pré-commit ou intégrations IDE empêcher les secrets d'entrer dans le contrôle de version. - Évoluez à travers les référentiels et les pipelines
Travaillez efficacement dans CI/CD, à travers les historiques et à l'échelle de l'entreprise.
Conclusion
détection de secrets simple, mais la tester est tout sauf simple. Les outils bruyants qui signalent chaque faux secret peuvent sembler impressionnants, tandis que les outils plus intelligents qui valident et filtrent semblent moins performants.
Si vous souhaitez effectuer des tests corrects, utilisez des jetons fictifs, des clés d'accès limitées ou de véritables référentiels. Et lors de l'évaluation, recherchez les qualités qui importent en production : validation, détection de modèles, analyse d'entropie, filtrage de dictionnaire, large couverture et, surtout, prévention avant validation.
Parce que la fausse clé AWS que vous avez placée à des fins de test n'est pas dangereuse. La vraie, qui se cache à la vue de tous, l'est.
Sécurisez votre logiciel dès maintenant.
.avif)
