Fuites de secrets dans Claude Code : Apiiro découvre des identifiants dans 1 122 fichiers GitHub publics

Les fuites de secrets dans Claude Code ont placé les approbations enregistrées d’Anthropic sous surveillance après qu’Apiiro a signalé des identifiants dans 1 122 fichiers de paramètres GitHub publics. Sa recherche du 5 novembre décrit une fonctionnalité qui mémorise des commandes contenant des secrets. La publication exige une étape supplémentaire : valider puis pousser le fichier obtenu.

La tension se situe entre un raccourci utile et l’enregistrement sensible qu’il crée. Les développeurs approuvent une opération pour terminer leur travail, tandis que le logiciel conserve des informations qui méritent une protection distincte. Une décision d’exécution devient une décision de stockage, souvent sans que l’utilisateur traite ces choix comme distincts.

Anthropic a reconnu le problème, tout en soulignant que le fichier de paramètres doit rester local. Cursor offre une comparaison utile, car sa documentation traite également de l’exécution autonome et de ses risques. Dans l’ensemble de ces produits, la question est de savoir comment les systèmes d’autorisation préservent la commodité sans créer un autre endroit où les identifiants s’accumulent.

Ce que mesure réellement la découverte sur les fuites de secrets dans Claude Code

La recherche d’Apiiro sur l’exposition d’identifiants a examiné 104 185 copies publiques de .claude/settings.local.json. Elle a identifié 1 379 secrets distincts dans les 1 122 fichiers signalés. Les chercheurs n’ont pas testé ces identifiants ; ce nombre n’établit donc ni un accès fonctionnel ni des intrusions réussies.

Le chiffre mis en avant mesure des fichiers exposés, plutôt que des comptes compromis. Cette distinction compte pour la réponse aux incidents, les décisions d’achat et toute affirmation sur la gravité de la découverte. La présence d’un identifiant justifie une enquête, tandis que sa validité et ses autorisations déterminent les conséquences immédiates.

Le flux de travail sous-jacent est familier. Un assistant de codage propose une opération, le développeur l’examine, et une approbation persistante réduit les interruptions à venir. La conséquence inattendue apparaît lorsque l’approbation enregistrée conserve des informations que le développeur considérait comme temporaires.

Prenons comme scénario illustratif une vérification d’une base de données de préproduction. Le développeur doit demander à l’assistant d’examiner un échec de connexion et approuve une commande contenant des informations d’authentification. Terminer cette vérification n’exige pas que l’identifiant devienne un artefact durable du projet.

Pourtant, un enregistrement d’approbation peut conserver précisément les informations nécessaires à l’opération. Son objectif paraît administratif, ce qui facilite sa séparation mentale d’avec les mots de passe et les jetons d’accès. Cette séparation devient dangereuse lorsque les réviseurs supposent que la configuration contient des préférences plutôt que des données opérationnelles sensibles.

Le dépôt public ajoute une autre frontière. Des informations auparavant accessibles sur la machine d’un développeur deviennent disponibles pour toute personne capable de lire le projet. La fonctionnalité d’approbation et le flux de publication doivent donc faire l’objet d’un examen distinct.

Il serait excessif d’affirmer que sélectionner cette option envoie automatiquement des mots de passe vers GitHub. La séquence signalée implique une persistance locale suivie d’une publication via le contrôle de version, le système qui enregistre et partage les modifications du projet. Chaque étape crée une possibilité de prévention.

Il serait également réducteur de décrire le problème uniquement comme une validation négligente. Le comportement du produit détermine quelles données sensibles existent pour qu’une personne puisse les valider. Un flux de publication plus sûr aide, mais éviter les copies inutiles d’identifiants traite une partie plus précoce du problème.

Le changement pertinent concerne ce que les équipes doivent prendre en compte lors de la révision. Les paramètres d’agent méritent une attention au même titre que le code applicatif et la configuration de déploiement. Un fichier peut influencer la sécurité par les informations qu’il conserve, même lorsqu’il ne contient aucun programme exécutable.

