Scanner de secrets Betterleaks : architecture et clés
La détection des secrets dans les dépôts a considérablement évolué ces dernières années. Auparavant, il suffisait de rechercher des chaînes de caractères suspectes ou des clés à forte entropie dans le code. Aujourd'hui, la situation est différente : des dépôts plus volumineux, des pipelines CI/CD plus rapides et, surtout, une quantité croissante de code généré par des outils automatisés ou des modèles d'IA.
Cela a une conséquence pratique : le problème ne consiste plus seulement à trouver des secrets, mais à distinguer ce qui est réellement dangereux de ce qui ne l'est qu'en apparence. De nombreuses équipes constatent que le véritable coût de ces scanners réside non pas dans l'exécution de l'analyse, mais dans l'examen de centaines de faux positifs.
Architecture de détection : ce qui change avec Betterleaks
Betterleaks apparaît précisément dans ce contexte. Ce service ne prétend pas réinventer complètement la détection de secrets, mais il remet en question une idée reçue largement répandue : celle selon laquelle la détection de schémas suffit.
Ce n'est pas le cas dans de nombreux dépôts modernes.
Ce projet, développé par Zach Rice et maintenu avec le soutien d'Aikido, propose une approche légèrement différente. Au lieu de se concentrer uniquement sur la détection de correspondances, il cherche à vérifier la pertinence de la découverte avant de la transformer en alerte.
Cela peut paraître un détail, mais cela change radicalement la dynamique au sein des grandes équipes. Lorsqu'un système d'analyse génère trop d'alertes non pertinentes, l'équipe a naturellement tendance à les ignorer. Or, en matière de sécurité, une alerte ignorée peut être pire que l'absence d'alerte.
Pour résoudre ce problème, Betterleaks introduit deux éléments techniques intéressants : la validation à l’aide du CEL (Common Expression Language) et une métrique appelée « efficacité du jeton », basée sur la tokenisation BPE.
L'idée est que tout ce qui semble secret ne l'est pas forcément. Certaines chaînes de caractères à haute entropie ne sont que des hachages, des identifiants ou des fragments générés automatiquement. Le système vise à réduire ce bruit.
La documentation du projet mentionne une comparaison où la tokenisation BPE atteint un taux de rappel de 98,6 % contre 70,4 % pour l'entropie sur l'ensemble de données CredData. Comme pour tout test de performance, ces chiffres sont indicatifs. Ils constituent un bon point de référence, mais ne remplacent pas les tests sur des référentiels réels.
Source : GitHub
Les éléments qui font la différence
L’examen des caractéristiques du projet révèle une orientation claire : faciliter le déploiement dans des environnements réels sans ajouter trop de complexité technique.
Parmi les éléments les plus importants, on peut citer :
- Validation définie par des règles utilisant le CEL (Common Expression Language)
- Analyse de l'efficacité des jetons basée sur la tokenisation BPE plutôt que sur l'entropie, atteignant un rappel de 98,6 % contre 70,4 % avec l'entropie sur l'ensemble de données CredData
- Implémentation en Go pur (sans dépendance à CGO ou Hyperscan)
- Gestion automatique des secrets doublement/triplement chiffrés
- Règles élargies pour davantage de fournisseurs
- Analyse parallèle de Git pour une analyse plus rapide des dépôts
Bien que cette liste puisse sembler n'être qu'un ensemble d'améliorations techniques, ce qui est intéressant, c'est leur impact sur l'utilisation quotidienne.
Par exemple, une implémentation Go complète sans dépendances natives simplifie grandement l'intégration dans les pipelines CI/CD. Dans de nombreuses équipes, ce genre de petits détails détermine si un outil sera finalement utilisé ou relégué aux oubliettes d'un dépôt.
La tokenisation BPE introduit également une approche différente. Au lieu de simplement mesurer l'aléatoire d'une chaîne, elle analyse les modèles de jetons qui reflètent plus fidèlement la structure réelle des identifiants modernes.
Que se passe-t-il lorsque le scanner détecte quelque chose ?
Lorsque Betterleaks détecte un secret potentiel, le processus ne s'arrête pas là.
Tout d'abord, le contexte est évalué à l'aide de règles définies dans CEL. Cela permet d'ajouter des conditions supplémentaires : par exemple, vérifier si le format correspond au fournisseur attendu ou éliminer les modèles qui apparaissent fréquemment dans les exemples ou les données fictives.
Cette étape peut paraître anodine, mais elle a un impact pratique considérable. Les faux positifs ne font pas seulement perdre du temps, ils sapent également la confiance de l'équipe dans le système d'alerte.
Un autre aspect intéressant est la gestion automatique des secrets encodés plusieurs fois. Dans certains référentiels, les identifiants apparaissent transformés à l'aide de base64 ou d'autres schémas d'encodage, ce qui complique leur détection.
Il convient toutefois de rappeler un point parfois négligé : aucun système d’analyse ne peut remplacer entièrement la vérification humaine. Détecter un secret n’est que le point de départ ; décider de la marche à suivre (révoquer, faire évoluer, ignorer ou enquêter) dépend du contexte.
Gouvernance et approche centrée sur l'humain/IA
Betterleaks est publié sous licence MIT et bénéficie de contributions externes d'organisations telles que la Banque Royale du Canada, Red Hat et Amazon.
Le projet tente également de s'adapter à une réalité de plus en plus visible dans les dépôts modernes : le mélange de code écrit par les développeurs et de code généré par des outils automatisés.
Dans ce contexte, l'outil vise à fonctionner aussi bien dans les flux de travail manuels que dans les systèmes automatisés qui analysent des référentiels entiers. Cela correspond à l'utilisation croissante de automatisation et outils qui analysent le code ou génèrent des revues automatiques.
La feuille de route comprend également des idées intéressantes : l’intégration avec sources de données autres que GitAssistance par modèle de langage pour la classification des résultats et mécanismes de révocation automatique via les API du fournisseur.
Cela ouvre un débat intéressant. L'automatisation de la révocation des identifiants peut réduire le temps de réponse à un incident, mais elle implique également de s'appuyer sur l'exactitude du système de classification.
Si une révocation automatique échoue ou est déclenchée par erreur, l'impact opérationnel peut être considérable.
Implications pratiques et limitations
D'un point de vue opérationnel, Betterleaks est intéressant pour les équipes qui cherchent à réduire les faux positifs et à simplifier les déploiements.
Mais il est également important de garder certaines limites à l'esprit :
- Les indicateurs de rappel dépendent de l'ensemble de données utilisé et peuvent varier considérablement d'un référentiel à l'autre.
- L'automatisation d'actions telles que la révocation de clés nécessite des contrôles supplémentaires et des journaux d'audit.
- Les scanners secrets ne constituent qu'une couche de défense parmi d'autres au sein d'une stratégie plus large.
Dans de nombreux cas, la décision d'adopter un tel outil dépend moins de sa précision théorique que d'un critère plus simple : son intégration aisée dans le flux de travail de l'équipe.
Un scanner très précis générant trop de friction est généralement abandonné. Un scanner d'une précision raisonnable et facile à intégrer est généralement conservé.
En ce sens, Betterleaks cherche à trouver un juste milieu. L'entreprise ne promet pas d'éliminer tous les faux positifs ni de remplacer les processus de sécurité existants, mais elle vise à réduire le bruit et à faciliter l'intégration aux chaînes de traitement modernes.
Le projet est disponible sur GitHub et se présente comme une évolution de l'approche utilisée par Gitleaks, dans le but de s'adapter aux référentiels où l'automatisation, les agents d'analyse et le code généré par les modèles de langage font partie intégrante du flux de développement.
