원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Il n'y a pas de temps à perdre à faire des recherches sur Google tard dans la nuit après avoir entendu parler d'un incident de sécurité. En mai 2026, le déploiement d'une extension Visual Studio Code malveillante a compromis les machines de développeurs, entraînant la fuite d'environ 3 800 dépôts de code source internes. Dans cette situation, supprimer aveuglément du code ou formater son ordinateur portable détruit les preuves médico-légales et empêche de trouver la cause. Examinons directement les journaux d'exécution du gestionnaire de paquets, les horodatages des CLI globales et les privilèges des processus en cours pour vérifier si le système a été compromis.
Les gestionnaires de paquets laissent des traces de transactions dans le répertoire de cache du système lors du processus d'installation. npm génère des journaux de débogage dans le dossier _logs situé à l'intérieur du chemin npm config get cache, tandis que pnpm stocke ses artefacts dans pnpm store path. Les paquets malveillants exfiltrent des variables d'environnement ou des identifiants via des scripts exécutés au moment de l'installation, il faut donc commencer par inspecter l'historique d'exécution du cycle de vie.
Voici la commande pour analyser les journaux des 14 derniers jours afin de détecter l'ajout non autorisé de paquets ou l'exécution de scripts externes. Ouvrez votre terminal et saisissez directement les commandes ci-dessous :
`bash
NPM_CACHE_DIR=$(npm config get cache)
find $NPM_CACHE_DIR/_logs/ -type f -mtime -14 -exec grep -Hn "lifecycle" {} +
`
Examinez les résultats pour voir si des crochets preinstall ou postinstall non souhaités ont été exécutés. Cela prend trois minutes. S'il n'y a pas d'historique de communication avec des URL externes suspectes, vous pouvez souffler un peu en ce qui concerne la peur d'une contamination directe au niveau des paquets.
Les attaquants s'immiscent dans l'ordinateur portable et insèrent des binaires malveillants dans les outils CLI globaux ou le cache npx pour persister. Listez les paquets installés globalement et comparez les dates de création et de modification des fichiers du dossier de binaires avec les journaux système pour vérifier leur intégrité.
`bash
npm list -g --depth=0 --json
ls -lact $(npm config get prefix)/bin/
`
Si l'heure de modification coïncide avec un créneau suspect, extrayez les valeurs de hachage avec la commande suivante pour les comparer.
`bash
shasum -a 256 $(npm config get prefix)/bin/
`
Les scripts d'installation de paquets s'exécutent avec les privilèges du compte développeur. Vous devez tuer les processus démons tournant en arrière-plan.
`bash
ps aux | grep -E "node|npm|pnpm|bun" | grep -v grep
lsof -i -P -n | grep -E "node|npm|pnpm"
`
Si un processus suspect communique avec un serveur C2 externe, attrapez-le et tuez-le immédiatement.
`bash
kill -9 [PID]
npm config set ignore-scripts true
`
Un modèle classique d'attaque de la chaîne d'approvisionnement consiste à modifier les fichiers de configuration pour détourner le registre. Les attaquants intègrent de fausses adresses de serveurs miroirs dans le fichier .npmrc du projet ou dans la configuration globale. Étant donné qu'ils modifient le chemin de téléchargement dans le fichier de verrouillage pour forcer le téléchargement d'une archive (tarball) malveillante lors de l'installation réelle, vous devez inspecter minutieusement tous les paramètres.
La procédure pour vérifier si des surcharges non autorisées ont été injectées dans les configurations locales et globales est la suivante. Extrayez d'abord la liste des liaisons de configuration.
`bash
npm config list
pnpm config list
`
Vérifiez ensuite si la portée du registre privé de l'entreprise est correctement définie.
`bash
npm config get @company:registry
`
Vérifiez également directement si des adresses de miroirs externes ont été codées en dur dans les fichiers de configuration du répertoire personnel de l'utilisateur et de la racine du projet.
`bash
grep -Rn "registry" ~/.npmrc ./.npmrc
`
Ces trois étapes vous permettent de déterminer en cinq minutes si une adresse de miroir étrange a été enregistrée.
Les fichiers package-lock.json et pnpm-lock.yaml enregistrent les URL d'origine du téléchargement des dépendances, vous devez donc rechercher toute corruption à l'aide d'expressions régulières.
`bash
grep -E '"resolved": "https?://' package-lock.json | grep -vE 'registry.npmjs.org|registry.corp.example'
`
Si vous utilisez pnpm, entrez la commande suivante.
`bash
grep -E 'resolution: {tarball:' pnpm-lock.yaml | grep -vE 'registry.npmjs.org|registry.corp.example'
`
Si un fichier de verrouillage corrompu apparaît, vous devez tout supprimer et le recréer.
`bash
rm -rf node_modules package-lock.json pnpm-lock.yaml
npm cache clean --force
pnpm store prune
npm config set registry https://registry.npmjs.org/
npm ci --ignore-scripts
`
En ignorant l'exécution des scripts de cycle de vie et en reconstituant un arbre de dépendances dans un état immuable, vous pouvez obtenir un environnement propre.
Dans les environnements Linux et Mac, les binaires malveillants pillent le stockage des mots de passe du navigateur et récupèrent toutes les clés d'API d'IA, les clés d'accès AWS et les clés SSH intégrées dans les variables d'environnement. Vous devez vérifier dès maintenant si vos identifiants ont été exposés dans l'environnement du terminal.
`bash
ls -la ~/.ssh/
env | grep -E 'TOKEN|KEY|SECRET|AUTH|AWS|GITHUB|OPENAI|ANTHROPIC'
grep -E '(ghp_[A-Za-z0-9]{36}|AKIA[0-9A-Z]{16}|bearer)' ~/.zsh_history ~/.bash_history
`
Si des clés exposées en clair apparaissent, ne fermez pas les yeux et révoquez-les immédiatement. Vérifiez également la portée des jetons connectés via le CLI GitHub.
`bash
gh auth status
`
Supprimez immédiatement les jetons classiques qui disposent d'un accès à tous les dépôts. Lorsque vous recréez un jeton d'accès personnel (PAT), spécifiez uniquement des dépôts spécifiques et limitez les autorisations de lecture à la plage minimale.
Pour isoler l'hôte local et les processus de développement, vous devez utiliser la structure DevContainer. Créez un fichier .devcontainer/devcontainer.json à la racine du projet et configurez l'image comme suit.
`json
{
"image": "mcr.microsoft.com/devcontainers/javascript-node:22",
"postCreateCommand": "npm ci --ignore-scripts"
}
`
En lançant le conteneur de cette manière, l'installation des paquets et la compilation s'exécutent dans un état totalement isolé des identifiants système de votre ordinateur portable, ce qui permet de bloquer à la source toute voie de fuite des actifs de l'entreprise.
