Secret scanning open source en 2026 : six scanners testés sur un dépôt truffé de faux secrets

Quels scanners de secrets open source sont encore maintenus en 2026 ?

Sur les onze scanners de secrets open source que nous avons vérifiés le 29 octobre 2026, six ont publié une version en 2026 : Betterleaks, Gitleaks, TruffleHog, Kingfisher, Titus et secretlint. Nosey Parker est archivé, et detect-secrets comme git-secrets n'ont rien publié depuis plus de deux ans. Le tableau reprend ce que l'API de GitHub et le README de chaque projet indiquaient ce jour-là : la licence, la dernière version, la capacité à tester un secret auprès de son fournisseur, et la sortie SARIF. Nous avons laissé de côté les étoiles, qui mesurent l'attention et non l'entretien.

Deux lignes changent le conseil habituel. Gitleaks fonctionne toujours et son dépôt reçoit encore des commits, mais depuis le 21 mai 2026 son README sur GitHub le dit « feature complete » et annonce que les prochaines versions « will be security patches only » (rien que des correctifs de sécurité). Son auteur d'origine est passé sur Betterleaks, un projet MIT créé en février 2026 par l'équipe à l'origine de Gitleaks, dont le développement est soutenu par Aikido Security. Quant à Nosey Parker, encore cité dans beaucoup de listes, Praetorian l'a archivé et remplacé par Titus, un scanner écrit en Go dont les 487 règles proviennent de Nosey Parker et de Kingfisher.

Il faut aussi regarder qui maintient chaque outil. Kingfisher appartient à MongoDB, detect-secrets à Yelp, git-secrets vient d'AWS Labs et Talisman de Thoughtworks. TruffleHog est le scanner open source de Truffle Security, sous licence AGPL-3.0 depuis sa version 3.0. Whispers, l'outil de Skyscanner que certaines listes citent encore, est archivé : sa dernière version, la 1.5.3, date d'août 2021.

Qu'ont trouvé les six scanners dans un dépôt truffé de faux secrets ?

Dans notre test du 29 octobre 2026, six scanners de secrets open source ont analysé un même dépôt contenant 12 faux credentials : Betterleaks en a trouvé 12, Titus 11, Gitleaks et Kingfisher 10, TruffleHog et detect-secrets 9. Les oublis portent sur des mots de passe et un secret de signature JWT sans préfixe de fournisseur, sur une clé présente uniquement dans l'historique git, et sur la clé live Stripe ratée par Titus. Titus et detect-secrets ont chacun signalé un leurre.

Le 29 octobre 2026, nous avons monté un petit dépôt qui ressemble à l'API d'une boutique en ligne, avec du TypeScript, du Python, un fichier de settings Django, un fichier Docker Compose et un script de déploiement en shell, le tout sur trois commits. Nous y avons planté 12 faux credentials, aux endroits où ils finissent d'habitude :

• une paire de clés d'accès AWS dans une config TypeScript ;
• un personal access token GitHub dans un en-tête curl ;
• une clé live Stripe dans .env ;
• un token de bot Slack dans du YAML ;
• une clé OpenAI et une clé Anthropic dans des appels de SDK ;
• une clé d'API Google dans une balise script HTML ;
• un mot de passe dans une chaîne de connexion Postgres ;
• un secret de signature JWT en Node.js ;
• un mot de passe de base de données Django ;
• une clé privée RSA ;
• une clé SendGrid dans un fichier .env.production qu'un commit ultérieur a supprimé.

Chaque valeur était aléatoire et reprenait le format du fournisseur, et aucune n'était une vraie clé. Deux leurres se trouvaient dans le README : la clé d'exemple documentée par AWS, AKIAIOSFODNN7EXAMPLE, et un placeholder Stripe fait de x. Chaque outil a tourné avec ses règles par défaut, en mode historique git quand il en a un, sur un Mac, avec les versions que Homebrew distribuait ce jour-là. Les vérifications en direct étaient coupées, puisqu'une fausse clé ne peut pas être vérifiée :

gitleaks git . --report-format json --report-path gitleaks.json
betterleaks git . --report-format json --report-path betterleaks.json
trufflehog git file://. --no-verification --json > trufflehog.jsonl
kingfisher scan . --no-validate --format json --output kingfisher.json
titus scan --git . --format json --output :memory: > titus.json
detect-secrets scan --all-files > detect-secrets.json

Les six ont trouvé la clé AWS, le token GitHub, le token Slack, la clé Anthropic et la clé privée. Les plus gros écarts viennent des secrets sans préfixe : Gitleaks, Kingfisher et TruffleHog ont manqué le mot de passe de la base Django, et Kingfisher comme TruffleHog ont aussi manqué le secret de signature JWT. Les clés de fournisseurs n'ont pas toutes été repérées pour autant, puisque TruffleHog et detect-secrets ont manqué la clé d'API Google, detect-secrets la clé OpenAI, et Titus la clé live Stripe. Une valeur affectée à JWT_SECRET est une chaîne aléatoire sans format à reconnaître, donc seules les règles qui lisent le nom de la variable ou l'entropie de la chaîne l'attrapent.

