Le bouton, le fichier et la commande
La société de sécurité applicative Apiiro a publié le 6 novembre une étude qui recense 2 539 secrets réels dans 1 994 dépôts GitHub publics, presque tous inscrits là par le fichier d’autorisations d’un agent de programmation.
Le mécanisme est banal. Claude Code demande confirmation avant d’exécuter une commande shell. Si l’on choisit « Oui, et ne redemande plus », il enregistre une règle d’autorisation dans .claude/settings.local.json, au sein du dossier du projet. Lorsque la règle approuvée est une commande littérale et non un motif, tout ce qui a été saisi dans cette commande — mot de passe de base de données, jeton, accès SSH — est conservé avec elle, en clair, dans un fichier posé à côté du code.
Apiiro a parcouru GitHub public du 1er au 3 novembre et y a trouvé 104 185 copies de ce fichier dans 103 617 dépôts. Parmi elles, 1 122 fichiers, environ 1,1 %, contenaient un secret réel : 1 379 valeurs distinctes au total, dont 636 correspondant au format de clé d’un fournisseur connu et 743 constituant des mots de passe ou des jetons placés à côté d’un serveur public. Plus d’un tiers ouvrent directement une base de données, dont 379 mots de passe de bases et 122 clés de rôle de service Supabase, à côté de 43 accès SSH vers des serveurs publics, 42 jetons GitHub, GitLab et npm et 23 clés AWS.
Pourquoi ces fichiers sont publics
Claude Code tente bien de garder le fichier en local : lorsqu’il le crée dans un dépôt, il l’ajoute aux exclusions git globales du développeur. Cela couvre le cas courant et rien d’autre. Cela ne couvre ni un dossier devenu dépôt par la suite, ni un clone sur une deuxième machine, ni un fichier déjà versionné, et la règle n’entre jamais dans le .gitignore du dépôt lui-même : aucune protection ne voyage donc avec le projet.
Apiiro relève aussi que l’agent verse souvent le fichier lui-même : dans 539 des 1 105 dépôts contenant un secret réel qu’elle a pu tracer, un commit cosigné par Claude l’avait modifié. Les instructions de commit de Claude Code demandent au modèle de ne pas verser .env ni credentials.json ; son propre fichier de configuration ne figure pas sur cette liste. Sur 16 agents de programmation dont Apiiro a comparé la documentation, Claude Code est selon elle le seul dont il est confirmé qu’il écrit par défaut la commande approuvée complète dans un fichier du projet.
L’exposition n’est pas brève. Chaque fichier concerné se trouvait encore sur la branche par défaut de son dépôt lors de la vérification, et dans le cas médian il y était depuis 217 jours. Le supprimer ne referme rien : des versions antérieures du fichier abritent 734 secrets supplémentaires dans 509 dépôts, absents de toute copie actuelle, et 211 forks de 74 dépôts portent les mêmes valeurs.
Ce que les scanners manquent, et ce que dit Anthropic
Les scanners génériques en ont repéré environ la moitié. Passés sur les 104 185 fichiers, gitleaks en a signalé 564 sur les 1 122 contenant un secret réel, et TruffleHog 643 ; 215 n’ont été signalés par aucun des deux. L’écart tient aux mots de passe saisis dans les commandes — après PGPASSWORD=, sshpass -p ou mysql -p — qui ressemblent à des mots ordinaires plutôt qu’à des formats de clé.
Apiiro indique avoir prévenu chaque organisation concernée les 2 et 3 novembre, et Anthropic par le canal de divulgation que l’entreprise demande d’emprunter. Elle note aussi que des utilisateurs signalent le mécanisme dans les tickets GitHub de Claude Code depuis août 2025, qu’aucun n’a reçu de réponse et que trois ont été fermés automatiquement pour inactivité ou doublon.
Le responsable de Claude Code chez Anthropic, Boris Cherny, a répondu sur Hacker News le 7 novembre. « Historiquement, Claude Code n’a pas fait de nettoyage des secrets (il existe beaucoup de bons outils pour cela), mais nous examinons ce que nous pouvons faire pour l’empêcher », a-t-il écrit, citant « veiller à ce que le mode automatique le détecte, intégrer une analyse basique des secrets » parmi les pistes que l’équipe prototyperait « avant de livrer quelque chose ». Il a ajouté que Claude Code place le fichier dans gitignore lorsqu’il le crée, et qu’à ses yeux les copies exposées ont donc été créées à la main puis versionnées.
Apiiro énonce ses propres limites sans détour : aucun identifiant n’a été utilisé ni testé, et « secret réel » désigne une valeur correspondant au format d’un fournisseur ou pointant vers un serveur public, non une valeur dont on sait qu’elle fonctionne. Une entreprise prévenue a confirmé que sa clé était active. Le conseil qui en découle n’a rien de spectaculaire : renouveler tout ce que le fichier a pu contenir, cesser de le versionner et approuver des motifs plutôt que des commandes littérales.