Cela élargit le sens d’une modification sensible. Les réviseurs doivent considérer ce qu’un fichier révèle autant que ce qu’il permet à l’application de faire. Les enregistrements d’autorisation se situent directement à cette intersection.

Un fichier de paramètres local est une promesse assortie de conditions

La documentation d’Anthropic sur les paramètres locaux indique que les approbations Bash persistantes deviennent des règles d’autorisation dans .claude/settings.local.json. Bash est un interpréteur de commandes utilisé pour exécuter des programmes. Claude Code ajoute une exclusion à la configuration Git ignore globale du développeur lorsqu’il écrit le fichier pour la première fois dans les conditions documentées.

La documentation identifie séparément .claude/settings.json comme une configuration de projet partagée que les équipes peuvent valider. Les fichiers locaux créés manuellement requièrent leur propre exclusion. Ces distinctions clarifient la frontière voulue, mais elles soulignent aussi l’importance de l’origine du fichier.

Qualifier un fichier de local n’impose pas, à lui seul, la confidentialité. Son nom communique une intention aux personnes, tandis que les contrôles du dépôt déterminent s’il circule avec le projet. Ce sont des protections liées, mais dont les conditions de défaillance diffèrent.

Une exclusion globale appartient à l’environnement d’un développeur. Une exclusion au niveau du projet appartient au flux de travail du dépôt. Cette différence compte dès lors que les équipes s’attendent à ce qu’une convention de sécurité survive aux changements de machines, de contributeurs ou d’environnements de développement.

Considérons une transmission de projet comme exemple d’analyse. L’auteur initial sait quels fichiers contiennent un état personnel et quels fichiers appartiennent au contrôle de code source. Un nouveau contributeur voit la structure des répertoires sans nécessairement hériter de cette compréhension.

Le problème devient organisationnel lorsque chaque contributeur doit reconstituer la même distinction. Une règle qui dépend de connaissances personnelles exige une attention répétée. Une règle représentée dans une politique de projet partagée est plus facile à examiner et à discuter.

Aucune des deux approches n’élimine le besoin d’examiner ce qui entre dans un commit. Une exclusion constitue une convention préventive, tandis que la modification validée est la véritable décision de publication. Les équipes doivent évaluer les deux plutôt que supposer que la présence de l’une garantit l’autre.

La terminologie mérite également attention. Les paramètres évoquent généralement des préférences inoffensives, comme les options d’affichage ou le comportement de l’éditeur. Un fichier d’autorisations peut contenir un enregistrement bien plus sensible, car son contenu provient d’opérations réelles.

Ce décalage met sous pression la conception du produit. Si un logiciel conserve des arguments de commande, il doit aider les utilisateurs à comprendre cette persistance avant qu’ils ne traitent le fichier comme une configuration ordinaire. L’avertissement pertinent doit se situer près de la décision qui crée l’enregistrement.

Il existe ici une contrainte légitime d’utilisabilité. Exiger des utilisateurs qu’ils inspectent chaque détail de mise en œuvre rendrait l’assistant plus difficile à utiliser et encouragerait une approbation superficielle. Le défi de conception consiste à mettre en évidence la conséquence importante sans submerger l’opération elle-même.

Pour les acheteurs en entreprise, cela devient une question d’évaluation concrète. Les administrateurs peuvent-ils expliquer quels fichiers d’agent peuvent être partagés sans risque, lesquels restent personnels et lesquels peuvent contenir des données sensibles ? Les réponses d’un produit doivent correspondre aux contrôles de dépôt réellement utilisés par les employés.

Les autorisations de Claude Code expliquées par la documentation fournissent le modèle prévu. Le test pratique consiste à déterminer si ce modèle reste compréhensible pendant la collaboration quotidienne. La documentation établit des attentes ; le comportement observable détermine si les équipes peuvent les suivre de manière fiable.

Le raccourci échange des invites répétées contre des données persistantes

