Installer des outils de code par IA sans se fier au nom d’un paquet

Un nom de produit familier n’est pas l’identité d’un éditeur

Le paquet dit « Claude ». Qui va pouvoir exécuter du code sur votre machine ? Installer sans risque un outil de code par IA commence par établir cette relation, avant de lui donner accès à un dépôt ou à des identifiants. Un nom sur npm, une description convaincante et un mot de produit reconnaissable ne prouvent pas que l’éditeur de ce produit l’a autorisé.

Le 19 octobre 2026, GitHub a publié des avis de malware pour les huit noms de paquets npm sur le thème de l’IA listés ci-dessous. Ces avis sont une raison d’enquêter sur une installation, pas la preuve que les produits officiels Claude, Codex ou ChatGPT ont été compromis. Ce guide s’appuie sur les avis publiés et la documentation officielle ; il ne revendique ni analyse du malware ni exécution d’échantillon. [1][2][3]

Flagged package names; do not install

claude-desktop-setup       @decoopus/claude-setup
codex-setup                chatgpt-desktop-setup
@decoopus/chatgpt-setup     chatgpt-pro-activator
chatgpt-pro-setup-tool     api-anthropic

Un retrait ne nous dit pas ce que faisait le payload

Les avis examinés identifient le malware mais ne fournissent aucune analyse comportementale pour ce groupe. Au 20 octobre, les sources examinées ici n’établissent ni quels fichiers ont été lus, ni si un magasin d’identifiants précis a été visé, ni quelle persistance a été installée. Nommer une famille d’infostealers comblerait le vide par un récit plutôt que par des preuves. Les paquets partagent un thème ; cela seul ne prouve pas qu’un même opérateur est derrière. [1][2][3]

Le nombre de téléchargements ne réglerait pas ce problème. Un téléchargement peut être automatisé, répété ou effectué à des fins d’analyse ; ce n’est ni une exécution confirmée ni une personne touchée. Pour une équipe qui évalue sa propre exposition, la preuve solide est le paquet et la version exacts figurant dans les journaux d’installation, l’endroit où il a été installé, et la question de savoir si du code s’est exécuté avec accès à des éléments de valeur. Consignez un état d’exécution inconnu plutôt que de prendre l’absence de télémétrie pour une preuve de sécurité.

Partir de l’éditeur, puis suivre le chemin de distribution

Pour Claude Code, Anthropic documente l’identité npm officielle @anthropic-ai/claude-code et propose aussi des canaux d’installation natifs. Un paquet d’installation au nom ressemblant n’hérite pas de cette relation. C’est une méthode applicable à tout outil de code : partez de la page d’installation documentée par l’éditeur et suivez le canal exact propre à votre plateforme, plutôt que de choisir un paquet dans un résultat de recherche. [4]

Le processus de l’entreprise doit rendre le choix vérifié facile à reproduire. Tenez un court registre des outils approuvés avec l’URL de la documentation, le canal de distribution, l’éditeur attendu, la version retenue et le responsable des mises à jour. Épingler la version d’un paquet rend reproductibles les octets ou la version choisis ; cela ne prouve pas que le choix initial était légitime. Examinez aussi le chemin de mise à jour, car l’installation de demain peut arriver sans que personne ne copie de nouveau une commande.

Proposed approved-tool record

Vendor documentation URL -> exact distribution identity
Version + platform        -> expected artifact
Publisher / signing key   -> trust anchor
Artifact hash             -> recorded bytes
Update mechanism          -> owner and review policy
Runtime permissions       -> separately approved access

Une somme de contrôle exige une référence de comparaison fiable

Une somme de contrôle prouve la concordance entre des octets et une empreinte attendue. Si un distributeur non fiable fournit les deux, la concordance n’établit pas qui les a produits. Anthropic documente des manifestes de version signés à partir de Claude Code 2.1.89, les manifestes plus anciens contenant des sommes de contrôle sans cette signature détachée. Vérifiez le manifeste avec l’empreinte de la clé de signature documentée, puis comparez le binaire de la plateforme choisie au manifeste authentifié. [4]

