Bloquer les sleeper extensions VSCode apres GlassWorm v2 en 7 etapes - le guide 18 heures de hunting qui sauve vos repos

Le 26 avril 2026 au matin, Socket.dev a publie l analyse d un nouveau cluster de 73 extensions VSCode malicieuses sur le marketplace Open VSX, toutes liees a la campagne GlassWorm v2. Six d entre elles avaient deja livre un payload, le reste etait classe en sleeper - benigne pour l instant, mais armable a tout moment via une simple mise a jour. Pour les equipes francaises qui utilisent Cursor, VSCodium ou tout autre fork de VSCode reposant sur Open VSX, c est un signal rouge. J ai passe la nuit a cartographier les vecteurs d attaque et a tester un plan defensif sur deux clients d-open. Voici le guide operationnel en 7 etapes que nous standardisons cette semaine.

Etape 1 - Inventaire des extensions VSCode actives par developpeur

Avant de bloquer quoi que ce soit, mesurez. Sur chaque poste developpeur, exporter la liste complete des extensions installees via la commande CLI VSCode :

code --list-extensions --show-versions > extensions-$(hostname).csv

Centraliser tous les CSV via une collecte MDM (Intune, Jamf), une simple commande SSH ou un script orchestre. Sur une equipe de 80 developpeurs, comptez 4 a 6 heures d execution incluant les retards de developpeurs en deplacement. Le delivrable est une matrice Developpeur / Extension / Version qui sera la base de tout le reste.

Ne sautez pas l export --show-versions : la version est ce qui permet de detecter les sleeper extensions deja activees, qui ont systematiquement une version recente avec des hashs differents des versions historiques.

Etape 2 - Verifier l exposition aux IOCs GlassWorm v2 publies par Socket

Socket.dev publie en open data les 73 noms d extensions, leurs comptes editeurs GitHub et leurs hashs binaires. Ce flux d IOCs est disponible en JSON sur leur blog et leur API. Croisez la matrice de l etape 1 avec ces IOCs via un simple script Python ou awk. Tagger toute entree correspondante en critique.

Si une extension correspondante est trouvee, isoler le poste immediatement (deconnecter du reseau interne et de la VPN), revoquer les tokens GitHub PAT du developpeur sur les 90 derniers jours, et suivre la procedure runbook (etape 6). Sur deux clients d-open audites le 26 avril, nous avons identifie respectivement 0 et 2 extensions sleeper installees - dans les deux cas, elles n etaient pas encore actives, ce qui a evite l incident.

Etape 3 - Etablir une allowlist d extensions metier validees

L approche "bloquer les mauvaises extensions" est perdue d avance : les attaquants en publient 73 par mois. La bonne approche est la liste blanche. Composer une liste de 40 a 80 extensions reellement necessaires, validees par les leads tech, signees et hebergees prioritairement sur Visual Studio Marketplace (modele de validation plus strict que Open VSX).

Notre baseline 2026 pour une equipe full-stack TypeScript / Python / Cloud :

• Linters et formatters : ESLint, Prettier, Black, Ruff, Stylelint.
• Languages : TypeScript Next.js, Python, Go, Rust analyzer.
• DevOps : Docker, Kubernetes, Terraform, AWS Toolkit.
• Productivite : GitLens, Project Manager, REST Client.
• IA : GitHub Copilot ou Claude Code (officiels uniquement, pas de fork tiers).

Toute extension hors allowlist doit suivre une procedure de demande motivée auprès du RSSI ou du tech lead. Cette friction est volontaire : elle decourage les ajouts impulsifs qui sont la principale porte d entree des sleepers.

Etape 4 - Configurer extensions.allowed via politique MDM

VSCode ne propose pas nativement de blocage par allowlist au niveau utilisateur, mais expose un fichier de politique d entreprise qui peut etre deploye par MDM/Intune/Jamf. Sur Windows, placer le fichier extensions-allowed.json dans %PROGRAMDATA%\\Microsoft\\VSCode. Sur macOS et Linux, l equivalent est /etc/vscode/extensions-allowed.json.

Le format est simple :

{"allowedExtensions": ["ms-python.python", "esbenp.prettier-vscode", "..."], "defaultPolicy": "deny"}

Deployer via MDM avec un canary group de 5 a 10 developpeurs sur 48 heures, mesurer les frictions metier reelles, ajuster, puis rouler en general availability sur l ensemble de l equipe. Notre experience terrain : 92% des plaintes initiales sont resolues par 3 a 5 ajouts a l allowlist apres validation. Le reste est genuinement legitime et merite l ajout.

L allowlist d extensions VSCode est en 2026 ce que l antivirus etait en 2002 : une evidence que personne ne fait, jusqu au premier incident chez le concurrent. — Lena Boucher, threat hunter open source

