Ing. Calogero Bono
Selon les chercheurs en sécurité d'Apiiro, Claude Code laisse des secrets dans les dépôts publics de GitHub. Le problème vient d'un fichier de paramètres local, qui finit en ligne sans que le développeur s'en rende compte. Parmi les données trouvées, on compte des mots de passe de bases de données, des jetons API et des accès root. Cela concerne toute personne qui utilise un assistant de programmation fondé sur l'IA, car un seul commit distrait peut rendre publics des identifiants encore valides.
Quelques termes, avant d'entrer dans les faits. .gitignore est le fichier qui indique à Git quels fichiers ne pas enregistrer dans les commits. Dépôt (repository) est le dossier de projet suivi par Git. Secret désigne un identifiant sensible, comme un mot de passe, un jeton API ou une clé privée. Fork est la copie d'un projet réalisée par un autre utilisateur sur GitHub. Commit est l'enregistrement d'un ensemble de modifications dans l'historique du projet.
Qu'a-t-on découvert sur Claude Code et GitHub ?
Ars Technica rapporte le travail d'Apiiro dans cet article. Les chercheurs ont trouvé plus de 100 000 cas où le fichier local de paramètres de Claude Code avait été envoyé sur un dépôt public de GitHub.
Tous ne contiennent pas de données sensibles. Seuls environ 1 100 fichiers, issus de 63 organisations différentes, comportaient des secrets comme des jetons API publics, des mots de passe de bases de données ou des clés privées. Le nombre est faible par rapport au total, mais il s'agit d'identifiants réels, pas d'exemples.
Pourquoi le fichier se retrouve-t-il en ligne ?
Lorsque l'utilisateur choisit l'option « Oui, et ne plus demander » pour approuver une commande shell, ce choix devient une règle dans le fichier local .claude/settings.local.json. Parfois la règle est écrite sous forme de schéma générique. Mais souvent, la commande est enregistrée telle quelle, avec tout ce qu'elle contient, y compris d'éventuels identifiants.
Tant que le fichier reste sur l'ordinateur, le risque est limité, sauf compromission de la machine. Le problème commence lorsque le fichier entre dans un commit.
Le .gitignore ne devrait-il pas suffire ?
En théorie, si. Selon Ars Technica, la documentation d'Anthropic indique que ce fichier est ajouté au .gitignore global du développeur, ce qui évite en général sa publication.
Le point faible est que cette règle ne se reflète pas au niveau du dépôt. Si le projet est cloné sur une autre machine, ou si un dossier devient un dépôt plus tard, le fichier peut être envoyé par erreur. Apiiro ajoute que, dans de nombreux cas, c'est Claude Code lui-même qui committe les modifications des paramètres, sans intervention de l'utilisateur.
La documentation officielle de GitHub explique la différence. Le .gitignore à la racine du dépôt, une fois committé, s'applique à quiconque clone le projet. Celui global, dans ~/.config/git/ignore, ne s'applique que sur ton ordinateur.
Suffit-il de supprimer le fichier pour régler le problème ?
Non. Selon Apiiro, même après la découverte et la suppression des fichiers d'un dépôt, les secrets peuvent rester dans les forks du projet d'origine, si l'utilisateur ne fait pas attention.
La documentation de GitHub rappelle en outre qu'un fichier déjà suivi doit d'abord être retiré du suivi avec git rm --cached NOM_FICHIER, et seulement ensuite la règle d'exclusion prend effet. Ajouter une ligne au .gitignore n'efface pas ce qui est déjà dans l'historique. Pour cette raison, si un identifiant a été publié en ligne, il faut le considérer comme compromis et le remplacer.
Limites à connaître
Les chiffres viennent de l'analyse d'Apiiro, rapportée par Ars Technica, et nous n'avons pas vérifié ces données. Nous ne savons pas combien des identifiants trouvés étaient encore valides, ni s'ils ont été utilisés par des tiers. Les sources ne contiennent pas de réponse d'Anthropic sur d'éventuelles modifications du comportement de Claude Code. La situation pourrait évoluer si l'entreprise décidait d'intervenir sur la manière dont les commandes approuvées sont enregistrées.
Ce qui change pour ceux qui travaillent dans le numérique
Si tu utilises Claude Code, vérifie tout de suite si .claude/settings.local.json est suivi dans un dépôt, même privé. Un projet privé peut devenir public, ou être cloné ailleurs. Ajoute le fichier au .gitignore du projet et committe-le, pour que la règle s'applique à tout le monde. Pour exclure un fichier uniquement sur ton propre clone, GitHub indique .git/info/exclude.
Il y a aussi l'habitude d'écrire des mots de passe dans les commandes. Mieux vaut utiliser des variables d'environnement ou un gestionnaire de secrets. En entreprise, il est utile d'ajouter une analyse automatique des secrets avant chaque push.
Notre avis
Ce cas révèle une limite de conception, pas seulement une distraction des utilisateurs. Un fichier pouvant contenir des identifiants devrait être exclu là où cela compte, c'est-à-dire dans le dépôt, et pas seulement dans la configuration personnelle. Reporter toute la responsabilité sur l'utilisateur fonctionne mal, surtout quand l'outil fait des commits de manière autonome. Cela dit, c'est aussi notre responsabilité. Une commande contenant un mot de passe en clair est une mauvaise habitude à corriger, avec ou sans assistant IA. La rapidité que promettent ces outils rend la discipline autour des secrets plus urgente, pas moins.
Questions fréquentes
Quel fichier de Claude Code contient les secrets ?
Il s'agit de .claude/settings.local.json. Il enregistre les règles créées lorsque tu approuves une commande avec « Oui, et ne plus demander ». Parfois la commande est écrite en entier, avec les identifiants à l'intérieur.
Combien de fichiers exposés Apiiro a-t-il trouvés ?
Plus de 100 000 fichiers envoyés sur des dépôts publics de GitHub. Environ 1 100, issus de 63 organisations, contenaient des secrets comme des jetons API, des mots de passe de bases de données ou des clés privées.
Le .gitignore global protège-t-il du problème ?
Seulement en partie. Il s'applique sur ton ordinateur, mais pas dans le dépôt. Si le projet est cloné ailleurs ou si un dossier devient un dépôt plus tard, le fichier peut se retrouver dans un commit.
Supprimer le fichier du dépôt efface-t-il les secrets ?
Non. Selon Apiiro, les secrets peuvent rester dans les forks du projet. Si un identifiant a été publié, il faut le considérer comme compromis et le remplacer.
Comment exclure un fichier déjà suivi par Git ?
Retire-le d'abord du suivi avec git rm --cached NOM_FICHIER. Ajoute ensuite la règle au .gitignore. Sans la première étape, la règle n'a aucun effet sur un fichier déjà suivi.
Ce qu'il faut surveiller dans les prochains mois sur la sécurité de Claude Code
La question est de savoir si Anthropic changera la manière dont l'outil enregistre les commandes approuvées. En attendant, il est utile de suivre les mises à jour de l'outil.
- Lis les notes de version de Claude Code, pour voir si la gestion de settings.local.json change, en commençant par notre article sur la version 2.1.319.
- Cherche dans l'historique de tes dépôts les fichiers .claude déjà committés, et fais tourner les identifiants qui apparaissent.
- Revois les règles de protection des branches, en t'appuyant sur notre guide des pull requests sur GitHub.
