Pré-validateurs et post-validateurs

Un Detector comprend trois composants principaux :

• Pré-validateurs : règles appliquées avant le processus de détection. Elles déterminent si la détection doit continuer.
• Matchers : extracteurs de chaînes qui identifient et renvoient des correspondances (« matches »). En général ce sont des expressions régulières, mais ils peuvent être plus complexes (par ex. détection de chaînes de connexion).
• Post-validateurs : règles appliquées après les matchers. Elles valident les correspondances identifiées. Les post-validateurs peuvent s'appliquer à une seule correspondance ou à toutes celles trouvées par le matcher.

Pré-validation

Les pré-validateurs sont essentiels au processus de détection des secrets. Ils servent de filtre initial pour décider si une analyse plus poussée doit avoir lieu. Ils appliquent des règles et conditions avant la détection proprement dite, afin de vérifier que le document remplit certains critères : motifs dans le contenu, nom de fichier, chemin ou extensions, exclusion de fichiers JavaScript minifiés, etc. Les pré-validateurs optimisent le scan en se concentrant sur les documents pertinents.

Les pré-validateurs suivants sont utilisés par notre moteur :

• BanMinifiedPreValidator : exclut les fichiers JavaScript minifiés selon un seuil défini.
• ContentWhitelistPreValidator : renvoie vrai si le nom de fichier ou le contenu contient certains motifs.
• FilenameWhitelistPreValidator : renvoie vrai si le nom de fichier correspond à un nom ou une extension autorisés.
• FilenameBanlistPreValidator : renvoie faux si le nom de fichier correspond à un nom, chemin ou extension interdits.

Post-validation

Les post-validateurs jouent un rôle clé : ils valident et filtrent les correspondances identifiées par les matchers. Après les premières correspondances, ils appliquent des règles supplémentaires pour juger de la légitimité des secrets détectés : bannir des faux positifs courants, mesurer l'entropie, vérifier un nombre minimal de chiffres, appliquer des heuristiques, etc. Ils améliorent la précision et la fiabilité globale du moteur.

Les post-validateurs suivants sont utilisés :

• AssignmentBanlistPostValidator : écarte des correspondances selon le motif des variables d'affectation.
• CommonHostBanlistPostValidator : bannit des hôtes souvent associés à des faux positifs.
• CommonPasswordBanlistPostValidator : bannit des mots de passe de faux positifs courants.
• CommonUsernameBanlistPostValidator : bannit des noms d'utilisateur de faux positifs courants.
• CommonHighEntropyBanlistPostValidator : bannit des valeurs génériques ou placeholders à haute entropie.
• CommonValueBanlistPostValidator : bannit des valeurs génériques de faux positifs courants.
• DictFilterPostValidator : filtre les correspondances contenant des mots du dictionnaire courants.
• EntropyPostValidator : impose une entropie minimale sur la correspondance.
• HeuristicPostValidator : applique des heuristiques pour filtrer certains types de correspondances.
• MatchesPostValidator : applique des post-validateurs à un sous-ensemble de correspondances.
• MinimumDigitsPostValidator : vérifie un nombre minimal de chiffres dans les correspondances.
• ValueBanlistPostValidator : bannit des correspondances selon des motifs de valeur.
• ValueSimilarityPostValidator : bannit des groupes de correspondances dont la similarité dépasse un seuil.
• ContextWindowBanlistPostValidator : bannit des motifs de valeur dans une fenêtre autour de la chaîne correspondante.

Exemple

Prenons le détecteur Slack App Token. Il utilise un pré-validateur ContentWhitelistPreValidator qui recherche le préfixe xapp- dans les documents — occurrence rare, d'environ un document sur un million sur GitHub. Le pré-validateur élimine ainsi rapidement 99,9999 % des documents.

Voici des exemples de documents acceptés par le pré-validateur :

curl -X POST https://slack.com/api/chat.postMessage \
  -d '{"channel":"C12345678","text":"Hello, Slack!"}' \
  -H "Content-Type: application/json"  \
  -H "Authorization: Bearer xapp-1-XQ1QRVG5098-91645510917198-7bda3ae63ec19bcbc94c9907a52835cd47f8835e0a7553ffa3a494a4bd82e572"

bin/xfce4-set-wallpaper
include/xapp/libxapp/xapp-gtk-window.h

SLACK_APP_TOKEN="xapp-1-ABCDEFGHIJK-12345678901234-aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"

Parmi ces documents, le matcher identifie deux correspondances :

• xapp-1-XQ1QRVG5098-91645510917198-7bda3ae63ec19bcbc94c9907a52835cd47f8835e0a7553ffa3a494a4bd82e572
• xapp-1-ABCDEFGHIJK-12345678901234-aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Le détecteur Slack App Token utilise aussi un EntropyPostValidator, qui écarte la seconde correspondance en raison de sa faible entropie.

En conclusion, sur ces exemples, le détecteur n'identifie comme secret valide que : xapp-1-XQ1QRVG5098-91645510917198-7bda3ae63ec19bcbc94c9907a52835cd47f8835e0a7553ffa3a494a4bd82e572.