Comment auditer vos extensions VS Code pour la securite supply chain en 7 etapes

Les extensions VS Code sont devenues le vecteur d attaque supply chain le plus exploite de 2026. En mai dernier, le groupe TeamPCP (UNC6780) a compromis les systemes internes de GitHub via une version trojanisee de l extension Nx Console restee en ligne seulement 11 minutes. Plus tot dans l annee, les extensions Glassworm avaient deja demontre la vulnerabilite du Marketplace. Le probleme structurel est clair : les extensions VS Code s executent avec les memes privileges que l utilisateur, sans sandboxing, et les mises a jour automatiques sont activees par defaut. Une seule extension compromise suffit pour exfiltrer vos tokens npm, credentials AWS, cles SSH, et configurations Claude Code.

Ce guide vous donne 7 etapes concretes et actionnables pour auditer vos extensions VS Code, reduire votre surface d attaque supply chain, et mettre en place un processus de securite perenne pour votre equipe. Chaque etape inclut des commandes, des scripts et des configurations que vous pouvez appliquer immediatement. Que vous soyez developpeur solo ou responsable securite dans une equipe de 50 personnes, ce guide s adapte a votre contexte. Nous avions deja couvert la securisation des pipelines dans nos guides pour securiser les pipelines npm et securiser GitHub Actions — ce guide complete le triptyque en couvrant l environnement de developpement local.

Etape 1 : Realiser un inventaire complet de vos extensions installees

La premiere etape de tout audit de securite est la visibilite. Vous ne pouvez pas securiser ce que vous ne connaissez pas. La plupart des developpeurs accumulent des dizaines d extensions au fil du temps — certaines installees pour un projet specifique il y a deux ans et jamais desinstallees, d autres recommandees par un collegue sans verification prealable. L objectif de cette etape est de produire un inventaire exhaustif et structure de toutes les extensions installees sur chaque machine de votre equipe.

Commencez par lister toutes les extensions installees avec leurs versions. Ouvrez un terminal et executez la commande suivante :

# Lister toutes les extensions avec leurs versions
code --list-extensions --show-versions

# Exporter dans un fichier pour analyse
code --list-extensions --show-versions > ~/vscode-extensions-audit.txt

# Compter le nombre total d extensions installees
code --list-extensions | wc -l

# Pour VS Code Insiders
code-insiders --list-extensions --show-versions

Pour une equipe, vous devez centraliser ces inventaires. Voici un script bash qui genere un rapport structure au format CSV, incluant le nom de l extension, la version, l editeur, et la date d installation estimee :

#!/bin/bash
# audit-vscode-extensions.sh
# Script d inventaire des extensions VS Code pour audit securite

echo "extension_id,version,install_date" > vscode-audit-report.csv

EXTENSIONS_DIR="$HOME/.vscode/extensions"

