7 conseils pour éviter de se faire pirater (npm, pnpm & bun)

Françaisالعربية Deutsch English Español हिन्दी Bahasa Indonesia 日本語 한국어 Português Русский 中文

Computing/SoftwareInternet Technology

Transcript

00:00:00Si vous installez des paquets NPM, vous êtes une cible. Peut-être pas aujourd'hui, peut-être pas cette semaine, mais c'est

00:00:05définitivement en approche. Des centaines de paquets ont été compromis rien que ces derniers mois,

00:00:09et ça ne ralentit pas. Alors, au lieu de m'inquiéter à chaque fois qu'un problème survient,

00:00:14j'ai pris le temps de verrouiller ma configuration pour NPM, PNPM et BUN, et il s'avère que la plupart

00:00:18des mesures qui vous auraient sauvés ne prennent qu'environ 30 secondes à mettre en place. Dans cette vidéo,

00:00:23je vais vous présenter les sept changements que j'ai effectués, allant d'une simple ligne de configuration qui

00:00:27élimine l'attaque la plus courante, jusqu'à des outils gratuits soumis par les attaquants eux-mêmes

00:00:30qui les détecteraient avant même que le paquet n'atteigne votre machine. Entrons dans le vif du sujet.

00:00:39La première et la plus simple est d'arrêter de télécharger de nouveaux paquets. La plupart de ces attaques

00:00:44par la chaîne d'approvisionnement sont détectées en quelques heures, donc si vous n'installez pas les toutes nouvelles versions

00:00:48dès leur sortie, vous évitez en fait la plupart de ces attaques. Tous les gestionnaires de paquets

00:00:52Node.js majeurs proposent désormais une forme de contrôle de l'âge des versions. Pour NPM, vous réglez cela dans le fichier

00:00:57.npmrc, et c'est défini en jours. Pour PNPM, vous pouvez le définir globalement dans le fichier config.yaml,

00:01:03ou le régler par projet en utilisant le fichier workspace de PNPM, et cette valeur est en fait

00:01:08définie en minutes. Il est également intéressant de noter que depuis PNPM 11, cela est réglé par défaut sur un jour,

00:01:14donc même sans configuration, vous bénéficiez d'une certaine protection. Pour BUN, cela se règle dans le

00:01:17fichier bunfig.toml, globalement ou par projet, et cette valeur est définie en secondes.

00:01:23Cela m'étonne vraiment que pour le même paramètre, à travers trois gestionnaires de paquets,

00:01:27nous nous retrouvions avec trois valeurs différentes, ce qui résume assez bien cet écosystème. Une fois ce réglage effectué,

00:01:32si vous installez un paquet comme le react start de TanStack, vous verrez qu'il n'installe pas la

00:01:36version la plus récente, mais celle qui respecte mes critères d'âge de sortie, qui pour moi

00:01:41était d'une semaine. Si vous avez besoin de contourner cela, peut-être en raison d'un problème de sécurité

00:01:45avec le paquet que vous installez et que vous devez installer la dernière version, vous pouvez toujours le faire

00:01:49depuis la ligne de commande. Mais attention aux LLM, car j'ai déjà vu des cas où les LLM

00:01:54utilisent simplement cette commande pour contourner la restriction et installer quand même les dernières versions. Gardez aussi à l'esprit

00:01:59que NPX et BUNX ne respectent pas ce paramètre, ils installent toujours la version la plus récente,

00:02:03et il y a une PR ouverte sur BUN pour corriger cela. Tant que nous sommes dans les réglages, allons-y

00:02:07et désactivons les scripts d'installation pour NPM. PNPM et BUN ont déjà ce comportement par défaut,

00:02:12il n'y a donc rien à configurer. Si vous ne le saviez pas, lors de l'installation d'un paquet, celui-ci

00:02:16est autorisé à exécuter son propre code juste après avoir été installé. Cela a été prévu pour des cas

00:02:20d'utilisation légitimes comme la compilation de code natif ou le téléchargement d'un binaire, mais le problème est que presque chaque