La clé SendGrid n'existait que dans un commit, supprimé par le commit suivant. Tous les outils qui lisent l'historique git l'ont trouvée. detect-secrets l'a manquée, et son README explique pourquoi : il évite le « digging through all git history », c'est-à-dire de fouiller tout l'historique git, et se contente des fichiers actuels, avec une baseline des résultats connus.

Les deux leurres n'ont pas piégé les mêmes outils. Gitleaks et Betterleaks ignorent les clés AWS qui se terminent par EXAMPLE, parce que leur règle AWS par défaut prévoit cette exception : la clé de la documentation n'a rien déclenché chez eux, alors que detect-secrets l'a signalée. Titus a pris le placeholder en x pour une clé Stripe et a manqué la vraie clé Stripe dans .env. Nosey Parker 0.24.0, que nous avons aussi lancé, a fait exactement la même chose, ce qui colle avec des règles reprises de Nosey Parker.

Le nombre de résultats dépasse le nombre de credentials. Titus a remonté 16 résultats pour 11 credentials, et detect-secrets 15 pour 9, parce que plusieurs règles se déclenchaient sur la même valeur : un token GitHub détecté à la fois comme token et comme en-tête curl, une clé OpenAI attrapée une seconde fois comme clé générique. Chaque doublon, c'est une ligne de plus à trier.

Gitleaks, TruffleHog ou Betterleaks : lequel choisir ?

Partez sur Betterleaks pour une nouvelle installation, gardez Gitleaks s'il tourne déjà dans vos hooks et que vous lui demandez seulement de continuer à fonctionner, et ajoutez TruffleHog ou Kingfisher quand savoir si une clé est active compte plus que d'attraper chaque mot de passe. Ces outils se distinguent par leurs règles, leur entretien et ce qu'ils font après une détection.

Gitleaks (MIT, v8.30.1) fait toujours son travail : dans notre test, il n'a levé aucune fausse alerte et a manqué deux mots de passe. Il ne recevra pas de nouvelles règles. En sortir demande peu d'effort, car Betterleaks lit un fichier .gitleaks.toml et respecte les commentaires gitleaks:allow.

Betterleaks (MIT) a tout trouvé dans notre test. La version 1.9.0 est la version stable, et la validation s'active par un flag, --validation. La version 2 est en release candidate, et son guide de migration indique que les reporters CSV, JUnit, SARIF et template ont été retirés (« have been removed »). Si votre pipeline lit du SARIF, restez en 1.x pour l'instant.

TruffleHog (AGPL-3.0) revendique plus de 800 types de secrets et plus de 700 détecteurs qui testent les credentials auprès de l'API du service concerné, et il lance ces tests par défaut. Pour AWS, son README indique qu'il appelle GetCallerIdentity. --results=verified ne garde que les secrets confirmés actifs, et dans notre test, vérification coupée, c'est aussi lui qui a remonté le moins de résultats. Il a manqué la clé d'API Google, le secret de signature JWT et le mot de passe Django. Il est sous licence AGPL-3.0 : lisez la licence avec votre service juridique avant de l'embarquer dans un produit ou de le redistribuer.

Kingfisher (Apache-2.0, Rust) valide les résultats par défaut et sait en révoquer certains. Depuis sa version 2.0.0 du 23 août 2026, ses règles viennent du catalogue de Betterleaks : 462 de ses 488 règles, plus 26 issues de Veles, le projet de Google. Nous avons testé la 2.14.0 ; la 2.15.0 est sortie la veille.

Titus (Apache-2.0, Go) est l'outil vers lequel migrent les utilisateurs de Nosey Parker. Il valide avec --validate et écrit du SARIF.

Un scanner de secrets doit-il tester si une clé est encore active ?

Oui pour le tri, à condition de maîtriser l'endroit où le test s'exécute. Une vérification en direct envoie le credential trouvé à l'API de son fournisseur et vous dit quels résultats relèvent de l'incident et lesquels sont des clés mortes. TruffleHog et Kingfisher le font par défaut, Betterleaks et Titus seulement avec un flag, Gitleaks jamais.

Le test est une vraie requête, envoyée avec le vrai secret. Lancez-le là où votre politique réseau autorise les appels vers ces fournisseurs, et gardez les résultats hors des logs de CI publics. Le secret scanning de GitHub propose la même idée sous forme de « validity checks », des vérifications de validité à activer.