Sous Windows, les binaires natifs documentés portent aussi une signature Authenticode. Les commandes d’inspection ci-dessous n’exécutent pas le programme. Vérifiez à la fois la validité de la signature et l’identité de l’éditeur attendu, Anthropic, PBC ; un signataire valide quelconque ne suffit pas. Il s’agit d’étapes de vérification documentées, pas du compte rendu d’un binaire téléchargé ou vérifié pour cet article. [4]

# Inspect an already-downloaded binary; do not execute it
Get-AuthenticodeSignature -LiteralPath .\claude.exe |
  Select-Object Status, SignerCertificate
Get-FileHash -LiteralPath .\claude.exe -Algorithm SHA256

# Compare signer and hash with the vendor's documented trust chain.

Une origine vérifiée appelle encore une décision sur les droits

Les contrôles de signature et de provenance répondent à des questions d’origine. Ils ne prouvent pas que le code est exempt de comportement malveillant ou de vulnérabilités. npm le dit explicitement à propos de la provenance : elle relie un paquet à des informations sur son code source et son build pour permettre un examen, sans certifier qu’il est inoffensif. Traitez le résultat comme un élément de preuve parmi d’autres sur l’artefact, pas comme une raison de lui confier tous les identifiants de la machine. [5]

Ma question suivante porte sur ce que le programme installé peut atteindre. Pour un outil de code approuvé, examinez le contenu du dépôt, les variables d’environnement, les magasins d’identifiants et l’accès réseau exposés à son processus. Séparez l’accès de développement des identifiants de production et rendez délibérée toute autorisation supplémentaire. Cette recommandation porte sur l’autorité d’exécution en général ; elle n’affirme pas que les paquets retirés utilisaient une technique de collecte particulière.

Ignorer les scripts d’installation rend-il une CLI sûre ?

L’option ignore-scripts de npm supprime les scripts de package.json pendant l’installation, mais la documentation précise que les scripts demandés explicitement, comme npm run, exécutent toujours leur commande. Ce n’est pas un bac à sable pour un programme lancé ensuite. Une équipe qui bloque les scripts de cycle de vie puis exécute une CLI non vérifiée a pris une autre décision d’exécution. Évaluez cette décision séparément. [6]

Il y a aussi un coût de compatibilité bien réel : des paquets légitimes peuvent nécessiter des étapes d’installation. La réponse est une exception explicite, examinée et justifiée, pas la désactivation globale du contrôle parce qu’un outil échoue. Distinguez, dans le registre d’approbation, l’inspection des métadonnées, l’installation et l’exécution. Chaque étape apporte une preuve différente et peut exposer des capacités différentes ; aucune ne doit discrètement tenir lieu de la suivante.

Si vous avez installé un paquet signalé, préservez les preuves

Les avis de malware recommandent de considérer comme compromise la machine sur laquelle le paquet a été installé et de renouveler les secrets exposés depuis un autre ordinateur. Suivez ces consignes avec votre équipe de réponse aux incidents : isolez l’environnement touché, préservez les journaux d’installation et de processus, et établissez quels identifiants il pouvait atteindre. Supprimer le paquet ne prouve pas, à lui seul, que l’accès ou la persistance qui en résultent ont disparu. [1][2]

C’est délibérément différent de l’affirmation d’un payload précis. On peut prendre le confinement au sérieux tout en restant précis sur ce qui est inconnu. Conservez dans le dossier les identifiants et les versions des paquets, ainsi que les preuves d’exécution et les identifiants examinés. Ne collez pas de valeurs de secrets actifs dans un ticket et n’utilisez pas un poste non fiable pour générer leurs remplaçants.

Faire de l’installation une décision d’ingénierie

Je demanderais à une équipe de démontrer une chaîne complète pour un outil approuvé : l’éditeur renvoie vers ce canal, l’artefact correspond à cette version authentifiée, et le processus reçoit cet accès documenté. Un autre ingénieur peut relire cette chaîne. La capture d’écran d’un logo familier ou un compteur de téléchargements ne peuvent pas la remplacer.

C’est un travail d’ingénierie logicielle sécurisée, car ces choix s’intègrent à l’onboarding, à la CI et à l’automatisation des mises à jour. Si chaque développeur doit reconstruire seul la décision de confiance, l’organisation a délégué un contrôle de sécurité reproductible à un résultat de recherche. Construisez une fois le chemin vérifié, désignez son responsable, et gardez ses droits d’exécution assez restreints pour pouvoir les justifier.