La commodité des approbations persistantes est facile à comprendre. Les développeurs souhaitent qu’un assistant poursuive le travail courant sans interrompre chaque étape. Un système qui redemande sans cesse la même décision encourage les utilisateurs à rechercher une autorisation plus large ou plus durable.

Le compromis central oppose moins d’interruptions aux informations conservées pour les rendre possibles. L’autorisation d’exécution et le stockage d’identifiants méritent des décisions distinctes, même lorsque l’interface les présente ensemble.

Une manière utile d’évaluer la conception consiste à séparer la capacité des données. La capacité décrit ce que l’agent peut faire, comme exécuter une opération de développement approuvée. Les données incluent les arguments particuliers et les éléments d’authentification fournis durant une exécution.

Préserver une capacité ne requiert pas nécessairement de conserver chaque donnée. Toutefois, supprimer des arguments peut modifier la signification d’une règle. Une approbation plus large pourrait autoriser des opérations que l’utilisateur n’avait jamais envisagées, créant un autre problème de sécurité.

C’est pourquoi supprimer simplement le texte suspect des commandes enregistrées constitue une spécification de conception incomplète. Le produit doit préserver le périmètre voulu par l’utilisateur tout en évitant une conservation inutile. Le comportement résultant doit aussi rester compréhensible lorsqu’une opération demande à nouveau une autorisation plus tard.

Les références à des identifiants offrent une autre piste de conception. Une commande peut faire référence à une valeur fournie séparément plutôt que d’intégrer directement cette valeur. Cela réduit la nécessité pour un enregistrement d’approbation de contenir l’identifiant lui-même.

Les références exigent toujours de la prudence. Un programme peut imprimer une valeur résolue, un message d’erreur peut la révéler, ou un autre artefact peut conserver la sortie. Éviter un mot de passe littéral dans un enregistrement réduit l’exposition sans établir une protection complète.

C’est ici que le sujet devient pertinent au-delà d’un bouton particulier. Les logiciels d’agent produisent des enregistrements pour favoriser la continuité, le débogage et la collaboration. Chaque enregistrement devrait avoir un objectif, un public et une politique de conservation définis, proportionnels à son contenu.

La mémoire apparente de l’assistant peut masquer ces questions. Les utilisateurs vivent une conversation qui poursuit le travail, tandis que la mise en œuvre peut créer des fichiers soumis à des règles de partage différentes. Les équipes produit doivent rendre visibles les frontières qui ont des conséquences.

La documentation de Cursor sur la sécurité des agents d’arrière-plan fournit une comparaison utile. Elle décrit des machines virtuelles isolées, l’accès à Internet et l’exécution automatique du terminal. Elle avertit également que des instructions malveillantes peuvent mener au vol de données via l’injection de prompt, où un contenu non fiable redirige le comportement d’un agent.

Cette comparaison n’établit pas que Cursor partage le comportement de stockage des approbations signalé pour Claude Code. Elle montre que des conceptions concurrentes répartissent différemment la responsabilité entre l’exécution, l’isolation et la révision par l’utilisateur. Les acheteurs doivent comparer ces mécanismes séparément plutôt que de sélectionner un produit selon son seul mode d’approbation.

L’isolation limite l’environnement dans lequel une opération s’exécute. L’approbation décide si une opération se poursuit. La gestion des identifiants détermine quelles données sensibles entrent dans l’environnement et quels enregistrements subsistent ensuite.

Ces contrôles se renforcent mutuellement lorsque leurs frontières sont explicites. Ils deviennent déroutants lorsqu’une décision réussie à un niveau est considérée comme la preuve que tous les autres niveaux sont sûrs. Une opération autorisée peut toujours laisser un enregistrement inapproprié.

Les risques de sécurité de Claude Code méritent donc une évaluation au niveau du flux de travail. La question utile est de savoir quelles informations une tâche approuvée crée, où ces informations persistent et qui peut les récupérer ultérieurement.

Anthropic reconnaît la lacune, mais le mode automatique n’est pas un certificat de correction

