Chaque npm install, pip install ou build Maven fait entrer dans votre produit du code écrit par des personnes que vous n’avez jamais rencontrées. En mars 2026, l’ENISA a publié le Technical Advisory for Secure Use of Package Managers, un guide court et pratique pour le faire en toute sécurité. Cet article le résume et ajoute quelques remarques tirées de notre propre travail en SCA.
Ce que couvre l’avis
L’avis en est à la version 1.1. Il a été révisé après une consultation menée entre décembre 2025 et janvier 2026, qui a recueilli 15 contributions, et il est publié sous licence CC BY 4.0.
Son périmètre est volontairement étroit : la consommation de paquets et la gestion des dépendances au niveau applicatif. Les gestionnaires de paquets des systèmes d’exploitation, la publication sécurisée de paquets, la sécurité des registres eux-mêmes et le développement sécurisé en sont exclus. Les exemples utilisent surtout npm et GitHub, mais les principes valent pour tout écosystème.
Vous installez plus que vous ne pensez
L’avis commence par un exemple simple. Un serveur web Node.js de dix lignes utilisant le framework express entraîne environ 27 dépendances directes, et 68 paquets au total une fois les dépendances transitives résolues. Chacun d’eux fait désormais partie de votre produit.
L’ENISA en tire deux remarques qui méritent d’être répétées :
- Le code “tiers” cesse d’appartenir à quelqu’un d’autre dès qu’il est dans votre build. Il fait partie de votre base de code de confiance et mérite le même examen que votre propre code.
- Code installé ne veut pas dire code atteignable. Votre application n’exécute peut-être qu’une petite partie d’un paquet. Une vulnérabilité dans du code jamais exécuté a moins de chances d’être exploitable, mais “non directement atteignable” n’est pas une garantie : la réflexion, une mauvaise configuration ou des entrées malveillantes peuvent ouvrir des chemins inattendus.
La même interconnexion qui rend les gestionnaires de paquets utiles propage aussi les problèmes. Près de 100 000 paquets dépendent directement d’express, et bien plus d’un million de projets en comptant l’usage transitif.
Deux types de risques
L’ENISA classe les risques liés à la consommation de paquets en deux catégories.
Paquets comportant des vulnérabilités intrinsèques
La première catégorie regroupe les faiblesses des paquets eux-mêmes : code ou conception non sécurisés, paramètres par défaut trop permissifs ou modes de débogage exposés. Ces faiblesses entrent dans votre surface d’attaque alors que vous ne les avez pas écrites.
Les paquets non maintenus aggravent la situation. Les exemples de l’avis :
- node-serialize : sa dernière version, publiée il y a onze ans, comporte une vulnérabilité critique connue de désérialisation. La seule solution est de ne pas l’utiliser, et pourtant il est encore téléchargé chaque semaine.
- tokio-tar : la vulnérabilité “TARmageddon” provenait de cette bibliothèque Rust abandonnée, des années après l’arrêt de sa maintenance.
- crypto-js : abandonnée selon son dépôt, mais encore téléchargée des millions de fois par semaine.
Attaques de la chaîne d’approvisionnement
La seconde catégorie regroupe les attaques où quelqu’un compromet un fournisseur pour atteindre ses clients :
| Attaque | Fonctionnement | Exemples de l'avis |
|---|---|---|
| Paquets malveillants | Un attaquant publie un nouveau paquet contenant du code malveillant et attend que des développeurs l'installent, directement ou comme dépendance transitive. | crypto-encrypt-ts ; le malware GlassWorm dans des extensions VS Code |
| Paquets légitimes compromis | Un attaquant obtient les droits de publication via un compte de mainteneur volé ou obtenu par ingénierie sociale, ou un mainteneur retourne le paquet contre ses utilisateurs. | event-stream, ua-parser-js, l'attaque npm de septembre 2025 contre 18 paquets totalisant 2,6 milliards de téléchargements par semaine, colors et faker |
| Typosquatting | Un paquet malveillant au nom proche de celui d'un paquet populaire, qui attend une faute de frappe. | crossenv imitant cross-env |
| Confusion de dépendances | Un paquet public portant le même nom qu'un paquet interne et un numéro de version plus élevé, récupéré par des outils de build qui consultent les deux registres. | La recherche de 2021 qui a atteint des dizaines de grandes entreprises |
Dans les deux cas, l’effet se propage en cascade. L’avis cite la CVE-2025-55182 dans React, notée 10,0 au CVSS, que les premières estimations associaient à plus de 12 millions de sites web.
Quatre étapes de consommation des paquets
Le cœur de l’avis est un cycle de vie simple pour chaque dépendance : sélectionner, intégrer, surveiller et atténuer. Les deux premières étapes intègrent la sécurité, les deux dernières la maintiennent. Pour chaque étape, l’ENISA donne des recommandations et un aide-mémoire avec des exemples de commandes.
1. Sélectionner : choisir des paquets dignes de confiance
Avant d’évaluer un paquet, demandez-vous si vous en avez vraiment besoin. Moins de dépendances, c’est une surface d’attaque plus réduite et moins de gestion. Vérifiez ensuite :
- qu’il provient d’un registre officiel, idéalement publié via un flux sécurisé avec provenance, comme le Trusted Publishing de npm
- ses vulnérabilités connues, dans OSV, l’EU Vulnerability Database (EUVD), la NVD ou une base commerciale
- que le paquet et le registre prennent en charge les signatures et les empreintes d’intégrité, et que vous n’installez pas directement depuis un dépôt Git ou une URL d’archive qui contourne ces contrôles
- les mainteneurs : méfiez-vous des paquets publiés par de nouveaux comptes n’ayant qu’un seul projet
- les signes de maintenance active : commits récents, versions étiquetées, tickets traités, fichier SECURITY.md. L’ENISA prévient que les étoiles et le nombre de téléchargements peuvent être gonflés et ne doivent pas servir de seul critère.
- les scripts d’installation qui téléchargent du code ou des binaires supplémentaires depuis des URL externes
Par exemple avec npm :
npm audit signatures # vérifier les signatures et la provenance
npm view <package> scripts # rechercher des scripts pre- et post-install
npm view <package> maintainers
npm ls --all # examiner l'arbre complet des dépendancesL’ENISA suggère aussi de tenir, lorsque c’est possible, une liste interne de paquets ou de mainteneurs approuvés.
2. Intégrer : garder le contrôle sur ce que vous installez
- Générez une SBOM à chaque build, pour disposer d’un inventaire de chaque dépendance à des fins de sécurité et de conformité.
- Faites échouer le build s’il contient des composants présentant des vulnérabilités connues élevées ou critiques.
- Imposez l’intégrité : npm vérifie automatiquement les empreintes SHA-512 du fichier de verrouillage ; pip a besoin de
--require-hashes. - Limitez les installations à des registres de confiance, idéalement via un registre local ou un proxy comme Nexus Repository, JFrog Artifactory ou Verdaccio. Un proxy avec cache permet aussi à vos builds de continuer si un paquet disparaît en amont.
- Désactivez les scripts d’installation lorsque c’est possible, en acceptant que certains paquets ne fonctionnent plus.
- Figez les versions avec un fichier de verrouillage versionné et utilisez-le en CI (
npm ci). Lisez les journaux de modifications avant toute mise à niveau.
npm ci --ignore-scripts # installer exactement le fichier de verrouillage, sans scripts d'installation
npm audit --omit=dev --audit-level=high # échouer sur les constats élevés ou critiques
pip install --require-hashes -r requirements.txtL’ENISA signale le compromis du figement des versions : il vous protège des mises à jour non vérifiées, mais prolonge votre exposition aux vulnérabilités connues si personne n’examine et n’applique régulièrement les mises à jour. Elle mentionne aussi une mesure facultative, selon le contexte : n’installer que des versions publiées depuis au moins quelques jours, ce qui laisse à la communauté le temps de repérer une version malveillante avant qu’elle n’atteigne votre build.
3. Surveiller : remarquer quand quelque chose change
Des dépendances sûres le jour de leur ajout ne le restent pas. L’ENISA recommande :
- d’utiliser les données des SBOM pour des contrôles de vulnérabilités continus, par exemple avec Grype ou OSV-Scanner
- d’analyser les dépendances en CI selon un calendrier, et pas seulement quand le code change
- de suivre les flux de vulnérabilités comme l’EUVD, OSV et la NVD, ainsi que les avis lisibles par machine des fournisseurs au format CSAF
- de surveiller les versions obsolètes
- de mettre en place des alertes pour les nouvelles CVE dans les versions figées, les versions dépréciées ou non maintenues, l’absence d’activité des mainteneurs et les changements de mainteneur ou de propriétaire
Ce dernier groupe est facile à négliger. Un nouveau mainteneur a été le point de départ de l’attaque event-stream, et peu d’équipes surveillent les changements de propriétaire.
4. Atténuer : évaluer avant de corriger
L’avis est d’une honnêteté rafraîchissante au sujet des constats SCA. Une version vulnérable dans votre arbre de dépendances signifie que le paquet contient du code exploitable dans certaines conditions. Cela ne signifie pas automatiquement que votre application est vulnérable.
Les étapes d’atténuation de l’ENISA :
- Évaluez le constat avec plus que le score CVSS : l’EPSS pour la probabilité d’exploitation, le catalogue Known Exploited Vulnerabilities de la CISA, les déclarations VEX du fournisseur et l’analyse d’atteignabilité avec des outils comme CodeQL ou Semgrep.
- Priorisez selon un seuil de risque défini, par exemple “CVSS 7,0 ou plus, ou EPSS 0,3 ou plus, est prioritaire”, et concentrez-vous sur les vulnérabilités atteignables et exploitables des dépendances de production.
- Atténuez en mettant à niveau, en appliquant une mesure temporaire comme une règle de WAF ou un feature flag, ou en supprimant, rétrogradant ou isolant le paquet s’il n’existe pas de correctif.
- Documentez et informez : enregistrez un statut VEX (affected, not affected, under investigation ou fixed), régénérez la SBOM, mettez à jour les notes de version et informez si nécessaire les clients, les autorités ou les équipes internes.
Automatisation et développement assisté par l’IA
L’avis se termine sur deux remarques prospectives. Les contrôles manuels ne passent pas à l’échelle de centaines de dépendances réparties dans de nombreux dépôts : la génération de SBOM (Syft, CycloneDX), l’analyse (Grype, OSV-Scanner) et les contrôles d’installation ont leur place dans le pipeline CI/CD.
Et les assistants de code IA changent la question de savoir qui choisit les dépendances. Quand du code est généré avec peu de relecture humaine, personne ne sait peut-être pourquoi un paquet a été ajouté. L’ENISA mentionne le “slopsquatting” : des attaquants enregistrent les noms de paquets que les outils d’IA inventent. Son conseil : garder la visibilité sur chaque paquet introduit par du code généré par IA, vérifier si chacun est nécessaire, automatiser les contrôles de sélection et d’intégration, et renforcer la détection et la réponse pour compenser le contrôle réduit en amont.
Pourquoi c’est important pour le CRA
Le Cyber Resilience Act rend une grande partie de ces pratiques obligatoires pour les fabricants. Ils doivent faire preuve de diligence lorsqu’ils intègrent des composants tiers, open source compris, établir une SBOM, et identifier et corriger les vulnérabilités des composants qu’ils livrent pendant toute la période de support. L’avis ne cite pas le CRA, mais ses quatre étapes se lisent comme une mise en œuvre pratique de ces obligations. Notre guide du CRA pour les PME les détaille.
Notre avis
Pour les équipes qui travaillent avec npm, Python ou Java, c’est une bonne liste de contrôle à garder à côté du pipeline CI. Elle est courte et concrète, et les aide-mémoire transforment chaque recommandation en commande à essayer dès aujourd’hui. La partie sur l’atténuation mérite une attention particulière : les équipes qui traitent chaque constat SCA comme également urgent s’épuisent sur les faux positifs et manquent les quelques-uns qui comptent.
Deux réserves. Les exemples sont très centrés sur npm ; l’avis dit que les principes s’appliquent ailleurs, et c’est vrai, mais vous devrez trouver vous-même les contrôles équivalents dans votre écosystème. Et le C et le C++ ne sont pas du tout abordés, alors qu’ils posent un problème propre : les composants des SBOM manquent souvent des identifiants dont les bases de vulnérabilités ont besoin. Notre article sur l’enrichissement CPE des bibliothèques C++ dans les builds Conan comble cette lacune, et notre guide de déploiement d’OWASP Dependency-Track montre une façon de mettre en place une surveillance fondée sur les SBOM. Pour les SBOM en général, nous avons rédigé une synthèse de l’avis technique de l’ENISA sur les SBOM.
L’ENISA souligne aussi que les outils cités sont des exemples, pas des recommandations. Ce qui compte, c’est le contrôle, pas la marque.