Auditer son marketplace VSCode entreprise apres GlassWorm en 8 etapes - le guide 5 jours qui sauve vos repos

Etape 1 - Inventaire central des extensions installees via MDM

Avant tout, mesurer. Sur chaque poste developpeur, exporter la liste complete via la commande code --list-extensions --show-versions. Centraliser via Intune, Jamf, ou MDM equivalent. La sortie est un CSV contenant Hostname, User, Extension ID, Version. Sur 80 developpeurs, comptez 4 a 6 heures pour la collecte complete. Le delivrable est une matrice unique partagee par les equipes SOC, DevOps et RSSI.

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 hashs differents des versions historiques.

Etape 2 - Croisement avec IOCs Socket et Snyk pour detection

Socket.dev publie en open data les 145 noms d extensions GlassWorm v1+v2 cumulees, avec leurs comptes editeurs GitHub et hashs binaires. Snyk publie un flux IOCs complementaire pour les extensions a risque. Croiser via script Python ou awk. Tagger toute correspondance en critique et passer immediatement a l etape 6 pour ces postes.

Ne pas se limiter aux IOCs GlassWorm : utiliser aussi le flux Snyk Vulnerabilities qui couvre les extensions populaires avec CVE recents. La couverture est plus large et permet de detecter d autres campagnes en cours.

Etape 3 - Etablir l allowlist d extensions metier validees

L approche "bloquer les mauvaises extensions" est perdue d avance. La bonne approche est la liste blanche. Composer une liste de 40 a 80 extensions metier validees, signees, prioritaires sur Visual Studio Marketplace. 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 suit une procedure de demande motivée auprès du tech lead. Cette friction est volontaire : elle decourage les ajouts impulsifs qui sont la principale porte d entree des sleepers.

Etape 4 - Deploiement allowlist via politique MDM

VSCode expose un fichier de politique d entreprise. Sur Windows, placer extensions-allowed.json dans %PROGRAMDATA%\Microsoft\VSCode. Sur macOS et Linux, l equivalent est /etc/vscode/extensions-allowed.json. Format :

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

Deployer via MDM avec un canary group de 10 developpeurs sur 48 heures, mesurer les frictions metier reelles, ajuster, puis general availability. Notre experience : 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.

Etape 5 - Scan integrity quotidien sur les binaires d extensions

L allowlist bloque les nouvelles installations mais ne detecte pas les sleeper extensions deja installees qui se transforment via mise a jour. Pour cela, calculer un hash SHA-256 sur ~/.vscode/extensions chaque jour, comparer avec la baseline J-1, 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 sur d-open.org.

L allowlist VSCode est en 2026 ce que l antivirus etait en 2002 : une evidence que personne ne fait, jusqu au premier incident chez le concurrent. Le rythme GlassWorm v1 puis v2 ne laisse plus le luxe d attendre. — Marc Lehmann, Senior Security Engineer SOC WebGuard

Etape 6 - Procedure d isolation et incident response

Pour tout poste contenant une extension malicieuse identifiee, executer immediatement :

1. Isolement reseau : deconnecter VPN, WiFi, ports USB. Conserver l etat memoire pour forensique.
2. Rotation tokens : revoquer GitHub PAT, OAuth tokens (Slack, Notion), AWS keys, GCP keys utilises sur les 90 derniers jours.
3. Audit commits : examiner les commits pousses depuis le poste sur la meme periode pour detecter une injection laterale.
4. Forensique poste : capture memoire (Magnet RAM Capture ou WinPMEM), image disque (FTK Imager), logs reseau via journal proxy.
5. Notification interne : RSSI, equipe legale, communication. Documenter chronologie pour audit ulterieur.

Etape 7 - Runbook DSI et notification reglementaire NIS2/DORA

Pour les operateurs francais sous NIS2 (operateurs essentiels et importants) ou DORA (secteur financier), une exfiltration confirmee depuis une extension malicieuse declenche potentiellement des obligations de notification incident sous 24 heures. Preparer en avance :

• Template de communication ANSSI : modele d email pre-redige avec champs a remplir.
• Template de communication CNIL si donnees personnelles potentiellement exfiltrees.
• Chaine d alerte interne : RSSI, DSI, COMEX, communication, juridique avec contacts H24 et delais d escalade.
• Procedure de communication clients si l incident a un impact externe (delais reglementaires DORA art. 19).

Tester le runbook une fois par trimestre via un exercice incident response simule. Sans test, le runbook est un papier mort. Pour les implications NIS2 plus larges sur la chaine logicielle, voir notre analyse audit dependances npm en 8 etapes.

Etape 8 - Monitoring continu et formation developpeurs trimestrielle

La menace evolue. GlassWorm v2 est la deuxieme vague apres v1, 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 automatique. 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. Pour completer cette posture supply chain, voir notre analyse CVE-2026-6951 simple-git RCE sur d-open et les implications GPT-5.5 sur Plug-Tech. Les architectures multi-LLM en production exigent la meme discipline supply chain que les marketplaces VSCode.

Cout total et ROI de la procedure 8 etapes

Pour une ETI francaise de 80 developpeurs, le sprint complet coute environ 8 000 EUR en cout interne (1,5 ETP semaine + outillage MDM/SIEM existant) ou 15 000 a 22 000 EUR en sprint externalise. Compare au cout d un incident GlassWorm reussi (rotation tokens, forensique, 3 a 6 mois de remediation lateral movement, atteinte reputationnelle), le ROI defensif est immediat. Notre observation terrain : les ETI qui ont execute cette procedure en avril 2026 sont passees au travers de v2 sans incident.

FAQ : audit marketplace VSCode entreprise

Combien de temps prend l audit complet en 8 etapes ?

Pour une fleet de 50 a 200 developpeurs, comptez 5 jours ouvres : 1 jour pour inventaire et IOCs, 1 jour pour allowlist, 1 jour pour MDM, 1 jour pour scan integrity, 1 jour pour runbook DSI et formation. Au-dela de 200 developpeurs, prevoir 8 a 12 jours pour la coordination cross-equipes et le pilote canary.

Quelle est la difference entre Visual Studio Marketplace et Open VSX ?

Visual Studio Marketplace de Microsoft impose une revue manuelle pour les extensions a forte permission, des checks anti-typosquatting et une signature obligatoire des publishers. Open VSX, registre alternatif Eclipse Foundation utilise par Cursor, VSCodium et Theia, dispose de moins de ressources de moderation. C est exactement ce que GlassWorm v1 et v2 exploitent. Notre recommandation : prioriser Visual Studio Marketplace dans votre allowlist d entreprise.

Comment gerer la remontee NIS2 ou DORA en cas d incident ?

Pour NIS2, le delai de notification initial a l ANSSI est de 24 heures pour les operateurs essentiels. Pour DORA, l art. 19 impose une notification a l autorite competente dans les 4 heures pour les incidents majeurs. Preparer en avance des templates pre-redigees, documenter une chaine d alerte interne avec contacts H24, et tester le runbook trimestriellement pour eviter la decouverte des trous le jour J.

Quelle est la prochaine campagne attendue apres GlassWorm v2 ?

GlassWorm v3 est tres probable courant mai 2026, sur le meme rythme mensuel. D autres campagnes paralleles cibleront les marketplaces JetBrains Plugin Repository, Chrome Web Store et Firefox Add-ons. La defense durable est l approche allowlist organisationnelle plutot que la reaction par vague d incidents. Anticiper plutot que rattraper.