Boris Cherny, de l’équipe Claude Code, a abordé le signalement dans la discussion sur la sécurité des autorisations. Il a déclaré que Claude Code ne disposait historiquement pas d’un mécanisme d’effacement des secrets et a recommandé le mode automatique ainsi que l’analyse des secrets dans les dépôts. Il a également décrit des protections possibles pour le prototypage, y compris une détection élémentaire des secrets.

Un lecteur a demandé si le mode automatique pouvait toujours atteindre le parcours d’approbation problématique. Cherny a reconnu cette observation. Ses commentaires attestent d’une réponse active, mais ils ne prouvent pas qu’un correctif complet ait été déployé.

Une protection proposée doit être vérifiée face à la défaillance qu’elle est censée prévenir. Réduire les approbations manuelles et empêcher la persistance des identifiants sont des objectifs liés, mais leurs critères d’acceptation diffèrent. Les preuves concernant l’un ne doivent pas se substituer aux preuves concernant l’autre.

Le point de vue sceptique est simple. Si une opération sensible crée toujours un enregistrement d’approbation contenant un identifiant, modifier le mode d’exécution par défaut laisse cette voie pertinente. Une réponse doit traiter l’artefact qui en résulte, ainsi que la fréquence des invites.

L’accent mis par Anthropic sur la réduction des interruptions liées aux autorisations repose aussi sur un argument raisonnable. Des invites répétées peuvent mobiliser l’attention sans entraîner un examen attentif. Améliorer cette expérience est utile, à condition que cette amélioration ne devienne pas une affirmation générale de sécurité.

Le désaccord porte en partie sur l’endroit où le contrôle doit être appliqué. Certains utilisateurs souhaitent des restrictions fixes qui s’appliquent indépendamment de l’interprétation d’un agent. D’autres privilégient une évaluation automatique capable de distinguer l’activité courante des opérations sensibles.

Ces approches répondent à une question différente de celle de savoir si les enregistrements sauvegardés contiennent des mots de passe. Une limite stricte d’exécution peut coexister avec une rétention excessive de données. Un évaluateur automatique peut réduire les interruptions tout en nécessitant des règles explicites sur ce qui est écrit sur le disque.

L’évaluation en entreprise doit conserver ces questions distinctes. Un acheteur peut apprécier l’exécution automatique des tâches tout en exigeant un comportement de stockage prévisible. Le produit doit démontrer les deux par des résultats observables plutôt que demander aux clients d’en déduire l’un à partir de l’autre.

Un exercice de vérification crédible utiliserait des identifiants artificiels dans un projet contrôlé. Il inspecterait l’enregistrement d’approbation et les autres artefacts produits après l’opération. Il examinerait également le comportement lorsqu’un fichier local sensible est déjà suivi.

Il s’agit de conditions d’évaluation proposées, et non d’affirmations concernant des tests réalisés par Anthropic. Elles décrivent les preuves nécessaires pour distinguer une réponse prometteuse d’une amélioration démontrée. Des résultats publiés permettraient aux clients d’évaluer la portée de tout changement.

Les fuites de secrets de Claude Code révèlent également un défi de communication. Conseiller aux utilisateurs d’activer un autre contrôle est utile, mais cela laisse ouverte la question de la responsabilité que le produit assumera lui-même. Des notes de version claires devraient expliquer à la fois la nouvelle protection et les conditions qui subsistent.

La conclusion la plus équitable est limitée et exploitable. Anthropic reconnaît le problème, des utilisateurs ont soulevé des cas limites pertinents, et l’efficacité des changements proposés exige une observation. Ni le rejet du problème ni la déclaration d’une remédiation complète ne correspondent aux éléments disponibles.

Les équipes de sécurité héritent d’un autre type d’examen des dépôts

Pour les équipes de sécurité, la pression immédiate concerne la visibilité. Les revues d’applications se concentrent souvent sur le code qui s’exécute en production. Des paramètres générés par un agent peuvent créer une exposition avant même que l’application ne modifie son comportement.