Non vérifié ne veut pas dire sans danger. Le mot de passe d'une base de données sur votre réseau privé ne peut pas être testé depuis un runner de CI situé hors de ce réseau : un outil qui vérifie le signale donc comme non vérifié, et un filtre sur les résultats vérifiés le fait disparaître.

Où faire tourner le secret scanning : en pre-commit, en CI ou dans l'agent ?

À trois endroits : un hook pre-commit sur chaque poste, un scan en CI à chaque push que le développeur ne peut pas contourner, et un scan complet de l'historique le jour où vous adoptez l'outil. Le hook pre-commit seul ne suffit pas, car git commit --no-verify court-circuite les hooks pre-commit et commit-msg, comme le précise la documentation de git.

Sur GitHub, la protection au push bloque un push qui contient un secret détecté. Le secret scanning tourne gratuitement sur les dépôts publics ; sur les dépôts privés et internes appartenant à une organisation, il exige GitHub Secret Protection avec GitHub Team ou GitHub Enterprise Cloud, facturé par committer actif.

Les agents de code ajoutent une étape avant le commit. Claude Code, Cursor ou Codex peuvent lire un fichier .env quand rien ne le leur interdit, comme nous l'avons montré en détaillant ce que Claude Code envoie à Anthropic et comment garder le .env hors de sa portée, et une valeur lue par un agent peut se retrouver dans un fichier qu'il écrit.

C'est sur cette étape que travaille CybeDefend. Les garde-fous de VibeDefend refusent à l'agent la lecture du .env dans Claude Code, Cursor et Codex et le renvoient vers la variable d'environnement, et son scan du diff passe les fichiers modifiés par l'agent au crible des secrets, du SAST et de l'IaC avant qu'ils ne soient commités. Le fonctionnement de VibeDefend montre les deux.

La pull request reste la dernière barrière, et les contrôles de sécurité d'une pull request ouverte par un agent IA comprennent une passe sur les secrets.

Comment fusionner les résultats des scanners de secrets avec ceux de vos autres outils ?

Faites écrire à chaque scanner du SARIF 2.1.0, le format que lisent les forges de code et les outils de gestion des vulnérabilités, puis fusionnez. Cinq des six outils testés savent l'écrire, et chaque commande ci-dessous a produit un fichier SARIF 2.1.0 valide sur notre dépôt de test. Deux pièges : Betterleaks v2 retire son reporter SARIF, et l'aide de Kingfisher qualifie encore sa sortie SARIF d'expérimentale.

gitleaks git . --report-format sarif --report-path gitleaks.sarif
betterleaks git . --report-format sarif --report-path betterleaks.sarif   # 1.x only
trufflehog git file://. --sarif > trufflehog.sarif
kingfisher scan . --format sarif --output kingfisher.sarif
titus scan --git . --format sarif --output :memory: > titus.sarif

Scans en pre-commit et en CIUn fichier SARIF par outilFusionner et dédoublonnerTrier et garder l'historique

Un fichier fusionné n'est pas une liste triée. La même clé revient de deux outils sous deux noms de règle, un faux positif que vous aviez écarté réapparaît au scan suivant, et rien ne garde la trace que l'auditeur vous demandera. Le problème du tri est celui que nous décrivons dans pourquoi tant de résultats SAST ne sont que du bruit.

CybeDefend Open Source est conçu pour cette étape. Il fait tourner les scanners que vous choisissez, n'importe quel outil qui écrit du SARIF, et réunit ce qu'ils trouvent dans une seule file de résultats dédoublonnée, gratuitement et sur vos serveurs. Il sort bientôt, et la liste d'attente de CybeDefend Open Source est ouverte.

Quels scanners de secrets gratuits ne sont pas entièrement open source ni locaux ?

Le secret scanning de GitHub et ggshield, de GitGuardian, sont gratuits pour démarrer, mais aucun des deux ne tourne entièrement sur votre machine sous licence open source. GitHub scanne gratuitement les dépôts publics et exige un plan Secret Protection payant pour les dépôts privés. La CLI de ggshield est sous MIT, mais l'analyse passe par l'API de GitGuardian et demande un compte.

Le scan de GitHub est un service hébergé : il lit tout l'historique d'un dépôt présent sur GitHub, sur toutes les branches, et sa protection au push agit côté serveur. Il fait donc un bon filet de sécurité, mais convient mal au code qui vit ailleurs. Ce qu'il attrape et ce qu'il laisse passer dans un workflow Copilot est détaillé dans notre guide des risques de sécurité de GitHub Copilot.

Le README de ggshield indique que, pour l'utiliser, « you need to authenticate against GitGuardian servers », donc s'authentifier auprès des serveurs de GitGuardian, avec un compte ou une clé d'API ; il précise aussi que vos fichiers et vos secrets ne seront pas stockés. Pour beaucoup d'équipes, ce compromis est raisonnable, et il diffère de celui que vous faites en lançant Betterleaks sur votre propre runner.

