L'écosystème de paquets JavaScript, en particulier npm, a toujours été un territoire dynamique, bien que parfois chaotique. Mais alors que nous arrivons à la fin de 2025, l'atmosphère est chargée d'une énergie différente : une poussée palpable et urgente vers une chaîne d'approvisionnement logicielle plus sécurisée. Des attaques récentes et médiatisées ont fait passer la conversation de "si" à "comment" nous renforcer collectivement contre nos dépendances. J'ai été au cœur de la bataille, testant les derniers outils et observant l'évolution du paysage, et honnêtement, certaines des avancées sont vraiment impressionnantes, même si le chemin vers une adoption complète est encore semé de quelques épines tenaces.
Il ne s'agit pas seulement de corriger des bugs ; il s'agit d'une réévaluation fondamentale de la confiance, de la provenance et des mécanismes mêmes de la façon dont nous consommons et publions du code. La bonne nouvelle ? Nous constatons des efforts réels et tangibles de la part de l'équipe principale de npm, de GitHub et de la communauté au sens large pour résoudre ces vulnérabilités systémiques.
L'essor de npm provenance et Sigstore : la confiance à la source
C'est vraiment impressionnant car cela s'attaque à l'une des menaces les plus insidieuses : un environnement de construction ou de publication compromis. Depuis des années, nous nous sommes appuyés sur le champ integrity de package.json pour les sommes de contrôle, mais cela ne vérifie que le paquet téléchargé par rapport à ce que le registre pense qu'il devrait être. Cela ne nous dit pas si le paquet a été construit et publié par le mainteneur légitime dans un environnement fiable. Entrez npm provenance, désormais généralement disponible depuis octobre 2023, avec un élan significatif tout au long de 2024 et 2025.
npm provenance est l'implémentation par npm du cadre Supply-chain Levels for Software Artifacts (SLSA), tirant parti de la puissance de Sigstore. L'idée centrale est de créer des attestations vérifiables sur comment et où un paquet a été construit et publié. Lorsque vous publiez un paquet avec --provenance, la CLI npm fonctionne avec votre fournisseur CI/CD (actuellement GitHub Actions et GitLab CI/CD sont pris en charge) pour générer une attestation de provenance. Cette attestation comprend des détails tels que l'URI du dépôt source, le hachage de commit et les instructions de construction.
Voici l'élégance architecturale : au lieu de gérer des clés de signature de longue durée, Sigstore utilise des certificats éphémères de courte durée émis par une autorité de certification (Fulcio) qui se fédère avec votre fournisseur OIDC. Ce certificat est ensuite utilisé pour signer la déclaration de provenance, et le certificat et la signature sont tous deux enregistrés dans un journal de transparence public et inviolable (Rekor). Cela signifie que vous signez la construction, jetez la clé privée et l'ensemble du processus est auditable publiquement.
Pour publier avec la provenance, il suffit d'ajouter un indicateur :
npm publish --provenance --access public
Et pour la vérification ? La commande npm audit signatures, introduite en juillet 2022, est désormais notre meilleure amie pour cela. Elle vérifie les signatures ECDSA et renvoie une erreur si les paquets ont des signatures manquantes ou invalides, indiquant une éventuelle falsification.
npm audit signatures
C'est un pas en avant monumental. Bien que cela ne garantisse pas l'absence de code malveillant, cela fournit un lien cryptographique vers la source et l'environnement de construction, permettant aux développeurs de prendre des décisions de confiance éclairées. La limitation, pour l'instant, est sa dépendance aux exécuteurs hébergés dans le cloud et à des fournisseurs CI/CD spécifiques. Pour ceux d'entre nous qui disposent d'exécuteurs auto-hébergés ou de systèmes CI alternatifs, l'adoption est encore un peu maladroite, nécessitant des contournements manuels ou l'attente d'un support plus large. Mais la direction est claire, et elle est robuste.
Renforcer le publiant : 2FA, jetons granulaires et publication de confiance
La vague d'attaques de la chaîne d'approvisionnement en 2025, y compris le ver "Shai-Hulud" en septembre et les campagnes de typosquatting subséquentes en octobre, a servi de réveil brutal. Les attaquants ont compromis les comptes des mainteneurs par le biais de phishing sophistiqué, entraînant des injections de paquets malveillants. GitHub, qui possède npm, a réagi par des changements agressifs et nécessaires à l'authentification et à la publication, déployés en grande partie entre octobre et mi-novembre 2025.
Les principaux changements sont les suivants :
- 2FA obligatoire pour la publication locale : C'est une grande victoire. Plus de publication à partir d'une machine locale avec juste un mot de passe. Si vous publiez depuis votre environnement de développement, la 2FA sera requise. Cela s'attaque directement aux vecteurs de phishing qui ont affligé les mainteneurs.
- Dépréciation des jetons classiques hérités : Les jetons npm classiques, souvent de longue durée et à large portée, sont progressivement abandonnés. C'est essentiel car les jetons de longue durée compromis étaient un vecteur d'attaque principal.
- Durée de vie limitée pour les jetons granulaires : Les nouveaux jetons granulaires, qui permettent des autorisations plus fines, auront une durée de vie maximale de sept jours (avec un maximum de 90 jours dans certains cas). Cela réduit considérablement la marge de manœuvre des attaquants si un jeton est volé.
- Extension de la publication de confiance : La prise en charge par npm de la publication de confiance, introduite en juillet 2025, supprime la nécessité de gérer les jetons API dans les systèmes CI/CD. Au lieu de cela, les fournisseurs CI/CD (tels que GitHub Actions) peuvent attester directement de l'identité du publiant, et npm vérifie cette attestation. C'est le standard d'or, car cela élimine le jeton en tant que secret dans votre pipeline de construction.
La transition, bien que nécessaire, a causé quelques perturbations de flux de travail pour les développeurs habitués aux anciennes pratiques. La dépréciation de la 2FA TOTP au profit de la 2FA basée sur FIDO (comme WebAuthn/passkeys) est également un changement important, car l'authentification résistante au phishing est démontrablement supérieure à la TOTP contre les attaques sophistiquées. Bien que certains développeurs puissent trouver le passage aux passkeys difficile en raison de la compatibilité des appareils, les avantages en matière de sécurité sont indéniables.
Pour ceux qui publient à partir de CI, la recommandation est d'utiliser npm publish --provenance avec la configuration Trusted Publishers, contournant complètement le besoin de jetons explicites dans votre environnement CI. Pour la publication locale, assurez-vous que votre 2FA est à jour et résistant au phishing.
Au-delà de npm audit : le paysage en évolution de l'analyse des dépendances
npm audit est un incontournable depuis 2018, faisant un travail correct pour signaler les vulnérabilités connues dans votre arbre de dépendances en vérifiant la base de données des avis publics npm. Et bien qu'il s'agisse d'un moyen rapide et intégré d'identifier les problèmes, les événements récents ont mis en évidence ses limites. Un npm audit ne fonctionne que sur les vulnérabilités connues. Il ne détecte pas les nouveaux logiciels malveillants, les attaques subtiles de la chaîne d'approvisionnement qui modifient les paquets légitimes ou les vulnérabilités dans votre propre code.
Le ver "Shai-Hulud", par exemple, a compromis des paquets et les a republiés avec des logiciels malveillants. Bien que npm audit puisse éventuellement détecter les nouvelles versions malveillantes si des avis sont publiés, la propagation initiale peut être rapide. Cela souligne la nécessité d'une approche à plusieurs niveaux.
C'est là que les outils spécialisés brillent vraiment. Des solutions comme Snyk et SonarQube vont beaucoup plus loin. Snyk, par exemple, offre une détection des vulnérabilités en temps réel dans les dépendances, une surveillance continue et même des demandes de tirage automatisées pour appliquer les corrections. SonarQube, bien que plus large dans sa portée pour la qualité du code, fournit également une analyse de sécurité complète pour JavaScript et Node.js, capable de casser les constructions si les seuils de sécurité ne sont pas respectés.
L'intégration de ces outils dans les pipelines CI/CD n'est plus un "plus" mais un "must-have". Une configuration typique peut impliquer :
- Hooks pré-commit : Exécution de linters de base et d'analyses statiques pour détecter les problèmes évidents dès le début.
- Étape de construction CI : Exécution de
npm auditpour une vérification rapide, mais surtout, intégration d'un outil SCA (Software Composition Analysis) robuste comme Snyk ou d'un outil SAST (Static Application Security Testing) comme SonarQube. - Surveillance post-déploiement : Analyse continue des applications déployées et de leurs dépendances à la recherche de nouvelles vulnérabilités.
Le constat ici est que, bien que npm audit soit accessible, il s'agit d'une base. Compter uniquement sur lui en 2025, c'est comme apporter un couteau à beurre à une fusillade. Les outils commerciaux et open source avancés, bien qu'ils nécessitent plus de configuration et potentiellement des coûts, offrent la profondeur nécessaire pour sécuriser véritablement les applications modernes.
Sécurité d'exécution réimaginée : les permissions de Deno et la vision de JSR
Bien que npm soit le gestionnaire de paquets dominant pour Node.js, l'écosystème JavaScript plus large connaît une évolution fascinante des environnements d'exécution, Deno et Bun défiant l'hégémonie de Node.js. Ce qui est passionnant, c'est la façon dont leurs philosophies influencent la sécurité. Comprendre les différences entre Node.js, Deno, Bun en 2025 : Choisir votre environnement d'exécution JavaScript est désormais une condition préalable à une architecture sécurisée.
Deno : la sécurité d'abord par défaut
Deno, créé par le fondateur de Node.js Ryan Dahl, a la sécurité intégrée à son cœur. Contrairement à Node.js, qui accorde aux scripts un accès illimité au système par défaut, Deno fonctionne avec un modèle de permissions en bac à sable. Cela signifie qu'un programme Deno ne peut pas accéder au système de fichiers, au réseau ou aux variables d'environnement sans autorisation explicite.
Par exemple, pour autoriser l'accès au réseau et la lecture du système de fichiers, vous exécuteriez votre script Deno avec des indicateurs :
deno run --allow-net --allow-read app.ts
Ce modèle de permissions explicite est un tournant pour prévenir les attaques de la chaîne d'approvisionnement, où les paquets malveillants tentent souvent de soutirer des données ou de compromettre le système hôte. Si une dépendance compromise tente de fetch des données à partir d'un domaine non autorisé ou de read des fichiers sensibles, Deno refusera simplement, à moins que vous n'ayez explicitement accordé cette permission.
JSR : un nouveau registre pour JavaScript moderne
Introduit en version bêta publique en mars 2024, JSR (JavaScript Registry) est la réponse de Deno à un registre de paquets moderne. JSR n'est pas destiné à forker npm mais à s'appuyer sur son succès, en adoptant ESM, la prise en charge native de TypeScript et en mettant l'accent sur la sécurité et l'expérience développeur.
L'une des caractéristiques de sécurité remarquables de JSR est la "publication sécurisée et sans jeton". Semblable à la publication de confiance de npm, JSR vise à protéger contre les attaques de la chaîne d'approvisionnement en supprimant la nécessité de jetons de longue durée pendant le processus de publication. JSR se concentre également sur la provenance complète des paquets publiés, garantissant des informations de construction vérifiables.
Bun : la vitesse avec une sécurité en évolution
Bun, le nouveau venu construit en Zig, donne la priorité à la vitesse brute dans tous les aspects : exécution, installation de paquets, regroupement et tests. Bien que Bun soit incroyablement rapide et offre une compatibilité npm, son modèle de sécurité est actuellement plus similaire à celui de Node.js, avec un accès illimité par défaut.
Cependant, le cycle de développement rapide de Bun suggère que des fonctionnalités de sécurité plus explicites pourraient être à l'horizon. Pour l'instant, si vous tirez parti des performances incroyables de Bun, il est essentiel de renforcer votre sécurité avec une analyse des dépendances et des garanties CI/CD robustes, car son bac à sable natif n'est pas aussi mature que celui de Deno.
Le rôle crucial de package-lock.json et SRI : l'intégrité que vous ne pouvez pas ignorer
Le fichier package-lock.json est bien plus qu'une simple liste de versions épinglées ; c'est un manifeste cryptographique de votre arbre de dépendances. Son champ integrity, en particulier, contient un hachage d'intégrité de sous-ressource (SRI), généralement SHA512, pour chaque paquet. Ce hachage est une empreinte digitale unique du contenu du paquet tel qu'il a été initialement publié sur le registre.
Lorsque vous exécutez npm install (ou npm ci dans CI/CD, ce qui est fortement recommandé pour la reproductibilité), npm télécharge le paquet, recalcule son hachage et le compare à la valeur integrity dans votre package-lock.json. S'ils ne correspondent pas, l'installation échoue, signalant une éventuelle falsification. Il s'agit de notre première et souvent la plus critique ligne de défense contre les acteurs malveillants modifiant les paquets dans le registre ou pendant le transit.
Cependant, ce mécanisme n'est pas à l'abri de toutes les attaques de la chaîne d'approvisionnement. Le vecteur d'attaque du "empoisonnement du fichier de verrouillage" le démontre : si un attaquant prend le contrôle du compte d'un mainteneur, il peut publier une version malveillante d'un paquet et mettre à jour le package-lock.json dans le dépôt légitime avec le nouveau hachage d'intégrité malveillant. Si ce package-lock.json compromis est validé et qu'un npm install ou npm ci est exécuté, le paquet malveillant sera installé car le hachage d'intégrité correspond à la version de l'attaquant.
C'est pourquoi npm provenance est si crucial en tant que couche de défense supplémentaire, prouvant qui a publié le paquet et comment il a été construit. Cela ajoute une "source de vérité" au-delà du simple hachage.
Les développeurs doivent toujours :
- Valider
package-lock.json: Cela garantit des installations déterministes et fournit les hachages d'intégrité pour la vérification. - Examiner les différences
package-lock.jsondans les PR : Recherchez les modifications inattendues, en particulier des versions de paquets ou des hachages d'intégrité, qui pourraient indiquer un acteur malveillant tentant d'injecter une dépendance compromise. - Assurez-vous que SHA-512 est utilisé : Les anciens fichiers
package-lock.jsonpeuvent utiliser SHA-1, qui est cryptographiquement faible et vulnérable aux attaques par collision. Les versions modernes de npm utilisent par défaut SHA-512, mais si vous travaillez sur un ancien projet, une nouvelle installationnpmaprès avoir suppriménode_modulesetpackage-lock.json(puis validé la nouvelle) peut mettre à niveau ces hachages.
# Pour forcer la mise à jour vers SHA512 (utilisez avec prudence, validez les modifications après !)
rm -rf node_modules package-lock.json
npm install
Se défendre contre les attaques de script du cycle de vie : la menace silencieuse
L'une des fonctionnalités les plus puissantes - et les plus dangereuses - des paquets npm est les scripts du cycle de vie. Il s'agit de commandes shell arbitraires définies dans package.json (par exemple, preinstall, install, postinstall, prepack, prepare) qui s'exécutent à différentes étapes du processus d'installation ou de publication du paquet. Bien qu'incroyablement utiles pour la compilation, la configuration ou la construction de modules natifs, ils constituent également un vecteur principal pour les attaques de la chaîne d'approvisionnement.
Un script postinstall malveillant, par exemple, peut exécuter un code arbitraire sur la machine d'un utilisateur immédiatement après l'installation d'un paquet. Cela peut aller du vol de variables d'environnement et d'informations d'identification à l'installation de logiciels malveillants supplémentaires. Les attaques de typosquatting d'octobre 2025, qui ont utilisé des voleurs d'informations en plusieurs étapes et ont lancé des terminaux cachés pour extraire les mots de passe du système et les cookies du navigateur, ont largement utilisé les scripts postinstall.
La défense contre cela nécessite une approche à plusieurs facettes :
- Indicateur
--ignore-scripts: Pour les déploiements de production ou lors de l'audit de nouvelles dépendances, l'exécution denpm install --ignore-scriptspeut empêcher ces scripts de s'exécuter. Il s'agit d'une garantie cruciale, en particulier dans les environnements CI/CD où vous souhaitez minimiser la surface d'exécution.npm install --ignore-scripts # Ou via une variable d'environnement pour un effet global NPM_CONFIG_IGNORE_SCRIPTS=true npm install - Examen attentif de
package.json: Lors de l'ajout de nouvelles dépendances, inspectez toujours leurpackage.jsonà la recherche de scripts du cycle de vie suspects. Si un simple paquet utilitaire a un scriptpostinstallcomplexe, c'est un signal d'alarme. - Environnements en bac à sable : L'exécution de
npm installdans des environnements ou des conteneurs en bac à sable peut limiter le rayon d'impact d'un script malveillant. - Analyse statique : Les outils de sécurité avancés peuvent souvent détecter des modèles suspects dans les scripts du cycle de vie.
La voie à suivre : un écosystème plus résilient
En regardant en arrière sur 2024 et 2025, il est clair que l'écosystème de paquets JavaScript a été mis à rude épreuve, mais qu'il en ressort plus fort. Les attaques récentes, bien que douloureuses, ont accéléré l'adoption de fonctionnalités de sécurité essentielles. Nous évoluons vers :
- Identité et provenance plus fortes :
npm provenanceet Sigstore changent la donne, offrant des liens vérifiables du paquet publié à la source et à la construction. Cela déplace la confiance de "J'espère que c'est bien" à "Je peux vérifier que cela a été construit comme prévu". - Flux de publication renforcés : La 2FA obligatoire, les jetons de courte durée et la publication de confiance rendent beaucoup plus difficile pour les attaquants de compromettre les comptes des mainteneurs et d'injecter du code malveillant. Il s'agit d'une défense pratique et solide contre le phishing.
- Analyse sophistiquée : Bien que
npm auditreste utile, la dépendance croissante aux outils SCA et SAST avancés, intégrés en profondeur dans le SDLC, est essentielle pour détecter les menaces connues et nouvelles. - Sécurité au niveau de l'exécution : Le modèle de permissions par défaut de Deno et le registre JSR axé sur la sécurité repoussent les limites du possible dans un environnement JavaScript sécurisé. Ce ne sont pas seulement des "alternatives" mais des "innovations" qui influenceront l'ensemble de l'écosystème.
Cependant, nous ne sommes pas sortis de l'auberge. L'ampleur de l'écosystème npm (4 500 milliards de requêtes en 2024 à lui seul) en fait une cible privilégiée. L'adoption de ces nouvelles fonctionnalités de sécurité n'est pas universelle, et les projets hérités continueront de poser des défis. L'expérience développeur peut encore être maladroite lors de l'intégration de nouvelles mesures de sécurité, et la documentation de certaines fonctionnalités expérimentales (comme le modèle de permissions expérimental de Node.js, qui est encore en évolution) peut être rare.
Mon avis ? Accueillez ces changements avec enthousiasme. Intégrez npm publish --provenance dans votre CI/CD. Exigez une 2FA résistante au phishing pour votre équipe. Ne vous contentez pas d'exécuter npm audit ; investissez dans une analyse plus approfondie. Examinez attentivement package-lock.json et réfléchissez à deux fois avant d'activer les scripts du cycle de vie provenant de sources inconnues. L'écosystème JavaScript est plus résilient que jamais, mais sa force dépend en fin de compte de notre vigilance collective et de notre volonté d'adopter ces mesures de sécurité pratiques et efficaces. Nous construisons l'avenir, et faire en sorte qu'il soit sécurisé est notre responsabilité commune.
Sources
🛠️ Outils connexes
Explorez ces outils DataFormatHub liés à ce sujet :
- Formateur JSON - Formater package.json
- Générateur de hachage - Vérifier l'intégrité du paquet