Chaîne d'approvisionnement des extensions IDE : comment vérifier une extension VS Code avant de l'installer

La plupart d’entre nous installons une extension d’IDE comme on installait autrefois des barres d’outils de navigateur : un clic, un coup d’œil au nombre d’étoiles, et c’est réglé. Sauf qu’une extension s’exécute dans votre éditeur, avec vos fichiers, votre terminal et souvent votre configuration git et SSH à portée de main. Le badge de l’éditeur vous dit qui l’a publiée, une fois. Il ne vous dit pas ce que fait la mise à jour arrivée sur votre machine ce matin. Voici comment vérifier une extension avant de lui faire confiance, ce que chaque contrôle détecte et l’endroit où chacun cesse de fonctionner.

Avant de lire : Le guide sur les permissions des extensions Chrome couvre la même question de confiance pour les modules de navigateur, et le guide sur le bac à sable des agents IA explique ce qui se passe quand une extension peut joindre le réseau. Vous n’avez besoin ni de l’un ni de l’autre pour suivre ce texte, mais les deux précisent le modèle de menace.

Pourquoi maintenant : Des reportages de cette semaine affirment qu’une version malveillante de l’extension Claude Code d’Anthropic a été offerte pendant des heures sur la place de marché de Cursor. Je n’ai pas pu confirmer ces détails auprès des reportages d’origine en rédigeant ce texte; l’incident sert donc d’exemple, pas de preuve.

Table des matières

• Le badge est un reçu, pas une garantie
• Quatre vérifications avant la mise à jour
• Comparatif des contrôles
• Là où la méthode montre ses limites
• Faits saillants
• Sources

Le badge est un reçu, pas une garantie

Un badge d’éditeur vérifié indique que quelqu’un a contrôlé une identité à un moment donné. Pensez-y comme à un videur qui vous a demandé une pièce d’identité en mars. Il ne dit rien sur qui détient les clés aujourd’hui. Si un attaquant prend le contrôle d’un compte d’éditeur de confiance, la version suivante qu’il publie porte le même nom, la même icône et le même badge, et quiconque a les mises à jour automatiques l’obtient sans aucune invite.

Les noms sont l’autre point faible. Tous les développeurs ont déjà cherché un formateur dans une place de marché et fait défiler trois fiches presque identiques avant de trouver la bonne. Les attaquants comptent sur ce défilement.

Les forks ajoutent une deuxième question. Cursor et d’autres forks de VS Code ne tirent pas toujours leurs extensions du même magasin que celui de Microsoft. Avant de faire confiance à une fiche, vérifiez quel registre votre éditeur utilise réellement, parce que les règles dont il est question ici s’appliquent à ce registre et à aucun autre.

Quatre vérifications avant la mise à jour

1. Récupérez le paquet, pas la fiche. Un fichier .vsix est une archive ZIP. Téléchargez la version exacte que vous voulez installer et listez son contenu :

unzip -l example-publisher.example-tool-1.4.2.vsix

Tout ce que l’éditeur va exécuter se trouve sous extension/. Commencez par extension/package.json et lisez quatre champs : publisher, repository, main et activationEvents. Une entrée activationEvents de * signifie que l’extension se charge au démarrage, avant que vous ayez ouvert le moindre fichier. Un champ repository absent, ou qui pointe vers un projet sans commit récent, mérite une note, pas un verdict.

2. Comparez la version que vous avez à celle que vous allez recevoir. La plupart des mises à jour suspectes sont petites : une nouvelle dépendance, un nouvel hôte réseau, un appel de plus à child_process. Décompressez les deux versions et comparez-les :

unzip -q old.vsix -d old && unzip -q new.vsix -d new
diff -rq old/extension new/extension

Listez ensuite chaque URL mentionnée dans le nouveau build :

grep -rhoE 'https?://[A-Za-z0-9._/-]+' new/extension | sort -u

Un hôte qui n’apparaît que dans la nouvelle version est la question à régler avant de cliquer sur Mettre à jour. Les paquets minifiés rendent le diff bruyant : commencez donc par la liste des dépendances dans package.json, puis regardez le paquet lui-même.

3. Cherchez les comportements dont une extension d’éditeur a rarement besoin. Un formateur n’a aucune raison d’écrire dans votre dossier personnel. Ce motif attrape la plupart des chemins de code qui comptent pour une porte dérobée :

grep -rnE 'child_process|authorized_keys|[.]ssh|new Function|eval[(]' new/extension

Attendez-vous à des faux positifs. Beaucoup d’outils légitimes appellent child_process pour lancer git. Un résultat est une question posée au code, pas un verdict. Un résultat sur authorized_keys, en revanche, mérite qu’on s’arrête.