Que faire quand un scanner trouve un vrai secret ?

Révoquez-le ou renouvelez-le d'abord, puis décidez s'il faut réécrire l'historique. Le guide de GitHub sur la suppression des données sensibles indique que la première étape, pour un mot de passe, un token ou un credential, consiste à le révoquer et/ou à le faire tourner, et qu'un secret révoqué ne donne plus accès à rien, ce qui peut suffire à lui seul.

1. Révoquez ou renouvelez le credential chez le fournisseur. Kingfisher, et Betterleaks à partir de la version 2, savent révoquer eux-mêmes certains types de credentials.
2. Vérifiez dans les logs d'accès du fournisseur comment il a été utilisé pendant qu'il était exposé.
3. Sortez-le du code, vers un gestionnaire de secrets ou une variable d'environnement que le code lit.
4. Ne réécrivez l'historique que si vous y êtes obligé ; le guide de GitHub en détaille les étapes.
5. Consignez les faux positifs pour qu'ils cessent de revenir : un commentaire gitleaks:allow ou betterleaks:allow, une entrée dans le fichier d'exclusion de l'outil, ou une baseline detect-secrets.

Questions fréquentes

Quel est le meilleur scanner de secrets open source en 2026 ?

Dans notre test du 29 octobre 2026, Betterleaks 1.9.0 a trouvé les 12 credentials plantés dans un petit dépôt de test et n'a déclenché aucune alerte sur les leurres. TruffleHog est le meilleur choix quand vous devez savoir si une clé est active, puisqu'il vérifie par défaut. Gitleaks fonctionne toujours, et son README limite ses prochaines versions aux correctifs de sécurité.

Gitleaks, c'est quoi ?

Gitleaks est un scanner de secrets open source sous licence MIT, qui repère par motifs les clés, tokens et mots de passe dans le code et dans l'historique git, en hook pre-commit comme en CI. Dans notre test, il a trouvé 10 des 12 credentials plantés, sans fausse alerte. Il fonctionne toujours, mais se déclare « feature complete » depuis le 21 mai 2026, et ses prochaines versions se limiteront aux correctifs de sécurité.

Gitleaks est-il encore maintenu ?

Gitleaks est toujours maintenu, mais uniquement pour les correctifs de sécurité. Depuis le 21 mai 2026, son README le dit « feature complete » et précise qu'aucune nouvelle fonctionnalité ne sera intégrée ; sa dernière version est la v8.30.1, du 21 mars 2026. Son auteur d'origine travaille désormais sur Betterleaks, qui lit les fichiers de configuration et les commentaires d'autorisation de Gitleaks.

Qu'est-ce que Betterleaks ?

Betterleaks est un scanner de secrets sous licence MIT, créé en février 2026 par l'équipe à l'origine de Gitleaks, son auteur d'origine compris, avec le soutien d'Aikido Security pour le développement. La version 1.9.0 est la version stable. La version 2, en release candidate, laisse la validation en direct désactivée par défaut et retire le reporter SARIF.

TruffleHog est-il gratuit et open source ?

Oui. La version de TruffleHog publiée sur GitHub est open source sous AGPL-3.0 depuis la version 3.0, et gratuite à utiliser. Elle revendique plus de 800 types de secrets, vérifie par défaut les credentials auprès de leurs fournisseurs, et écrit du SARIF depuis la version 3.97.0, sortie en août 2026.

detect-secrets scanne-t-il l'historique git ?

Non, et c'est voulu. detect-secrets scanne les fichiers de votre copie de travail, par défaut ceux que git suit, et tient une baseline des résultats connus pour que seuls les nouveaux secrets bloquent un commit. Dans notre test, il a manqué une clé présente uniquement dans l'historique d'un fichier supprimé. Sa dernière version, la 1.5.0, date de mai 2024.

Comment détecter des clés d'API codées en dur dans le code source ?

Passez un scanner par motifs comme Betterleaks ou Gitleaks sur le code et tout son historique git une première fois, puis à chaque commit et à chaque push. Les clés de fournisseurs comme AWS, GitHub ou Stripe se reconnaissent à leur préfixe et à leur format. Les secrets génériques, comme les mots de passe, demandent des règles sur les noms de variables et sur l'entropie, et c'est là que les outils diffèrent le plus.

Le secret scanning de GitHub est-il gratuit ?

Sur les dépôts publics, oui : il y tourne automatiquement et gratuitement. Sur les dépôts privés et internes appartenant à une organisation, il exige GitHub Secret Protection avec GitHub Team ou GitHub Enterprise Cloud, facturé par committer actif.