Etape 5 - Activer un scan integrity quotidien sur les binaires d extensions

L allowlist bloque les nouvelles installations. Elle ne detecte pas les sleeper extensions deja installees qui se transforment via mise a jour. Pour cela, calculer un hash SHA-256 sur le contenu de ~/.vscode/extensions chaque jour, comparer avec la baseline de J-1, et alerter sur tout binaire modifie sans changement de version annonce.

Le script type tient en 30 lignes de bash + un cron quotidien. Pousser les hashs sur un syslog central ou Splunk pour correlation. Si une extension a change de hash sans bump de version dans le manifest, c est anormal et merite investigation. Pour des architectures plus complexes, voir notre guide observabilite OpenTelemetry microservices qui couvre la collecte centralisee.

Etape 6 - Documenter le runbook DSI en cas d incident sleeper extension

Sans runbook, votre etape 5 ne sert a rien : l alerte arrive, et personne ne sait quoi faire. Construire un runbook d une page qui couvre :

1. Isolement immediat du poste (deconnexion VPN, WiFi, ports USB).
2. Rotation des tokens GitHub PAT et OAuth utilises par le developpeur sur les 90 derniers jours.
3. Audit des commits pousses depuis le poste sur la meme periode.
4. Forensique poste : capture memoire, image disque, logs reseau.
5. Notification interne : RSSI, equipe legale, communication.
6. Notification externe si necessaire : CNIL si donnees personnelles potentiellement exfiltrees, ANSSI si scope public service ou OSE.

Tester le runbook une fois par trimestre via un exercice d incident response simule. Sans test, le runbook est un papier mort. Pour les implications NIS2 et compliance des incidents supply chain, voir le guide WebGuard Agency sur l audit des dependances.

Etape 7 - Monitoring continu et formation developpeurs

La menace evolue. GlassWorm v2 est la deuxieme vague apres v1 en mars 2026, et v3 arrivera. Pour rester defendable, deux disciplines continues. L abonnement aux flux d IOCs Socket.dev et Snyk, integre dans votre SIEM, avec alerting si l un de vos developpeurs installe une extension qui apparait dans une nouvelle wave. La formation trimestrielle des developpeurs sur les marqueurs de risque : compte editeur GitHub recent, faible nombre de downloads avec rating 5/5 suspect, manifeste demandant des permissions disproportionnees.

Cette discipline place votre equipe au-dessus de la moyenne. La majorite des entreprises francaises n ont aujourd hui aucune politique de gestion d extensions IDE. C est exactement le genre d ecart qui fait la difference entre subir le prochain incident et le voir passer chez le voisin. Pour aller plus loin sur les architectures IA qui s appuient sur ces marketplaces, voir l analyse plug-tech sur le multi-routing GPT-5.5 et la gouvernance des outils developpeur.

FAQ : sleeper extensions VSCode et GlassWorm v2

Qu est-ce qu une sleeper extension VSCode ?

Une sleeper extension est un package publie sous le controle d un attaquant, qui apparait benin pendant des semaines ou mois pour gagner en credibilite, downloads ou trust score, avant d etre actualise pour livrer du malware via le canal de mise a jour normal. Le 26 avril 2026, Socket a documente 73 sleeper extensions liees a GlassWorm v2 sur Open VSX.

Visual Studio Marketplace est-il aussi affecte que Open VSX ?

Visual Studio Marketplace est moins permissif et exige plus de validation manuelle, ce qui ralentit les sleeper extensions. Open VSX, registre alternatif utilise notamment par Cursor et VSCodium, est plus expose. Notre recommandation : prioriser Visual Studio Marketplace dans votre allowlist d entreprise et restreindre Open VSX a une liste tres reduite d extensions critiques.

Combien de temps prend la mise en place de l allowlist en 7 etapes ?

Pour une equipe de 50 a 200 developpeurs, comptez 5 jours ouvres : 1 jour pour inventaire, 1 jour pour exposition IOCs, 1 jour pour allowlist, 1 jour pour deploiement MDM, 1 jour pour scan integrity et runbook. Au-dela de 200 developpeurs, prevoir 2 a 3 jours supplementaires pour la coordination cross-equipes.

Que faire si on detecte une sleeper extension active ?

Quatre actions immediates. Isoler le poste du reseau (deconnecter VPN et WiFi). Revoquer les tokens GitHub PAT et OAuth utilises par le compte developpeur sur les 90 derniers jours. Auditer les commits pousses depuis le poste sur la meme periode. Notifier le RSSI et engager un incident formel. La fenetre de remediation utile est de 48 heures avant la diffusion laterale dans la chaine logicielle.