00:02:26attaque par la chaîne d'approvisionnement a utilisé cette méthode pour exécuter du code malveillant sur votre machine juste après l'installation.

00:02:30Si vous trouvez un paquet qui a un besoin légitime de l'un de ces scripts, vous pouvez toujours l'activer

00:02:34explicitement. Dans PNPM, lorsque vous installez un paquet avec des scripts post-installation, il vous en informera,

00:02:39comme pour esbuild ici, et vous pouvez alors exécuter “pnpm approved builds” pour choisir ceux à autoriser,

00:02:44ce qui définit la configuration “workspace allow builds” de PNPM. Vous pouvez aussi simplement utiliser le

00:02:48drapeau “allow build” sur la commande d'installation pour faire la même chose. Pour BUN, comme je l'ai dit, il

00:02:52arrête aussi ces scripts d'installation par défaut, mais il faut savoir qu'il possède une liste organisée de

00:02:56paquets autorisés à exécuter ces scripts, ce qui inclut ceux que j'ai installés comme

00:03:00esbuild. Vous pouvez refuser cela en ajoutant des dépendances de confiance dans votre package.json,

00:03:04ainsi, seuls les paquets que vous autorisez explicitement pourront exécuter des scripts post-installation.

00:03:09Il est également indiqué que si vous définissez le tableau comme vide, cela devrait outrepasser la liste par défaut

00:03:12aussi, mais cela ne semble pas fonctionner pour moi, et il semble s'agir d'un bug que j'ai trouvé sur GitHub

00:03:17également. La solution de contournement actuelle est de mettre une valeur dans cette liste, et ainsi la liste par défaut

00:03:21est ignorée. Avec BUN, vous pouvez aussi exécuter “bun pm untrusted” pour voir quels paquets veulent exécuter

00:03:26des scripts mais ne sont pas encore approuvés, puis vous pouvez exécuter “bun pm trust” pour en autoriser un, ou simplement l'ajouter

00:03:30au tableau des dépendances de confiance. Vous pouvez aussi désactiver totalement les scripts dans BUN en réglant les “install scripts” sur

00:03:35false dans votre config globale BUN. Pour NPM, c'est un peu plus difficile. Honnêtement, n'utilisez simplement pas

00:03:40NPM, utilisez PNPM. Mais si vous devez vraiment utiliser NPM pour une raison quelconque, vous pouvez obtenir un comportement

00:03:45similaire de liste d'autorisation en utilisant le paquet “Lavamote's allow scripts”. Ainsi, c'est juste une liste

00:03:50d'autorisation dans votre package.json également. Le troisième conseil est de bloquer les dépendances basées sur git. Avec NPM, une dépendance peut

00:03:55en fait être déclarée comme une URL git, ce qui contourne le registre, et peut même embarquer son propre .npmrc qui

00:04:01réactive les scripts de cycle de vie. C'est en fait l'une des astuces utilisées dans la récente attaque NPM

00:04:05qui a touché TanStack. Vous pouvez arrêter cela en réglant “allow git” sur none dans votre config NPM,

00:04:10ce qui les bloque entièrement, et l'autre option est de régler cela sur “root”, ce qui autorise les dépendances

00:04:15basées sur git à être installées, mais seulement si elles sont déclarées dans votre package.json racine, donc probablement

00:04:19explicitement définies par vous. Pour PNPM, cette option est “block exotic sub-dependencies”. Quand ceci est réglé sur true,

00:04:25seules les dépendances directes, celles que vous avez listées dans votre package.json racine, peuvent utiliser des sources

00:04:29exotiques comme des repos git ou des URLs directes. Cette option n'existe pas encore dans Bun, mais il y a une

00:04:35PR ouverte pour l'ajouter, donc nous la verrons peut-être bientôt. En bonus pour terminer les conseils impliquant des changements

00:04:40de configuration, PNPM possède un réglage de politique de confiance, que nous pouvons régler sur “no downgrade”, ce qui signifie

00:04:45que PNPM échouera si le niveau de confiance d'un paquet a diminué par rapport à sa version précédente. Donc si un

