npm scanne les malwares à la publication : ce qui change pour votre supply chain

Le 28 juillet 2026, GitHub a activé un scan automatique anti-malware au moment de la publication sur npm. Chaque nouveau paquet, et chaque nouvelle version d'un paquet existant, passe désormais par une vérification avant de devenir installable. Ce changement introduit un léger délai dans votre workflow de publication, mais il referme une porte que les attaquants de la chaîne d'approvisionnement logicielle (supply chain) exploitaient depuis des années : publier, laisser le paquet s'installer chez des milliers de développeurs, puis compter sur la lenteur de la détection a posteriori.

Pour ceux qui découvrent le sujet : npm est le registre de paquets qui alimente la quasi-totalité de l'écosystème JavaScript et Node.js. Un paquet malveillant glissé dans une chaîne de dépendances (via un typo-squatting, un compte de mainteneur compromis ou une dépendance transitive piégée) peut se propager à des milliers de projets en aval avant que quiconque ne s'en aperçoive. GitHub, qui opère le registre npm, muscle donc sa défense en amont : au moment même où le code arrive sur le registre, plutôt qu'après coup.

Ce qui change concrètement à la publication

Concrètement, chaque npm publish déclenche désormais un scan avant que le paquet ne soit disponible à l'installation. Trois issues sont possibles :

• Publication normale si rien de suspect n'est détecté.
• Mise en attente pour revue manuelle si le scan a un doute.
• Blocage si le paquet est identifié comme malveillant.

Le délai typique annoncé par GitHub est d'environ cinq minutes entre la publication et la disponibilité réelle du paquet. Il peut grimper à 15 minutes ou plus aux heures de forte affluence, ou selon la taille et le contenu du paquet. GitHub précise que ces durées reflètent un comportement observé à date, pas un engagement de service contractuel : elles peuvent évoluer avec l'amélioration du scanner.

Pendant que le scan est en cours, la commande npm dist-tag continue de fonctionner normalement. En revanche, tout ce qui dépend de la version publiée, comme npm deprecate ou npm unpublish, reste bloqué tant que le paquet n'est pas passé le scan et n'est pas disponible.

Paquet bloqué : la procédure côté mainteneur

Si un paquet est bloqué, son mainteneur reçoit une notification avec la possibilité de faire appel. Selon la sévérité et le niveau de confiance du signalement, GitHub indique que des mesures supplémentaires peuvent viser le ou les comptes associés, conformément à ses politiques existantes. npm bloque les malwares qu'il parvient à détecter, et l'équipe de GitHub précise travailler en continu à améliorer la couverture de détection et réduire le temps de scan. Pour le détail de ce qui est autorisé ou non sur le registre, GitHub renvoie vers ses npm Acceptable Use Policies.

La nouvelle métadonnée contentPolicy pour le contenu à double usage

Le deuxième volet de l'annonce concerne un problème bien connu des éditeurs d'outils de sécurité : certains paquets parfaitement légitimes (scanners de vulnérabilités, proof-of-concept, outils de pentest, générateurs de payloads pour des tests autorisés) ressemblent, aux yeux d'un scanner automatique, à du code malveillant. GitHub introduit donc un champ contentPolicy dans package.json pour que les mainteneurs déclarent explicitement ce contenu à double usage.

Déclarer ce champ impose une obligation supplémentaire : le paquet doit aussi contenir un fichier DISCLOSURE à la racine, en texte brut, décrivant la fonctionnalité à double usage et son usage légitime prévu. C'est ce fichier que l'équipe Trust & Safety de GitHub consulte lors d'une revue manuelle. Attention : déclarer cette métadonnée déclenche potentiellement un scan automatisé additionnel adapté au contenu à double usage, mais ne garantit en rien la publication. Une revue humaine au cas par cas reste possible.

Deux contraintes techniques accompagnent cette déclaration :

• Publication avec 2FA imposée. Un paquet à double usage doit être publié via une méthode qui impose la double authentification : publication de confiance (trusted publishing / OIDC), session interactive avec 2FA, ou publication en deux temps (staged publishing). Le staging impose la 2FA lors de son étape de promotion, ce qui veut dire qu'un jeton d'accès granulaire pouvant contourner la 2FA reste utilisable pour publier vers le staging, mais pas pour publier directement (sans passer par le staging) avec un jeton qui contourne la 2FA : ce cas de figure n'est plus autorisé.
• Déclaration persistante. Une fois qu'un paquet est publié avec la métadonnée de contenu à double usage, cette déclaration doit rester présente dans toutes les versions suivantes. Toute publication qui retire le champ contentPolicy ou le fichier DISCLOSURE sera rejetée.

GitHub précise que cette exigence sera appliquée progressivement, et que les mainteneurs de paquets à double usage identifiés sont contactés directement par email pour ajouter cette métadonnée avant d'être bloqués par défaut.

Ce qu'il faut vérifier dans vos workflows

Pour la grande majorité des publications, aucune action n'est nécessaire au-delà d'accepter ce court délai. Mais deux cas méritent votre attention si vous gérez des paquets npm dans un contexte professionnel :

• Votre CI/CD suppose une installation immédiate après publication. Si un pipeline de release enchaîne npm publish puis npm install dans la foulée (déploiement automatisé, tests de fumée post-publication, mise à jour d'un monorepo interne), il faut désormais tolérer un délai de quelques minutes. Concrètement : ajoutez une boucle de nouvelle tentative avant d'échouer le pipeline, plutôt que de partir du principe qu'un paquet fraîchement publié est disponible à la seconde.
• Vous maintenez un outil de sécurité publié sur npm. Si votre paquet contient des fonctionnalités qui pourraient ressembler à du code malveillant (exécution de payloads, manipulation d'identifiants, automatisation d'attaques dans un cadre de test autorisé), préparez dès maintenant votre champ contentPolicy et votre fichier DISCLOSURE, et passez si besoin à une publication via trusted publishing (OIDC) pour rester conforme à l'exigence de 2FA.

Notre lecture chez CZSyn

Cette évolution s'inscrit dans une tendance de fond chez GitHub : muscler la sécurité de la chaîne d'approvisionnement logicielle à chaque étape du cycle de vie d'un paquet, pas seulement après coup. Un scan à la publication change la donne face aux attaques qui misaient justement sur la fenêtre entre mise en ligne et détection. Pour une PME française qui construit ses applications sur des centaines de dépendances npm, ce filet de sécurité tourne en arrière-plan sans rien coûter en configuration : c'est le meilleur type de sécurité, celle qui ne demande aucun effort pour en profiter.

Le point qui mérite une vraie vigilance, c'est le délai de disponibilité. Beaucoup d'organisations ont des scripts de release maison qui n'ont jamais été pensés pour un registre qui met plusieurs minutes à confirmer un paquet. Nous recommandons à nos clients qui publient des paquets internes ou open source d'auditer leurs pipelines de release dès maintenant, plutôt que de découvrir le problème lors d'un déploiement critique. Quant à la métadonnée de contenu à double usage, elle formalise une zone grise que les éditeurs d'outils de sécurité géraient jusqu'ici au cas par cas, avec le risque de se faire bloquer sans recours clair. Un cadre déclaratif, même contraignant, vaut mieux qu'une décision arbitraire du scanner.

Sources primaires

• GitHub Changelog, « npm publish-time malware scanning and dual-use metadata », 28 juillet 2026.
• Documentation officielle npm, docs.npmjs.com.
• GitHub Changelog, page d'accueil des annonces github.blog/changelog.