Secrets Detection Engine

Philosophie

La détection de secrets est probabiliste : certains secrets sont plus faciles à trouver que d'autres. Il existe un compromis entre un faible nombre de fausses alertes et un faible nombre d'identifiants manqués (compromis précision/rappel)

Notre moteur de détection de secrets fonctionne en production depuis 2017, analysant des milliards de commits provenant de GitHub. Dès le premier jour, nous avons commencé à entraîner et à évaluer nos algorithmes par rapport au code open source. Cela a permis à GitGuardian de construire un moteur de détection de secrets indépendant du langage, intégrant très rapidement de nouveaux secrets ou de nouvelles façons de déclarer des secrets tout en conservant un très faible nombre de faux positifs. Nous recueillons également des retours à partir des alertes que nous envoyons, y compris les alertes pro bono :

• Un retour explicite lorsqu'un développeur ou une équipe de sécurité marque une alerte comme fausse alerte.
• Un retour implicite lorsqu'un développeur retire un dépôt public ou supprime un commit public quelques minutes après que nous ayons envoyé une alerte.

Nous mettons actuellement en œuvre deux types de détecteurs :

• Détecteurs spécifiques : nous implémentons un algorithme dédié à la recherche d'un type spécifique de secret comme les clés AWS, les URI Postgres ou les identifiants SMTP. Ce type de détecteur vise à obtenir un rappel et une précision élevés pour le type de secret ciblé. L'inconvénient de cette approche est que nous devons implémenter de nombreux détecteurs spécifiques pour couvrir correctement tous les secrets existants.

• Détecteurs génériques : le but de ces détecteurs est de capturer ce que nos détecteurs spécifiques manquent grâce à une approche générique. Nous implémenterons des détecteurs génériques capturant des motifs tels que secret=\{high_entropy_string\} ou password=xxx, email=yyy@corp.com. Nous pouvons ainsi obtenir un faible nombre de secrets manqués même si la précision de ces détecteurs est légèrement inférieure à celle des détecteurs spécifiques.

Vous pouvez bien sûr choisir les détecteurs que vous souhaitez autoriser ou refuser dans nos différentes applications web.

Fonctionnement

Notre moteur de détection de secrets prend en entrée un Document ayant pour paramètre une chaîne de caractères (un patch Git, un gist GitHub, un message Slack) et un paramètre facultatif qui est le nom de fichier (secrets.py, index.html, ...) Notez que ce moteur de détection peut utiliser le nom de fichier lorsqu'il est disponible dans une étape de pré-validation : par exemple, nous ne scannerons pas une image ou un fichier vidéo puisque personne n'y met de secrets.

Nous avons actuellement les listes d'exclusion suivantes en place :

1. Nous ne scannons pas les fichiers binaires tels que jpg, tar.*, ...
2. Nous excluons certains chemins de fichiers à l'aide des expressions régulières suivantes :

node_modules(/|\\)
vendors?(/|\\)
top-1000\.txt$
\.sops$
\.sops\.yaml$

3. Dans la plupart des cas, nous ne scannons pas les documents ayant les extensions suivantes car ils génèrent beaucoup de faux positifs et presque aucun véritable secret : ["html", "css", "md", "lock", "storyboard", "xib"]

Tao de notre moteur de détection de secrets

• 🎯 Précision élevée : nous voulons conserver un faible nombre de faux positifs pour éviter la fatigue liée aux alertes.
• 🔐 Rappel élevé : nous voulons conserver un faible nombre de secrets manqués pour assurer la sécurité de nos clients.
• ⚡ Rapidité : bien que la rapidité soit moins importante que le rappel et la précision, notre moteur de détection de secrets est conçu pour être rapide et scanner l'historique d'un dépôt Git courant en moins d'une minute.
• 👥 Piloté par la communauté et les clients : notre moteur est constamment entraîné et amélioré grâce aux retours de centaines de milliers de développeurs utilisant nos applications et aux retours de nos clients.

Fonctionnalités principales

Couverture étendue avec plus de 600 détecteurs spécifiques

Nous avons développé la plus vaste bibliothèque de détecteurs spécifiques, capable de détecter plus de 600 types de secrets différents (10 fois plus que la concurrence actuelle). Vous pouvez trouver la liste exhaustive ici.

Détection de secrets avec plusieurs correspondances et secrets multilignes

GitGuardian prend en charge la détection des secrets à plusieurs correspondances tels que les client_id et client_secret oauth, les identifiants de base de données, les identifiants SMTP...

GitGuardian prend en charge la détection des secrets multilignes tels que les clés privées.