00:04:50paquet était précédemment publié par un éditeur de confiance, mais qu'il n'a maintenant que de la provenance ou

00:04:55aucune preuve de confiance, l'installation échouera. Cela devrait aider à attraper ces attaques qui trouvent des moyens de

00:05:00contourner les processus de publication habituels. Le conseil numéro quatre est probablement le plus puissant, qui est

00:05:04d'utiliser un outil qui examine les paquets que vous installez et peut les auditer avant qu'ils

00:05:08ne touchent jamais votre machine. Pour cela, nous avons deux outils puissants et totalement gratuits. Le premier est

00:05:14MPQ. Vous pouvez le configurer en créant un alias pour vos commandes NPM, PNPM ou Bun normales,

00:05:18afin que chaque fois que vous lancez une installation, il vérifie quelques éléments. Il scannera les vulnérabilités connues

00:05:23contre la base de données de Snyk, et signalera tout paquet ayant moins de 22 jours d'existence. Il

00:05:28détectera le typosquatting, où quelqu'un a publié un paquet comme “express” avec deux “s”, espérant

00:05:32que vous ferez une erreur de frappe et installerez celui-ci par erreur. Il vérifiera la signature du registre et

00:05:37la provenance de la construction. Il vous avertira lorsqu'un paquet a des scripts de pré et post-installation, et en plus de tout cela,

00:05:41il vérifie des choses basiques comme le nombre de téléchargements, s'il y a un readme, une licence, une URL de dépôt,

00:05:46et quel est l'email du mainteneur, et si ce domaine est même encore enregistré. Il fait tout cela

00:05:51et vous donne ensuite un rapport interactif sur vos paquets, où vous pouvez encore décider si vous

00:05:55voulez l'installer. Le second est Socket Firewall. C'est en fait celui que j'utilise,

00:05:59et encore une fois, vous faites un alias de ceci pour tous vos gestionnaires de paquets habituels, et celui-ci prend

00:06:03aussi en charge des choses en dehors de JavaScript, comme Python et Rust. Similaire à MPQ, quand vous lancez une installation avec

00:06:08lui, il vérifiera Socket et bloquera tout paquet malveillant confirmé par un humain, et il vous avertira aussi

00:06:12de toute menace détectée par IA, qui sont celles qui n'ont pas encore été examinées par un humain. Pour être honnête,

00:06:16j'ai principalement choisi Socket Firewall car c'est celui dont j'ai entendu parler en premier, mais je fais aussi confiance à Socket car ils ont

00:06:21attrapé beaucoup de paquets malveillants récents, et les attaquants ont même fait une interview où ils ont dit

00:06:25que Socket détectera le malware avant même que le paquet n'atteigne votre machine, ce qui est une assez bonne

00:06:30publicité pour eux, et j'aime aussi le fait qu'il prenne en charge plus que juste JavaScript avec UV pip et cargo.

00:06:35Si vous installez l'un ou l'autre, vous voudrez vous assurer que vous videz le cache de votre gestionnaire de paquets

00:06:38juste pour vous assurer que chaque paquet installé est vérifié par le pare-feu. Le conseil 5 concerne vos

00:06:42fichiers de verrouillage. Vos fichiers de verrouillage sont là où réside l'URL de téléchargement réelle pour chaque paquet, et le

00:06:47problème est que pratiquement personne ne révise ses fichiers de verrouillage dans une PR. Donc si quelqu'un ouvre une PR contre votre

00:06:51repo, il peut tranquillement éditer une URL résolue pour pointer vers un paquet qu'il contrôle, et aussi définir le

00:06:56hash d'intégrité correspondant pour que rien n'ait l'air suspect. Maintenant, la prochaine fois que vous lancez une installation, vous tirez

00:07:01le code depuis le serveur de l'attaquant. Bonne nouvelle cependant, si vous utilisez PNPM, vous n'êtes pas vulnérable

00:07:05à cela. Il ne garde pas ces sources de table qui peuvent être échangées, et il n'installera pas non plus