L’examen doit suivre les informations sensibles tout au long du flux de développement. Un fichier de configuration mérite un examen fondé sur son contenu et sa destination. Son objectif administratif ne rend pas inoffensives les informations qu’il contient.

La protection contre les poussées de GitHub bloque les détections de secrets prises en charge avant leur publication. Sa documentation distingue les motifs spécifiques à un fournisseur, génériques, personnalisés et détectés par IA, avec des exigences de configuration variables. Les équipes doivent donc vérifier la couverture qu’elles ont activée plutôt que supposer que chaque identifiant sera détecté.

La présence d’un analyseur et la couverture démontrée d’un analyseur constituent des formes de preuve différentes. Un jeton de service identifiable et un mot de passe ordinaire intégré dans une commande présentent des difficultés de détection différentes. Des tests avec des exemples artificiels peuvent révéler si le système configuré reconnaît les motifs réellement utilisés par une équipe.

Cela modifie la conversation entre les développeurs et le personnel de sécurité. Le développeur a besoin d’un flux de travail qui continue de fonctionner. L’équipe de sécurité a besoin de preuves que des valeurs sensibles n’entrent pas discrètement dans du contenu destiné au partage.

L’objectif commun devrait être une frontière reproductible. L’état personnel de l’agent devrait avoir une destination explicite, la configuration partagée devrait disposer d’une norme de revue claire, et les identifiants détectés devraient parvenir à une personne capable de les révoquer.

Une réponse à incident doit également séparer l’endiguement du nettoyage. Les conseils de GitHub sur la suppression des données sensibles donnent la priorité à la révocation ou à la rotation des identifiants exposés. Ils expliquent que la suppression de l’historique requiert une coordination et que des copies peuvent subsister dans des clones, des forks et d’autres références.

Cet ordre reflète la différence entre un identifiant et le document qui le contient. Modifier un document change ce que les lecteurs voient à cet emplacement. La révocation modifie la capacité de l’identifiant à continuer d’autoriser l’accès.

Pour une équipe sous pression, un nettoyage visible peut donner l’impression d’une résolution parce que le fichier fautif disparaît de la vue la plus récente. Le résultat de sécurité pertinent est de savoir si la valeur exposée conserve son autorité. Le nettoyage historique et la revue des accès traitent des conséquences supplémentaires.

La responsabilité devient plus difficile lorsque la personne qui découvre l’enregistrement ne peut pas en identifier le propriétaire. Un développeur peut reconnaître le nom d’un projet sans savoir quel système a émis un jeton. Une responsabilité claire raccourcit le chemin entre la détection et un endiguement efficace.

Les équipes ont également besoin d’un moyen de préserver l’enseignement sans préserver le secret. Une note d’incident peut décrire le flux de travail affecté, le service responsable et le changement préventif. Elle doit éviter de recopier des valeurs sensibles uniquement pour rendre l’explication concrète.

Cette distinction s’applique aussi à une base de connaissances consultable. Les connaissances d’ingénierie utiles comprennent les procédures approuvées et les explications d’échecs passés. Les identifiants ont leur place dans des systèmes conçus pour gérer les accès, plutôt que dans des documents de référence généraux.

Les risques de sécurité de Claude Code sont plus faciles à gouverner lorsque la réponse désigne des responsables. Les développeurs peuvent expliquer la tâche, les équipes de plateforme peuvent appliquer les conventions des dépôts, et les propriétaires de services peuvent remplacer les identifiants d’accès. Le personnel de sécurité ne devrait pas avoir à reconstituer toutes ces relations au cours d’une enquête.

Le changement organisationnel concret est un périmètre d’examen élargi. Les équipes doivent inspecter ce que l’assistant laisse derrière lui en même temps que ce qu’il modifie. Cela fait de l’état persistant de l’agent une composante de la gouvernance normale de l’ingénierie.

Qu’est-ce qui démontrerait que la voie d’exposition se referme ?

Les prochaines preuves utiles devraient apparaître dans le comportement du produit, les contrôles des dépôts et les résultats de remédiation. Ces signaux traitent différentes parties de la séquence signalée. Ensemble, ils peuvent montrer si la voie d’exposition initiale devient plus difficile à reproduire.

