Une version de l’outil de codage d’IA dans le registre npm d’Anthropic comprenait un fichier de carte source, qui mène au code source propriétaire complet.
Un employé d’Anthropic a accidentellement exposé l’intégralité du code source propriétaire de son outil de programmation d’IA, Claude Code, en incluant un fichier de carte source dans une version de l’outil publiée sur le compte de registre ouvert npm d’Anthropic, une erreur risquée, déclare un expert en IA.
« Une carte source compromise constitue un risque pour la sécurité », a déclaré Joseph Steinberg, expert américain en cybersécurité et en IA. « Un pirate informatique peut utiliser une carte source pour reconstruire le code source d’origine et (voir) comment il fonctionne. Tous les secrets contenus dans ce code – si quelqu’un a codé une clé API, par exemple – sont en danger, tout comme toute la logique. Et toutes les vulnérabilités trouvées dans la logique pourraient devenir claires pour le pirate informatique qui peut alors exploiter les vulnérabilités. «
Mais ce n’était pas la première fois que cela se produisait ; selon Fortune et d’autres sources d’information, la même chose s’est produite le mois dernier.
N’exposez pas les fichiers .map
Les fichiers de cartes ne doivent pas être laissés dans la version finale du code publiée sur les registres open source, où n’importe qui peut télécharger un package ; ils peuvent être des sources d’informations utiles pour les pirates.
Selon le développeur Kuber Mehta, qui a publié un blog sur le dernier incident, lorsque quelqu’un publie un package JavaScript/TypeScript sur npm, la chaîne d’outils de construction génère souvent des fichiers de carte source (fichiers .map). Ces fichiers constituent un pont entre le code de production minifié/groupé et la source originale ; ils existent de telle sorte que lorsque quelque chose plante en production, la trace de la pile peut pointer vers la ligne de code dans le fichier, et non vers une référence inintelligible.
Qu’est-ce qui est disponible dans ces fichiers ? « Chaque fichier. Chaque commentaire. Chaque constante interne. Chaque invite système. Tout cela, dans un fichier JSON que npm sert volontiers à quiconque exécute npm pack ou même parcourt simplement le contenu du package », a déclaré Mehta.
« L’erreur est presque toujours la même : quelqu’un oublie d’ajouter *.map à son ou ne configure pas son bundler pour ignorer la génération de la carte source pour les versions de production », a déclaré Mehta. « Avec le bundler de Bun (que Claude Code utilise), les cartes sources sont générées par défaut, sauf si vous les désactivez explicitement. »
Considérez une carte source comme un fichier qui montre ce que font les parties d’un code informatique réduit, qui n’est pas facilement compréhensible pour les humains, montrées dans le code source lisible par l’homme, a déclaré Steinberg. Par exemple, a-t-il déclaré, cela peut indiquer que le code dans une partie spécifique du code exécutable exécute les instructions qui apparaissent dans un extrait spécifique du code source.
Une carte source peut aider au débogage, a-t-il ajouté. Sans cela, a-t-il déclaré, de nombreuses erreurs seraient identifiées comme provenant d’une plus grande partie du code, plutôt que de montrer exactement où elles se produisent.
Le monde a appris cet incident lorsque le chercheur en sécurité Chaofan Shou a publié ce message tôt mardi sur X : « Le code source de Claude a été divulgué via un fichier de carte dans leur registre npm ! », accompagné d’un lien vers le fichier.
Une erreur courante
Laisser les fichiers de mappage source dans un package « est une erreur incroyablement courante que les développeurs commettent assez souvent », a déclaré Tanya Janca, formatrice en codage sécurisé. « Dans cette situation spécifique, la situation est plus grave qu’elle ne le serait ailleurs, principalement en raison de la valeur incroyablement élevée de la propriété intellectuelle impliquée et parce que désormais les acteurs malveillants peuvent analyser directement le code source pour détecter les vulnérabilités au lieu d’avoir à procéder à une ingénierie inverse, ce qui ajoute du temps, des coûts et de la complexité.
Idéalement, a déclaré Janca, les développeurs devraient renforcer leur environnement de construction, afin de ne pas envoyer d’informations/fonctionnalités de débogage avec la production. Elle a proposé ces conseils aux développeurs :
- désactiver les mappages sources dans l’outil build/bundler ;
- ajoutez le fichier .maps au champ files pour l’exclure explicitement, même s’il a été généré par accident lors de la construction ;
- exclure les fichiers .maps de la liste des artefacts publiés dans l’environnement d’intégration continue/déploiement continu ;
- séparez soigneusement les versions de débogage des versions de production s’il existe des différences ; même les commentaires pourraient être incroyablement sensibles.
Une couche critique
Toute exposition du code source ou de la logique au niveau du système est importante, car elle montre comment les contrôles sont mis en œuvre, a commenté Dan Schiappa, président de la technologie et des services chez Arctic Wolf. Avec ces informations exposées, le nombre de personnes qui comprennent désormais comment le modèle applique le comportement, gère l’accès et gère les cas extrêmes, a-t-il déclaré.
« Dans les systèmes d’IA, cette couche est particulièrement critique », a-t-il ajouté. « L’orchestration, les invites et les flux de travail définissent efficacement le fonctionnement du système. Si ceux-ci sont exposés, il peut être plus facile d’identifier les faiblesses ou de manipuler les résultats. Sachant que les attaquants sont encore en train de découvrir les moyens les plus optimaux d’exploiter l’IA, cela signifie que dans chaque cas où un outil pourrait être compromis, il y a probablement des cybercriminels qui attendent dans les coulisses. «