00:07:09quoi que ce soit qui est dans le fichier de verrouillage, mais pas réellement déclaré dans votre package.json. Je n'ai pas pu trouver d'

00:07:14information concrète sur Bun cependant, donc cela pourrait encore être vulnérable à ceci. La solution si vous n'

00:07:18utilisez pas PNPM est d'utiliser un outil appelé lockfileLint. Vous installez ceci comme une dépendance de dev, et il valide

00:07:23votre fichier de verrouillage, vérifiant que chaque paquet est résolu depuis un hôte de confiance, comme le registre NPM. Il vérifie

00:07:28que les URLs résolues correspondent réellement au nom du paquet, et il vérifie aussi que les hashs d'intégrité sont réels

00:07:32également. S'il suspecte que quelque chose a été altéré, il fera échouer l'installation. Le conseil 6 est d'arrêter

00:07:37d'utiliser NPM install en CI et en production, et plutôt d'utiliser “clean install”. La commande pour cela dans NPM est

00:07:42juste “npm ci”, et pour Bun et PNPM, vous ajoutez en fait le drapeau “frozen lockfile”, mais ils ont aussi des commandes

00:07:47CI comme un alias qui font la même chose. PNPM utilise en fait ceci par défaut s'il détecte qu'il

00:07:52tourne dans un environnement CI. La commande “clean install” installe exactement ce qui est dans le fichier de verrouillage,

00:07:57rien d'autre, et si le fichier de verrouillage et le package.json ne sont pas d'accord, il s'arrête juste et lance une erreur,

00:08:01au lieu de deviner et d'installer quand même. Donc ceci devrait empêcher un attaquant de glisser une

00:08:05version échangée. Rien de tout cela ne fonctionne cependant si vous ne committez pas votre fichier de verrouillage en premier

00:08:09lieu, donc assurez-vous que c'est dans le contrôle de version et pas dans votre gitignore, et j'admettrai quand je

00:08:13ai commencé à apprendre à coder enfant, je pensais en fait qu'on était censé ignorer ceux-ci, donc je suis content

00:08:17d'avoir appris à les committer. Donc ces six conseils étaient surtout de la configuration et de l'outillage, mais il y a aussi des

00:08:21habitudes que vous pouvez adopter pour vous aider à éviter les attaques. La première est d'arrêter de mettre à jour aveuglément

00:08:25tout. Vous avez peut-être déjà lancé “npm update” ou les autres versions de cette commande auparavant, et simplement

00:08:30mis à jour chaque dépendance vers sa dernière version d'un seul coup, mais c'est le genre de comportement exact que ces

00:08:35attaquants espèrent, donc passez réellement à travers ces mises à niveau et demandez-vous pourquoi vous avez besoin de

00:08:39la mettre à niveau. La deuxième habitude est de devenir de plus en plus pertinente, utilisez simplement moins de paquets. Chaque

00:08:43dépendance que vous ajoutez est une surface d'attaque supplémentaire, et la plupart de ces attaques se propagent à travers les dépendances

00:08:48d'une dépendance, donc ça vaut vraiment la peine de se demander pourquoi vous avez besoin de cette bibliothèque. Quelques exemples courants que je vois de

00:08:53ceci sont des choses comme Lodash pour des fonctions qui peuvent être faites avec un petit extrait de code, ou Axios quand

00:08:58fetch peut faire la même chose. La raison pour laquelle je dis que cela devient de plus en plus pertinent est qu'à l'ère du codage

00:09:03agentique, il est assez facile d'amener l'IA à écrire quelques fonctions pour vous au lieu d'utiliser une dépendance.

00:09:08La troisième habitude est d'épingler les dépendances à une version exacte, donc une mise à niveau est toujours un choix

00:09:12délibéré, mais sachez que cela ne verrouille en fait que les paquets que vous choisissez dans votre package.json,

00:09:17et les dépendances de vos dépendances peuvent encore utiliser leurs propres plages, ce qui est exactement pourquoi ce

00:09:21délai du conseil 1 compte. Tous ces éléments combinés devraient vous donner une certaine tranquillité d'esprit sur le fait que vous n'allez pas