Les progrès doivent être mesurés par la persistance empêchée et la réduction de l’autorité des identifiants. Le langage des annonces ne peut, à lui seul, établir aucun de ces résultats. Les preuves les plus solides relieront une protection précise à un changement observable.

Premièrement, surveillez une version documentée de Claude Code qui modifie la manière dont les approbations sensibles sont stockées. Le détail décisif est ce qui se produit lorsqu’une commande par ailleurs légitime contient des éléments d’authentification. Une version devrait expliquer l’enregistrement résultant et les circonstances qui exigent encore une intervention de l’utilisateur.

La preuve que des secrets synthétiques n’apparaissent plus dans les approbations sauvegardées renforcerait l’hypothèse d’une amélioration significative du produit. La preuve que les mêmes valeurs subsistent via un autre parcours d’autorisation limiterait cette conclusion. Ces deux résultats sont plus informatifs qu’une déclaration générale sur une automatisation plus sûre.

La portée des tests importe autant que le comportement mis en avant. Un projet vierge et un dépôt contenant déjà un fichier de paramètres suivi représentent des conditions de départ différentes. Un compte rendu clair devrait indiquer quelles conditions la protection couvre.

Deuxièmement, surveillez des contrôles de dépôt qui démontrent une couverture de la configuration des agents et des identifiants intégrés aux commandes. Cela comprend des politiques d’exclusion claires et une détection des secrets testée. Le résultat significatif est de savoir si une tentative de publication est arrêtée ou orientée vers une revue efficace.

Un document de politique seul laisse l’exécution incertaine. Un exercice contrôlé montrant que des identifiants artificiels déclenchent la réponse attendue apporte une preuve plus solide. Des échecs répétés réduiraient la confiance dans l’analyse comme contrôle compensatoire.

Ce signal compte également pour les concurrents. Les fournisseurs peuvent décrire les environnements d’exécution différemment tout en devant expliquer leurs artefacts conservés. Une documentation claire des fichiers générés, des limites de partage et du traitement des identifiants rendrait les comparaisons plus utiles aux acheteurs.

Troisièmement, surveillez les rapports de remédiation qui distinguent les fichiers supprimés des identifiants invalidés. L’apparence d’un dépôt est facile à observer, tandis que la persistance de l’accès exige des informations du service responsable. Un suivi crédible devrait maintenir ces résultats distincts.

Les résultats d’Apiiro n’ont pas été reproduits indépendamment ici, et sa collecte ne doit pas être considérée comme un échantillon aléatoire de l’ensemble des projets Claude Code. La population signalée se compose de fichiers publiquement découvrables. Cela limite les conclusions sur la prévalence de l’exposition dans l’ensemble plus large des utilisateurs.

Ces limites ne changent rien à la préoccupation centrale d’ingénierie. Une fonctionnalité qui préserve le contexte opérationnel a besoin d’une politique claire pour les données sensibles. Les utilisateurs devraient pouvoir comprendre cette politique sans reconstituer l’implémentation en pleine échéance.

Pour les équipes qui évaluent les fuites de secrets de Claude Code, commencez par l’enregistrement d’approbation réellement créé par votre flux de travail. Utilisez des identifiants synthétiques pour examiner ce qui persiste, puis vérifiez quels contrôles empêchent ce contenu d’atteindre un dépôt partagé. Attribuez les responsabilités avant qu’une exposition réelle ne force le problème. Conservez les conclusions sous forme de procédures que les collègues peuvent suivre sans reproduire de valeurs sensibles. Lorsque de véritables identifiants apparaissent dans du contenu partagé, faites de leur autorité restante la première question posée au propriétaire du service responsable. Demandez aux fournisseurs des preuves qui traitent le stockage autant que l’exécution. La prochaine revue la plus utile est celle qui répond à une question concrète : après l’exécution d’une tâche approuvée, quelles informations sensibles subsistent, et qui peut y accéder ?