4. Prenez un instantané du disque autour de l’installation. L’analyse statique rate tout ce qui est récupéré à l’exécution, donc vérifiez ce que l’éditeur a modifié. Sur macOS et Linux :

ls -la ~/.ssh && cat ~/.ssh/authorized_keys

Faites-le avant l’installation, puis de nouveau après. Sous Windows, le même dossier se trouve dans votre répertoire %USERPROFILE%, dans son sous-dossier .ssh. Un nouveau fichier de clé ou un authorized_keys modifié est le signal le moins coûteux de toute cette méthode, et il prend quelques secondes.

5. Épinglez ce qui touche à vos identifiants. L’épinglage empêche la mise à jour silencieuse qui livre un mauvais build, mais il bloque aussi le correctif de sécurité suivant. Le compromis est réel. Ma règle : épingler les extensions qui peuvent lire vos fichiers, votre terminal ou vos jetons, et laisser les thèmes et les jeux d’icônes se mettre à jour seuls. Pour installer une version précise, la forme en ligne de commande est code --install-extension publisher.name@version. Exécutez code --help sur votre build pour confirmer les options, car je ne les ai pas vérifiées sur la version actuelle.

Comparatif des contrôles

Aucun contrôle ne suffit seul, et chacun a un angle mort que d’autres couvrent. Ce tableau est celui que je collerais sur mon écran.

Contrôle	Détecte	Angle mort
Badge de l’éditeur et âge de la fiche	Noms trompeurs venant d’éditeurs récents	Un compte de confiance qui a été détourné
Diff de version	Nouveaux hôtes, dépendances et appels dans une mise à jour	Une première version malveillante, sans base de comparaison
Recherche statique (grep)	Motifs shell, SSH et eval dans le code clair	Code obfusqué et charges récupérées à l’exécution
Instantané du disque	Fichiers et clés écrits par l’extension	Tout ce qui reste en mémoire ou est préparé pour plus tard
Surveillance des connexions sortantes	Connexions vers des hôtes que vous n’avez jamais autorisés	Code dormant qui attend une date ultérieure

Les deux premières lignes décrivent le chemin qu’emprunte une mise à jour compromise pour entrer dans votre éditeur. Les trois dernières décrivent ce qui se passe une fois qu’elle est arrivée. Le guide sur le bac à sable couvre en détail la ligne des connexions sortantes, et c’est celle que la plupart des gens sautent.

Là où la méthode montre ses limites

Personne ne lit le paquet d’un formateur ligne par ligne un mardi après-midi. La plupart des développeurs feront les étapes un et trois, sauteront la deux et feront confiance au reste. C’est une dose de paranoïa raisonnable pour un thème, et nettement insuffisante pour une extension qui peut voir vos clés de production. La version honnête de ce guide dit ceci : choisissez les extensions qui touchent aux identifiants, soumettez-les à la procédure complète, et acceptez le risque pour le reste.

La limite plus profonde, c’est qu’un audit de paquet décrit ce que l’extension contient, pas ce qu’un serveur lui enverra la semaine prochaine. Le filtrage des places de marché aide, mais une fois le paquet installé, le travail de vérification vous revient.

Faits saillants

• L’archive à la vue de tous : Un fichier .vsix est un ZIP. Si vous pouvez exécuter unzip, vous pouvez lire le code source d’une extension avant votre éditeur.
• Cinq secondes de preuves : Une extension qui écrit une clé SSH laisse un fichier dans votre dossier .ssh. Un simple ls le montre, sans outil de sécurité.
• Votre éditeur est un programme au niveau utilisateur : Les extensions s’exécutent en général avec les droits de votre compte, ce qui explique que vos clés SSH et vos jetons git soient à portée du code que vous avez installé pour avoir un linter.

Sources

• BleepingComputer, reportage sur une extension Claude Code malveillante distribuée via Cursor (cité d’après le bref de l’agence, non consulté directement) : https://www.bleepingcomputer.com/news/security/malicious-claude-code-extension-on-cursor-planted-ssh-backdoors/
• Ars Technica, reportage sur le même incident (cité d’après le bref de l’agence, non consulté directement) : https://arstechnica.com/security/2026/10/anthropic-vs-code-extension-on-cursor-backdoored-for-nearly-12-hours/
• Documentation de VS Code et de la place de marché Visual Studio, pour les options de la CLI et la vérification des éditeurs : non consultée pour cet article; confirmez avant de vous fier à la syntaxe d’installation ci-dessus.