00:09:25accidentellement installer un paquet compromis. Ils ne sont pas invincibles, mais ils sont bien meilleurs que

00:09:29rien. Le conseil ultime est juste de tout exécuter dans un conteneur de développement durci, mais j'ai toujours trouvé

00:09:34que c'était un peu fastidieux, donc je finis par retomber sur le développement local. Si vous connaissez un autre moyen

00:09:38de vous protéger contre ce genre d'attaque, faites-le moi savoir dans les commentaires ci-dessous, pendant que vous y êtes

00:09:42abonnez-vous, et comme toujours on se voit dans la prochaine.

Key Takeaway

Sécuriser les installations de paquets nécessite une combinaison de limites d'âge pour les nouvelles versions, de désactivation des scripts post-installation et d'audit via des outils comme Socket Firewall.

Highlights

La configuration d'un délai de sécurité avant installation empêche l'exécution de paquets malveillants récents, ces derniers étant souvent détectés en quelques heures.
La désactivation des scripts d'installation post-installation bloque le vecteur d'attaque principal utilisé dans la majorité des compromissions de la chaîne d'approvisionnement.
L'utilisation d'outils comme Socket Firewall ou MPQ permet l'audit automatique des dépendances en scannant les vulnérabilités, le typosquatting et les comportements suspects avant l'installation.
L'exécution de la commande 'npm ci' ou de l'équivalent avec le drapeau 'frozen-lockfile' en CI garantit l'installation des versions exactes listées dans le fichier de verrouillage.
Le blocage des dépendances basées sur des URLs git empêche le contournement du registre officiel et l'injection de scripts de cycle de vie non contrôlés.

Timeline

Limitation de l'âge des paquets et désactivation des scripts

Le paramétrage d'un délai d'attente évite l'installation immédiate de paquets compromis, souvent identifiés peu après leur sortie.
La désactivation globale des scripts d'installation supprime la capacité des paquets à exécuter du code arbitraire sur la machine hôte.
PNPM et Bun offrent des contrôles de sécurité natifs plus robustes que NPM pour la gestion des scripts.

La plupart des attaques par la chaîne d'approvisionnement sont détectées en quelques heures. Configurer un délai de sécurité via .npmrc, config.yaml ou bunfig.toml permet de contourner ces menaces. La désactivation des scripts post-installation est une mesure critique, car ce vecteur est exploité pour exécuter du code malveillant dès l'installation. Des exceptions restent possibles pour des paquets de confiance via des listes d'approbation spécifiques.

Sécurisation des sources et audit des dépendances

Le blocage des dépendances git empêche les attaquants de contourner le registre npm officiel.
Socket Firewall et MPQ auditent les paquets en temps réel en vérifiant les signatures, la provenance et les comportements suspects.
Le paramètre 'no downgrade' de PNPM bloque les paquets dont la confiance a diminué par rapport à une version antérieure.

Les URLs git permettent d'injecter des paquets non vérifiés contenant des scripts malveillants. Restreindre ces sources aux seules dépendances définies explicitement à la racine du projet renforce la sécurité. Des outils gratuits d'audit automatisé comme Socket Firewall ou MPQ servent de pare-feu proactif, bloquant les menaces confirmées ou suspectes avant qu'elles n'atteignent le système.

Gestion du fichier de verrouillage et bonnes pratiques

L'utilisation de 'clean install' (npm ci) en CI garantit l'intégrité de l'installation par rapport au fichier de verrouillage.
L'examen manuel des fichiers de verrouillage est indispensable pour détecter toute modification suspecte des URLs ou des hashs d'intégrité.
Réduire le nombre de dépendances diminue directement la surface d'attaque du projet.

Le fichier de verrouillage est une cible facile pour les attaquants qui peuvent modifier les URLs résolues. L'usage systématique de commandes d'installation gelées en CI empêche toute modification non approuvée du graphe de dépendances. Adopter une politique de minimalisme en évitant les bibliothèques superflues au profit d'extraits de code simples limite l'exposition aux vulnérabilités transitives.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video