Par exemple, nous sommes capables de détecter des clés AWS à partir de l'extrait suivant et la sortie comportera deux correspondances : une pour le client id et une pour le client secret.

input: 'id=AKIAFJKR45SAWSZ5XDF3, client_secret: hjshnk5ex5u34565d4654HJKGjhz545d89sjkjka'
output:
  client_id: AKIAFJKR45SAWSZ5XDF3
  client_secret: hjshnk5ex5u34565d4654HJKGjhz545d89sjkjka

Exemple pour des identifiants de base de données :

input: |
  dbusername = admin
  dbpassword = 8095uohoiw4ur90
  dbhost = db-postgres-nyc1-1111-do-user-111111-0.db.ondigitalocean.com
  dbport = 25060
  dbdatabase = defaultdb
  dbsslmode = require
output:
  username: admin
  password: 8095uohoiw4ur90
  host: db-postgres-nyc1-1111-do-user-111111-0.db.ondigitalocean.com
  port: 25060

Déduplication automatique

• Si deux détecteurs correspondent aux mêmes caractères et ont les mêmes correspondances, nous écartons la sortie des détecteurs apportant le moins d'informations.

Par exemple, le contenu suivant slack_token="xoxp-198947049743-7861195093-830655328819-9d40a979cac97bccf1190afb660b37e1" déclenche deux détecteurs : notre détecteur slack_user_token et notre détecteur capturant les secrets génériques (token={high_entropy_string}). Nous ne conservons que les résultats du détecteur slack_user_token afin de réduire la fatigue liée aux alertes et d'attacher le maximum d'informations pour aider au processus de remédiation.

Détection des secrets encodés en Base64 avec préfixe

Les frameworks récents comme Kubernetes utilisent des secrets encodés en Base64 et il devient assez courant de voir des secrets encodés en Base64. Nous sommes capables de détecter les secrets préfixés encodés en Base64 comme les clés privées.

Ajout d'informations aux secrets pour faciliter le travail des ingénieurs et analystes de sécurité

Nous attachons des informations aux secrets afin que les analystes de sécurité applicative puissent disposer de plus de contexte pour la remédiation. Actuellement, nous prenons en charge les informations suivantes :

• test_file : nous avons trouvé le secret dans un contexte de test (dossier de test, nom de fichier de test).
• sensitive_file : nous avons trouvé le secret dans un document dont le nom de fichier est considéré comme sensible (.env, credentials.json, ...).
• whitelisted : le secret a été mis en liste blanche par le développeur qui a écrit le code.
• decoded value for encoded secret : nous pouvons attacher la valeur décodée du secret à un secret encodé.

Limitations

1. Nous ne sommes pas capables de scanner les fichiers binaires (pour l'instant). Certains noms de fichiers binaires peuvent contenir des secrets, comme les fichiers .pyc en Python par exemple.
2. Par défaut, le nombre de secrets détectés par détecteur et par fichier est plafonné à 8. Pour les détecteurs à rappel élevé qui retournent généralement une seule correspondance par document, cette limite est portée à 50. Ces seuils aident à prévenir la fatigue liée aux alertes provenant de documents bruités, tout en gérant les fichiers qui contiennent légitimement de nombreux secrets (comme un fichier avec des dizaines de webhooks Slack). Nous recommandons toujours d'examiner l'intégralité du document lorsqu'un secret est détecté, car il peut contenir des informations sensibles supplémentaires qui n'ont pas été remontées.

Architecture

Notre moteur de détection de secrets repose sur la logique suivante :

Nous utilisons des PreValidators pour supprimer certains noms de fichiers apportant des faux positifs ou pour sélectionner un document en fonction de la présence d'un mot-clé. Par exemple, chaque SendGrid API key doit commencer par le préfixe SG., nous pouvons écarter tous les documents qui ne contiennent pas ce préfixe. Vous pouvez trouver plus d'informations sur les pré-validateurs ici.

Notre Scanner est un ensemble de détecteurs qui scanne un Document et produit des candidats Secret.

Nous utilisons ensuite des PostValidators pour valider si nos candidats secrets sont de véritables secrets. Nous configurons les PostValidators pour chaque Detector afin d'obtenir le meilleur compromis entre rappel et précision. Les règles de post-validation filtrent les faux positifs en :

• Filtrant les clés d'exemple
• Filtrant les secrets à faible entropie
• Filtrant les secrets contenant des sous-chaînes du dictionnaire anglais
• Utilisant des modèles de machine learning pour exclure les faux secrets en fonction du contexte

Vous pouvez trouver plus d'informations sur tous les PostValidators que nous utilisons et prenons en charge actuellement ici.