Assistants de code IA : des mots de passe publiés sur GitHub sans que personne s'en aperçoive
Ce que l'étude d'Apiiro a trouvé dans les fichiers de Claude Code, et les gestes à faire dans vos dépôts dès cette semaine
Image générée par IA (art. 50 AI Act)
Analyse 2LKATIME
Le 6 novembre, la société de sécurité Apiiro a publié une étude sur les fichiers de configuration de Claude Code, l'assistant de programmation d'Anthropic. Elle y a trouvé des mots de passe et des clés, enregistrés en clair puis publiés sur GitHub. Le sujet dépasse un outil : tout assistant qui garde la trace de ce qu'on lui fait exécuter pose la même question. Nous nous appuyons ici sur le compte rendu de The Hacker News, daté du 7 novembre.
Un secret publié est un secret perdu
Un mot de passe de base de données ou une clé cloud dans un dépôt public donne accès à vos données, sans qu'aucun pirate n'ait à forcer quoi que ce soit. Parmi les cas relevés : le mot de passe propriétaire d'une base de dossiers médicaux, selon les chercheurs.
Quand un développeur choisit « Yes, and don't ask again » dans Claude Code, l'assistant peut enregistrer la commande telle quelle, secret compris, dans un fichier du projet. Ce fichier part ensuite avec le code, parfois jusque sur GitHub.
Les chercheurs n'ont pas testé si les secrets trouvés fonctionnent encore. Une entreprise prévenue en début de semaine a toutefois confirmé que sa clé était active. Pour une PME, la leçon est simple : le risque ne vient pas d'une attaque sophistiquée, mais d'une habitude commode.
1. Ce que l'étude a trouvé
104 185
Copies du fichier trouvées dans des dépôts GitHub publics
1 122
Copies contenant au moins un secret, soit environ 1,1 %
379
Mots de passe de bases de données parmi les secrets
215
Fichiers à secret que gitleaks et TruffleHog ont tous deux manqués
Apiiro a cherché le fichier .claude/settings.local.json sur GitHub public. Il en a trouvé 104 185 copies dans 103 617 dépôts, dont 1 122 contiennent au moins un secret, pour 1 379 secrets distincts. Plus d'un tiers ouvrent directement une base de données. On compte aussi 43 accès SSH à des serveurs publics, 42 jetons GitHub, GitLab ou npm, et 23 clés AWS. Soixante-trois organisations, surtout des éditeurs de logiciels, figurent parmi les propriétaires.
En ajoutant les anciennes versions des fichiers, un autre fichier de réglages que les équipes partagent volontairement et des journaux de conversation d'agents, le total monte à 2 539 secrets dans 1 994 dépôts. Pour la moitié des dépôts concernés, le fichier était en ligne depuis au moins 217 jours.
2. Comment un secret se retrouve là
Le mécanisme est banal, et c'est ce qui le rend dangereux. Il tient en quatre étapes.
1. L'assistant demande l'autorisation
Par défaut, Claude Code demande avant d'exécuter la plupart des commandes dans un terminal.
2. L'utilisateur choisit « ne plus demander »
Le choix « Yes, and don't ask again » enregistre une règle d'autorisation dans .claude/settings.local.json, à l'intérieur du projet.
3. La règle recopie la commande
Selon la documentation citée par les chercheurs, la règle porte parfois sur un motif de commande, parfois sur la commande exacte. Dans ce second cas, un mot de passe tapé dans la commande est enregistré en clair.
4. Le fichier est publié avec le projet
La protection de Claude Code ajoute le fichier aux exclusions git de l'utilisateur, sur son ordinateur seulement. Un fichier déjà versionné, ou un projet cloné ailleurs, n'en profite pas.
Les chercheurs notent que, dans 539 des 1 105 dépôts qu'ils ont retracés, un commit signé avec Claude en coauteur a modifié le fichier. Ils en déduisent que l'assistant le versionne souvent lui-même. Ils ont reproduit le comportement avec les derniers modèles d'Anthropic, Opus 5.5 et Fable 5.1.
3. Ce que l'article ne dit pas, et ce qu'il faut garder en tête
Trois précisions pour ne rien exagérer. D'abord, 1,1 % des copies contiennent un secret : la grande majorité des fichiers sont sans danger. Ensuite, l'étude ne dit pas si quelqu'un a utilisé ces secrets. Enfin, nous n'avons pas trouvé, dans les sources lues, de réponse publique d'Anthropic. Les chercheurs rapportent que des signalements de ce comportement, dont un daté d'août 2025, ont été clos automatiquement par un robot, sans réponse de l'éditeur.
Notre position : le problème est réel et concret, mais il se corrige par des habitudes simples, détaillées plus bas. Il n'y a pas lieu d'abandonner un outil pour autant, à condition de ne pas lui confier de secrets dans les commandes.
4. Vérifier vos dépôts
Commencez par chercher le fichier dans vos projets, puis dans l'historique de chaque dépôt, y compris là où il a été supprimé :
find . -path "*/.claude/settings*.json"
git log --all --oneline -- .claude/settings.local.json .claude/settings.jsonSi le fichier existe, ouvrez-le et repérez les commandes qui contiennent un mot de passe, un jeton ou une clé. Les formes à chercher sont celles que les scanners ratent : une variable précédée de PGPASSWORD=, une option sshpass -p ou mysql -p :
grep -nE "PGPASSWORD|sshpass|mysql .*-p|TOKEN|SECRET|KEY|password" .claude/settings.local.jsonPour une organisation GitHub, la recherche de code du site permet de lister les dépôts concernés avec une requête du type org:VOTRE_ORGANISATION path:.claude/settings.local.json. Pensez aussi aux dépôts de vos prestataires qui travaillent sur vos projets : demandez-leur de faire la même vérification.
5. Que faire, dans l'ordre
Les chercheurs recommandent de changer les secrets avant tout nettoyage, car un secret déjà publié doit être considéré comme compromis. Voici les gestes, par priorité.
Changer les secrets d'abord
Mots de passe de base de données, jetons GitHub, GitLab ou npm, clés AWS, accès SSH : tout ce que le fichier a contenu, y compris dans l'historique. Le nettoyage vient ensuite.
Sortir le fichier du suivi git
Retirez-le du suivi avec git rm --cached, puis ajoutez-le au .gitignore du projet, pas seulement à votre configuration personnelle.
Ne plus taper de secret dans les commandes
Utilisez une variable d'environnement alimentée par un gestionnaire de secrets : la règle enregistrée contiendra $DB_URL et non le mot de passe.
Approuver des motifs, pas des commandes exactes
Autoriser « npm run:* » enregistre un motif sans secret, alors qu'autoriser une commande précise enregistre tout son contenu.
git rm --cached .claude/settings.local.json
echo ".claude/settings.local.json" >> .gitignore
git add .gitignore && git commit -m "Ne plus suivre le fichier local de l'assistant"Ajoutez les dossiers d'assistants, comme .claude, .cursor ou .gemini, aux contrôles de secrets de votre intégration continue et à votre analyse de l'historique. Vérifiez que l'outil détecte les mots de passe tapés dans des commandes, pas seulement les formats de clés connus : sur les 1 122 fichiers à secret, gitleaks en a signalé 564 et TruffleHog 643, et 215 ont échappé aux deux.
6. Conformité
Si le secret donne accès à une base contenant des données personnelles, sa publication peut constituer une violation de données au sens du RGPD : accès non autorisé possible à des données. L'article 32 impose des mesures de sécurité adaptées, dont la gestion des secrets. En cas de violation avérée ou probable avec un risque pour les personnes, la notification à la CNIL se fait sous 72 heures. Notez la date de découverte, les secrets changés et les journaux d'accès consultés. Les entités soumises à NIS2 ont en plus une alerte précoce à émettre sous 24 heures pour un incident significatif.
Côté gouvernance, incluez les assistants de code dans votre inventaire des outils et dans votre politique de gestion des secrets.
7. Ce que 2LKATIME recommande
Adoptez trois règles pour toute équipe qui utilise un assistant de code : aucun secret saisi en clair dans une commande, un gestionnaire de secrets pour tout ce qui est sensible, et un contrôle automatique des secrets à chaque commit. Nos audits cybersécurité incluent une revue des dépôts et de l'historique, et notre accompagnement IA aide à encadrer l'usage des assistants dans l'entreprise.
Les entreprises de Paris, de Lyon ou de Bordeaux trouveront les formules sur nos pages tarifs. L'accompagnement se fait aussi à distance partout en France.
FAQ - Secrets et assistants de code IA
Mon entreprise utilise Claude Code : sommes-nous concernés ?
Seulement si le fichier .claude/settings.local.json d'un projet contient un secret et a été publié, ou le sera. Les chercheurs ont trouvé ces fichiers dans des dépôts publics. Un dépôt privé n'expose pas le fichier au public, mais le secret y reste en clair pour toute personne ayant accès au dépôt.
Supprimer le fichier de GitHub suffit-il ?
Non. Les anciennes versions restent dans l'historique git et dans les forks du dépôt. La règle donnée par les chercheurs est de changer d'abord tous les mots de passe, jetons et clés que le fichier a contenus, puis de nettoyer.
Mon scanner de secrets va-t-il détecter le problème ?
Pas toujours. Les chercheurs ont testé gitleaks et TruffleHog sur les 1 122 fichiers contenant un secret : le premier en a signalé 564, le second 643, et 215 ont échappé aux deux. Les oublis sont surtout des mots de passe tapés dans des commandes, qui ressemblent à du texte ordinaire.
Comment éviter que le secret soit enregistré ?
Ne tapez pas le secret dans la commande : utilisez une variable d'environnement alimentée par un gestionnaire de secrets. La règle enregistrée contiendra alors le nom de la variable, pas sa valeur. Préférez aussi approuver des motifs de commandes plutôt que des commandes exactes.
Est-ce propre à Claude Code ?
Les chercheurs ont comparé 16 assistants de code et indiquent que Claude Code est le seul dont ils ont confirmé qu'il enregistre par défaut la commande complète dans un fichier du projet. Les dossiers d'autres assistants, comme .cursor ou .gemini, doivent malgré tout être traités avec la même prudence.
Sources
Vos dépôts contiennent-ils des secrets sans que vous le sachiez ?
2LKATIME analyse vos dépôts et leur historique, repère les secrets exposés et vous remet un plan de rotation clair, avec des règles simples pour vos équipes et vos assistants de code.