"initializeCommand": "curl -fsSL https://... | bash" ne s'exécute pas dans le conteneur : il s'exécute sur votre propre machine, chaque fois que quelqu'un ouvre le dépôt dans un dev container. Et un montage de ${localEnv:HOME}/.ssh livre vos clés privées à chaque script d'installation de paquet qui s'y exécute. Ce skill détecte ces risques et douze autres liés aux dev containers avant que quiconque n'ouvre le dossier, et vous indique comment corriger chacun d'eux.

Votre agent lance un scanner sur .devcontainer/devcontainer.json, .devcontainer.json et les configurations par dossier situées sous .devcontainer/ (VS Code Dev Containers, GitHub Codespaces, la devcontainer CLI). Il lit le JSON avec commentaires et virgules finales, connaît les variables ${localEnv:NAME} et ${containerEnv:NAME}, les formes chaîne, tableau et objet des commandes de cycle de vie, les chaînes et objets de montage, les options docker run dans runArgs, et sait que runArgs, appPort et workspaceMount ne s'appliquent pas aux configurations Docker Compose, que les valeurs numériques de appPort restent sur localhost et qu'un devcontainer-lock.json épingle les Features. Les mots de passe de développement local (postgres, devpass, rootpass), les paramètres portant sur un secret (PASSWORD_HASHER) et les valeurs de substitution (your-token, django-insecure-...) ne sont pas signalés comme secrets. Il n'exécute jamais docker, la devcontainer CLI ni aucune commande trouvée. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre. Les secrets ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la livraison)

• D01 : un initializeCommand (il s'exécute sur l'hôte) qui télécharge un script et l'exécute : curl | bash, bash <(curl ...), iwr | iex
• D02 : mots de passe, jetons et clés écrits dans containerEnv, remoteEnv, les arguments de build, runArgs -e, les commandes de cycle de vie (y compris docker login -p, az login -p, sqlcmd -P et un littéral envoyé par echo à docker login --password-stdin), les valeurs par défaut ${localEnv:NAME:default}, la propriété secrets ou tout paramètre (noms de secrets, mots de passe dans des URL, formats de jetons connus)
• D03 : votre dossier personnel, ~/.ssh, ~/.aws, les identifiants des CLI cloud et de Docker, GnuPG, .npmrc, .netrc et autres fichiers d'identifiants, le dossier racine de l'hôte ou /etc montés dans le conteneur

REVIEW (à vérifier avant la publication)

• D11 : conteneurs privilégiés ("privileged": true, --privileged dans runArgs, ou la Feature docker-in-docker, qui l'active)
• D12 : le socket Docker ou Podman monté, ou la Feature docker-outside-of-docker, qui le monte
• D13 : onCreateCommand, postCreateCommand et les autres commandes de configuration qui envoient un téléchargement vers un shell
• D14 : images sans tag ou avec :latest, et Features sans version, avec :latest ou fournies sous forme d'URL de tarball (sauf si un devcontainer-lock.json les épingle)
• D15 : capabilities au-delà de celles par défaut de Docker (SYS_PTRACE seul est acceptable), périphériques de l'hôte, et seccomp, AppArmor ou SELinux désactivés (la configuration de débogage SYS_PTRACE plus seccomp=unconfined n'est pas signalée)
• D16 : espaces de noms de l'hôte pour le réseau, PID, IPC, UTS, les utilisateurs ou cgroup
• D17 : remoteUser, containerUser ou runArgs --user défini sur root
• D18 : un initializeCommand qui exécute un programme ou un script sur l'hôte (mkdir, touch, cp, docker pull et autres étapes simples similaires sont acceptables)
• D19 : ~/.kube, ~/.minikube, /proc, /sys, /dev, /var/lib/docker, /run, /boot ou /lib/modules montés depuis l'hôte
• D20 : ports publiés sur toutes les interfaces réseau (runArgs -p ou -P, chaînes appPort sans 127.0.0.1)
• D21 : permissions de dépôt Codespaces avec write-all, accès en écriture sur owner/* ou écriture sur workflows

Ce qui est inclus

• Le scanner (Python 3.9+, bibliothèque standard uniquement)
• Un guide des règles avec la raison, l'approche plus sûre et la source officielle de chaque règle
• Un projet d'exemple risqué et un sûr (un dev container pour une API et un dev container d'outils de cluster), ainsi que le rapport réel produit par le scanner sur le projet risqué

Limites

Il ne lit que les fichiers devcontainer.json : le Dockerfile, les fichiers Docker Compose indiqués dans dockerComposeFile, les scripts d'installation des Features, les paramètres que les images et les Features ajoutent via leurs propres métadonnées (hormis les Features Docker de D11 et D12) et les scripts appelés par les commandes ne sont pas lus. Les commandes sont analysées comme du texte, donc un script téléchargé dans un fichier puis exécuté à une étape ultérieure n'est pas signalé. Les tags de version majeure comme :1 sont considérés comme épinglés bien que l'éditeur puisse les déplacer ; seul un digest ou un devcontainer-lock.json épingle exactement une Feature. Le mode privilégié et le socket Docker sont en REVIEW, pas en BLOCK : tous deux livrent l'hôte Docker au code du conteneur, mais ce sont des moyens délibérés et documentés d'exécuter Docker dans un dev container (les modèles officiels docker-in-docker et docker-outside-of-docker les utilisent), si bien que le mode privilégié reçoit le même niveau, qu'il soit écrit explicitement ou activé par la Feature. Monter tout le dossier personnel (un exemple tiré de la documentation de VS Code) est en BLOCK, car chaque clé qu'il contient devient lisible dans le conteneur. NOT FLAGGED n'est pas une garantie.

Contenu

Un fichier ZIP contenant 11 fichiers : SKILL.md, le scanner dans scripts/ (4 fichiers Python), references/rules.md (chaque règle avec sa raison et une approche plus sûre) et examples/ (4 fichiers d'exemple plus report.md, la sortie réelle du scanner sur l'exemple risqué).

Utilisation : il s'agit d'un skill d'agent : un dossier contenant un fichier SKILL.md et des scripts Python qu'un agent de programmation IA comme Claude Code, Cursor ou Codex CLI peut exécuter. Décompressez-le dans le dossier des skills de votre agent (pour Claude Code : ~/.claude/skills/), puis demandez à votre agent de vérifier votre projet. Les scripts fonctionnent aussi de manière autonome avec Python 3.9 ou plus récent, sans rien à installer. Ils se contentent de lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.