for ext_dir in "$EXTENSIONS_DIR"/*/; do
  if [ -f "$ext_dir/package.json" ]; then
    EXT_NAME=$(jq -r '.publisher + "." + .name' "$ext_dir/package.json" 2>/dev/null)
    EXT_VERSION=$(jq -r '.version' "$ext_dir/package.json" 2>/dev/null)
    INSTALL_DATE=$(stat -c '%Y' "$ext_dir/package.json" 2>/dev/null | \
      xargs -I{} date -d @{} '+%Y-%m-%d' 2>/dev/null || echo "unknown")
    echo "$EXT_NAME,$EXT_VERSION,$INSTALL_DATE" >> vscode-audit-report.csv
  fi
done

echo "Rapport genere : vscode-audit-report.csv"
echo "Total extensions : $(tail -n +2 vscode-audit-report.csv | wc -l)"

Une fois l inventaire realise, examinez-le avec un oeil critique. Identifiez les extensions que vous ne reconnaissez pas, celles que vous n avez pas utilisees depuis longtemps, et celles dont le nombre total vous surprend. La regle empirique : si vous ne savez pas pourquoi une extension est installee, desinstallez-la. Vous pourrez toujours la reinstaller si vous en avez besoin. Un bon objectif pour un developpeur web typique est de maintenir votre nombre d extensions en dessous de 25. Au-dela, chaque extension supplementaire augmente votre surface d attaque sans benefice proportionnel.

Etape 2 : Verifier l authenticite et la fiabilite des editeurs

Chaque extension sur le VS Code Marketplace est publiee par un editeur identifie. La verification de cet editeur est votre premiere ligne de defense contre les extensions malveillantes. Le Marketplace offre un badge "Verified Publisher" pour les editeurs qui ont verifie leur identite — mais attention, meme ce badge n est pas une garantie absolue (l attaque TeamPCP a potentiellement utilise un compte editeur compromis ou une usurpation sophistiquee).

Pour chaque extension de votre inventaire, verifiez les points suivants sur la page Marketplace :

Checklist de verification editeur :

[x] Badge "Verified Publisher" present
[x] Nombre de telechargements > 10 000 (pour les extensions generiques)
[x] Note moyenne >= 4.0 etoiles avec > 50 avis
[x] Derniere mise a jour < 6 mois (extension activement maintenue)
[x] Repository source public et accessible (lien GitHub/GitLab)
[x] L editeur publie d autres extensions connues
[x] Le nom de l extension ne ressemble pas a une autre populaire
    (typosquatting : "prettier" vs "pretier", "eslint" vs "es-lint")
[x] La description et les screenshots sont professionnels
    (pas de fautes grossieres, pas de captures generiques)

Pour automatiser cette verification, vous pouvez utiliser l API du VS Code Marketplace. Voici un script qui verifie le statut de chaque extension de votre inventaire :

#!/bin/bash
# verify-extensions.sh
# Verifie les metadonnees de chaque extension via l API Marketplace

while IFS= read -r ext; do
  PUBLISHER=$(echo "$ext" | cut -d'.' -f1)
  NAME=$(echo "$ext" | cut -d'.' -f2- | cut -d'@' -f1)

  # Requete API Marketplace
  RESPONSE=$(curl -s -X POST \
    'https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery' \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json;api-version=7.1-preview.1' \
    -d "{
      \"filters\": [{
        \"criteria\": [{
          \"filterType\": 7,
          \"value\": \"$PUBLISHER.$NAME\"
        }]
      }],
      \"flags\": 914
    }")

  INSTALLS=$(echo "$RESPONSE" | jq -r '.results[0].extensions[0].statistics[]
    | select(.statisticName=="install") | .value' 2>/dev/null)
  LAST_UPDATED=$(echo "$RESPONSE" | jq -r '.results[0].extensions[0].lastUpdated' \
    2>/dev/null)

  echo "$PUBLISHER.$NAME | Installations: $INSTALLS | Mis a jour: $LAST_UPDATED"
done < <(code --list-extensions)

Portez une attention particuliere aux extensions qui echouent a plusieurs criteres de la checklist. Une extension sans badge de verification, avec peu de telechargements, et sans repository source public est un signal d alerte majeur. Desinstallez-la immediatement et cherchez une alternative mieux etablie. Mefiez-vous egalement des extensions tres populaires dont le compte editeur pourrait avoir change recemment — c est un signe potentiel de compromission de compte (comme dans le cas de TeamPCP).

Etape 3 : Analyser les permissions et les capabilities demandees

Contrairement aux applications mobiles, les extensions VS Code n ont pas de systeme de permissions granulaire visible par l utilisateur. Cependant, le fichier package.json de chaque extension declare ses capabilities et ses activation events — des informations qui revelent ce que l extension peut faire et quand elle s active. Analyser ces declarations est essentiel pour detecter les comportements suspects.

#!/bin/bash
# analyze-extension-permissions.sh
# Analyse les permissions et activation events de chaque extension

EXTENSIONS_DIR="$HOME/.vscode/extensions"

for ext_dir in "$EXTENSIONS_DIR"/*/; do
  PKG="$ext_dir/package.json"
  if [ -f "$PKG" ]; then
    EXT_NAME=$(jq -r '.displayName // .name' "$PKG" 2>/dev/null)

    # Verifier les activation events suspects
    ACTIVATION=$(jq -r '.activationEvents[]? // empty' "$PKG" 2>/dev/null)

    # Flags a surveiller :
    # "*" = s active TOUJOURS (tres suspect sauf pour les themes)
    # "onStartupFinished" = s active au demarrage
    # "onFileSystem:*" = surveille le systeme de fichiers

    if echo "$ACTIVATION" | grep -q "\*\|onStartupFinished"; then
      echo "[ALERTE] $EXT_NAME s active au demarrage ou en permanence"
    fi

    # Verifier les permissions reseau (contributes.configuration)
    HAS_NETWORK=$(jq '.contributes.configuration.properties
      | keys[]?' "$PKG" 2>/dev/null | grep -i "proxy\|url\|endpoint\|server")
    if [ -n "$HAS_NETWORK" ]; then
      echo "[INFO] $EXT_NAME declare des configurations reseau"
    fi

    # Verifier les commandes enregistrees
    CMD_COUNT=$(jq '.contributes.commands | length' "$PKG" 2>/dev/null)
    echo "  $EXT_NAME : $CMD_COUNT commandes, activation: $ACTIVATION"
  fi
done

Les signaux d alerte a surveiller dans l analyse des permissions sont les suivants. Une extension qui s active sur * (tous les evenements) ou onStartupFinished sans raison evidente est suspecte — un formateur de code comme Prettier n a pas besoin de s activer au demarrage, il devrait s activer sur des evenements de langage specifiques. Une extension de theme ou de coloration syntaxique qui declare des permissions reseau est un signal fort. Une extension qui enregistre des FileSystemWatcher sur des repertoires en dehors du workspace (comme ~/.ssh ou ~/.aws) est presque certainement malveillante.

Etape 4 : Desactiver les mises a jour automatiques des extensions

C est l etape la plus impactante de ce guide et la plus simple a mettre en oeuvre. Les mises a jour automatiques des extensions sont le mecanisme exact qui a permis a l attaque TeamPCP de reussir. Quand une extension est mise a jour sur le Marketplace, VS Code telecharge et installe la nouvelle version sans aucune intervention de l utilisateur. Si un compte editeur est compromis et qu une version trojanisee est publiee, elle est automatiquement deployee sur tous les postes des developpeurs qui utilisent cette extension.

Desactivez les mises a jour automatiques immediatement. Ouvrez les settings de VS Code (Ctrl+, ou Cmd+,) et ajoutez ces configurations :

// settings.json de VS Code
{
  // Desactiver les mises a jour automatiques des extensions
  "extensions.autoUpdate": false,

  // Desactiver la verification automatique des mises a jour
  "extensions.autoCheckUpdates": false,

  // Activer le mode restreint par defaut pour les workspaces inconnus
  "security.workspace.trust.enabled": true,
  "security.workspace.trust.startupPrompt": "always",

  // Desactiver la telemetrie (reduit la surface reseau)
  "telemetry.telemetryLevel": "off",

  // Restreindre les extensions qui peuvent s executer en mode non fiable
  "extensions.supportUntrustedWorkspaces": {},

  // Limiter les extensions recommandees automatiquement
  "extensions.ignoreRecommendations": true
}

Desormais, vous devrez mettre a jour vos extensions manuellement. C est un compromis volontaire entre confort et securite. Quand VS Code vous signale qu une mise a jour est disponible, prenez 30 secondes pour verifier le changelog de la nouvelle version sur la page Marketplace avant de l installer. Si la mise a jour est mineure (correction de bug, ajout de theme), installez-la. Si c est une version majeure avec des changements significatifs, attendez 24 a 48 heures apres la publication pour laisser le temps a la communaute de detecter d eventuels problemes. Cette latence volontaire est votre meilleure defense contre les attaques de type TeamPCP ou la version malveillante est retiree en quelques minutes.

Etape 5 : Mettre en place une liste blanche d extensions approuvees

Pour les equipes de developpement, la liste blanche est la mesure de securite la plus structurante. Au lieu de laisser chaque developpeur installer les extensions de son choix, vous definissez une liste d extensions approuvees apres audit, et vous restreignez les installations a cette liste. VS Code offre un mecanisme natif pour cela via le fichier .vscode/extensions.json a la racine de votre repository.

// .vscode/extensions.json — Liste blanche d equipe
// A committer dans le repository du projet
{
  "recommendations": [
    // Langages et formatage
    "esbenp.prettier-vscode",
    "dbaeumer.vscode-eslint",
    "bradlc.vscode-tailwindcss",

    // Git
    "eamodio.gitlens",

    // Docker et conteneurs
    "ms-azuretools.vscode-docker",

    // Tests
    "vitest.explorer",

    // Securite (recommande)
    "snyk-security.snyk-vulnerability-scanner"
  ],
  // Extensions explicitement non recommandees (avertissement si installees)
  "unwantedRecommendations": [
    "formulahendry.code-runner",    // Execute du code arbitraire
    "humao.rest-client"              // Si vous utilisez Postman/Insomnia
  ]
}

Le fichier extensions.json est un mecanisme de recommandation, pas de restriction. Pour une restriction plus forte, vous devez utiliser les politiques de groupe de VS Code (disponibles en entreprise via MDM) ou un script de verification dans votre pipeline CI/CD. Voici un script qui alerte quand un developpeur utilise une extension non approuvee :

#!/bin/bash
# check-approved-extensions.sh
# Compare les extensions installees a la liste approuvee

APPROVED_FILE=".vscode/extensions.json"

if [ ! -f "$APPROVED_FILE" ]; then
  echo "ERREUR: Pas de fichier extensions.json trouve"
  exit 1
fi

# Extraire les extensions approuvees
APPROVED=$(jq -r '.recommendations[]' "$APPROVED_FILE" | tr '[:upper:]' '[:lower:]')

# Lister les extensions installees
INSTALLED=$(code --list-extensions | tr '[:upper:]' '[:lower:]')

# Trouver les extensions non approuvees
UNAPPROVED=""
while IFS= read -r ext; do
  if ! echo "$APPROVED" | grep -qF "$ext"; then
    UNAPPROVED="$UNAPPROVED\n  - $ext"
  fi
done <<< "$INSTALLED"

if [ -n "$UNAPPROVED" ]; then
  echo "Extensions non approuvees detectees :"
  echo -e "$UNAPPROVED"
  echo ""
  echo "Contactez votre equipe securite pour demander l ajout."
  exit 1
else
  echo "Toutes les extensions sont approuvees."
  exit 0
fi

L enjeu principal de la liste blanche est l equilibre entre securite et productivite. Une liste trop restrictive frustrera les developpeurs et les poussera a contourner les restrictions. Une liste trop permissive ne sert a rien. La bonne approche est de definir une liste de base d extensions essentielles (linter, formateur, git, docker) et de mettre en place un processus d ajout rapide : un developpeur qui a besoin d une extension non listee fait une demande, l equipe securite la verifie selon les criteres de l etape 2, et elle est ajoutee a la liste en moins de 24 heures si elle passe les verifications.

Etape 6 : Mettre en place un monitoring continu des extensions

L audit initial est necessaire mais insuffisant. Les menaces evoluent en permanence — une extension approuvee aujourd hui peut etre compromise demain si le compte de son editeur est pirate. Le monitoring continu est la seule approche qui offre une protection durable. L objectif est de detecter rapidement trois scenarios : une extension approuvee qui change de comportement apres une mise a jour, un compte editeur qui est compromis, ou une nouvelle vulnerabilite qui affecte une extension installee.

Pour le monitoring automatise, vous pouvez mettre en place un cron job qui verifie quotidiennement l etat de vos extensions. Voici un script complet qui genere un rapport de monitoring :

#!/bin/bash
# monitor-extensions.sh
# Monitoring quotidien des extensions VS Code
# Ajouter a crontab : 0 9 * * * /path/to/monitor-extensions.sh

BASELINE_FILE="$HOME/.vscode-extension-baseline.txt"
CURRENT_FILE="/tmp/vscode-extensions-current.txt"
REPORT_FILE="/tmp/vscode-extension-report.txt"

# Generer l etat actuel
code --list-extensions --show-versions > "$CURRENT_FILE"

# Comparer avec le baseline
if [ -f "$BASELINE_FILE" ]; then
  # Nouvelles extensions ajoutees
  ADDED=$(diff "$BASELINE_FILE" "$CURRENT_FILE" | grep "^>" | sed 's/^> //')
  # Extensions supprimees
  REMOVED=$(diff "$BASELINE_FILE" "$CURRENT_FILE" | grep "^<" | sed 's/^< //')
  # Extensions avec version changee
  UPDATED=$(comm -13 <(sort "$BASELINE_FILE") <(sort "$CURRENT_FILE") | \
    grep -v -F -f <(echo "$ADDED"))

  echo "=== RAPPORT MONITORING EXTENSIONS VS CODE ===" > "$REPORT_FILE"
  echo "Date : $(date)" >> "$REPORT_FILE"
  echo "" >> "$REPORT_FILE"

  if [ -n "$ADDED" ]; then
    echo "[ALERTE] Nouvelles extensions detectees :" >> "$REPORT_FILE"
    echo "$ADDED" >> "$REPORT_FILE"
    echo "" >> "$REPORT_FILE"
  fi

  if [ -n "$UPDATED" ]; then
    echo "[INFO] Extensions mises a jour :" >> "$REPORT_FILE"
    echo "$UPDATED" >> "$REPORT_FILE"
    echo "" >> "$REPORT_FILE"
  fi

  if [ -n "$REMOVED" ]; then
    echo "[INFO] Extensions supprimees :" >> "$REPORT_FILE"
    echo "$REMOVED" >> "$REPORT_FILE"
  fi

  # Envoyer le rapport si des changements sont detectes
  if [ -n "$ADDED" ] || [ -n "$UPDATED" ] || [ -n "$REMOVED" ]; then
    cat "$REPORT_FILE"
    # Optionnel : envoyer par email ou webhook Slack
    # curl -X POST -H 'Content-type: application/json' \
    #   --data "{\"text\":\"$(cat $REPORT_FILE)\"}" \
    #   YOUR_SLACK_WEBHOOK_URL
  fi
else
  echo "Premier run — creation du baseline"
fi

# Mettre a jour le baseline
cp "$CURRENT_FILE" "$BASELINE_FILE"

Pour un monitoring plus avance, des outils tiers comme Aikido.dev et Socket.dev offrent une surveillance continue des ecosystemes de paquets et d extensions, avec des alertes en temps reel quand une extension change de comportement ou quand un editeur est signale comme compromis. Ces outils analysent le code des extensions a chaque mise a jour et detectent les patterns suspects (acces reseau non justifie, lecture de fichiers sensibles, obfuscation de code). L investissement dans ce type d outil est largement justifie pour les equipes de plus de 10 developpeurs — le cout d un incident supply chain depasse largement le cout d un abonnement a un outil de monitoring. Pour une approche complementaire, consultez notre guide sur la configuration de Dependabot et Renovate pour l audit des dependances.

Etape 7 : Formaliser une politique de securite d extensions pour l equipe

Les etapes 1 a 6 sont techniques. L etape 7 est organisationnelle — et c est souvent la plus importante pour la durabilite de votre posture de securite. Sans une politique formalisee, les bonnes pratiques d audit se diluent avec le temps : un nouveau developpeur rejoint l equipe et installe ses extensions favorites sans verification, un developpeur senior reactive les mises a jour automatiques par confort, la liste blanche n est pas mise a jour depuis 6 mois. La politique de securite d extensions est le document qui formalise les regles, les responsabilites et les processus.

Voici un template de politique que vous pouvez adapter a votre contexte :

# Politique de securite des extensions VS Code
# Version 1.0 — [Votre organisation] — Mai 2026

## 1. Regles generales
- Les mises a jour automatiques des extensions sont DESACTIVEES
  sur tous les postes de developpement.
- Seules les extensions figurant dans la liste blanche approuvee
  (.vscode/extensions.json) sont autorisees.
- L installation d extensions non approuvees declenche une alerte
  automatique via le script de monitoring.

## 2. Processus d ajout d une extension
1. Le developpeur soumet une demande via [Slack/Jira/email]
2. L equipe securite verifie les criteres :
   - Editeur verifie sur le Marketplace
   - > 10 000 telechargements
   - Derniere mise a jour < 6 mois
   - Repository source public
   - Pas de signaux d alerte dans les permissions
3. Decision sous 24 heures ouvrees
4. Si approuvee : ajout a extensions.json + commit

## 3. Mises a jour des extensions
- Les mises a jour sont appliquees manuellement
- Delai minimum de 48h apres publication pour les
  mises a jour majeures
- Le changelog doit etre consulte avant chaque mise a jour

## 4. Onboarding nouveau developpeur
- Le nouveau developpeur recoit la liste blanche
- Ses extensions existantes sont auditees
- Les extensions non approuvees sont desinstallees

## 5. Revision trimestrielle
- La liste blanche est revue tous les trimestres
- Les extensions non utilisees sont retirees
- Les nouvelles extensions pertinentes sont evaluees

## 6. Incident response
- Si une extension est signalee comme malveillante :
  1. Desinstallation immediate sur tous les postes
  2. Rotation de tous les credentials
  3. Scan des postes potentiellement compromis
  4. Post-mortem sous 48h

La politique doit etre vivante et accessible. Stockez-la dans le wiki de votre organisation ou dans un fichier SECURITY.md a la racine de votre monorepo. Incluez-la dans le processus d onboarding des nouveaux developpeurs. Et surtout, designez un responsable de la politique — quelqu un qui se charge de la revision trimestrielle, de l ajout d extensions a la liste blanche, et de la communication en cas d incident. Sans responsable clair, la politique mourra en quelques mois.

Enfin, n oubliez pas que la securite des extensions VS Code n est qu un maillon de votre chaine de securite supply chain. Les memes principes s appliquent a vos dependances npm (guide de securisation npm), a vos GitHub Actions (guide de securisation GitHub Actions), et a vos dependances Python (guide d audit des dependances Python). Une approche holistique de la securite supply chain couvre tous ces vecteurs simultanement.

FAQ