Le registre npm analyse maintenant les nouveaux paquets avant de les rendre installables. Une publication peut être acceptée, retenue pour examen manuel ou bloquée. Pour la plupart des projets, l’opération ajoute environ cinq minutes entre npm publish et la disponibilité réelle ; elle peut dépasser quinze minutes selon la taille, le contenu et la charge du service.

Cette latence paraît faible à l’échelle humaine, mais elle casse les pipelines qui publient une version puis tentent immédiatement de l’installer, de la déprécier ou de lancer une promotion dépendante. npm introduit en parallèle une déclaration obligatoire pour les outils dits dual-use, dont les capacités de sécurité peuvent ressembler à celles d’un logiciel malveillant.

La réponse rapide

QuestionRéponse
Tous les paquets sont-ils scannés ?Les nouveaux paquets et versions sont analysés avant leur disponibilité.
Combien de temps faut-il attendre ?Environ cinq minutes habituellement, parfois quinze minutes ou davantage.
Un paquet peut-il être bloqué ?Oui, avec une possibilité de recours selon la notification reçue.
Qu’est-ce qu’un paquet dual-use ?Un outil légitime aux capacités aussi utilisables de façon offensive.
Que faut-il changer dans la CI ?Attendre et vérifier la disponibilité au lieu de supposer qu’elle est immédiate.

La publication devient un processus asynchrone

Jusqu’ici, de nombreux scripts considéraient la réussite de npm publish comme le moment où la version devenait consommable. Le scan crée un état intermédiaire. npm dist-tag continue de fonctionner pendant l’analyse, mais des opérations comme npm deprecate ou npm unpublish attendent la disponibilité du paquet.

Un pipeline robuste doit interroger le registre avec une temporisation progressive et une limite claire. Il ne faut pas relancer aveuglément npm publish, car la version existe déjà et la répétition peut masquer le véritable état. L’étape suivante doit démarrer seulement lorsque le registre renvoie la version attendue.

Les projets qui publient plusieurs paquets liés doivent aussi revoir leur ordre. Si le paquet B dépend immédiatement de la nouvelle version de A, son test d’installation peut échouer pendant la période d’analyse. Un manifeste de publication ou une étape d’attente commune évite des résultats aléatoires.

Trois issues possibles après l’analyse

Un paquet sans signal suspect devient disponible normalement. Un résultat ambigu peut déclencher un examen manuel, ce qui allonge le délai. Un contenu jugé malveillant peut être bloqué, et npm peut agir sur les comptes des mainteneurs selon la gravité et le niveau de confiance.

Le scan ne garantit pas qu’aucun malware ne rejoindra le registre. Les détections automatiques ont des faux négatifs et des faux positifs. La mesure ajoute une barrière au moment le plus utile, avant que la nouvelle version ne soit téléchargée par des mises à jour automatisées.

Les consommateurs doivent donc conserver les autres défenses : verrouillage des versions, revue des changements, alertes Dependabot, exécution avec des droits réduits et analyse des scripts d’installation.

Les outils dual-use doivent se déclarer

Les bibliothèques de test d’intrusion, d’obfuscation ou de recherche en sécurité peuvent ressembler à du code offensif. npm leur demande désormais d’ajouter dans package.json un champ contentPolicy avec la classe dual-use, ainsi qu’un fichier texte DISCLOSURE à la racine du paquet publié.

Ce fichier doit décrire la capacité sensible et son usage légitime. La déclaration peut déclencher une analyse adaptée ou une revue humaine. Elle ne constitue pas une autorisation automatique et ne rend pas acceptable un paquet conçu principalement pour nuire.

Une fois publiée, la déclaration doit persister dans les versions suivantes. La retirer nécessite une revue de l’équipe Trust & Safety. Les mainteneurs doivent donc vérifier le tarball produit avec npm pack --dry-run, pas seulement la présence du fichier dans le dépôt.

L’authentification forte devient structurante

Un paquet dual-use doit passer par une méthode imposant la double authentification. La publication interactive avec 2FA est acceptée. La publication préparée en staging puis promue est également compatible, car la promotion impose la vérification.

En revanche, une publication directe avec un jeton contournant la 2FA n’est pas autorisée. Le trusted publishing via OIDC doit lui aussi utiliser le staging pour ce type de contenu plutôt qu’une publication directe. Cette nuance peut obliger à modifier un workflow GitHub Actions ou GitLab CI qui fonctionnait jusque-là sans intervention.

La migration à effectuer maintenant

Les mainteneurs doivent mesurer le temps entre publication et installation dans leur pipeline, ajouter une boucle de vérification avec timeout, puis traiter séparément les paquets de sécurité. Les monorepos doivent tester les dépendances croisées dans un environnement de prépublication plutôt que contre le registre public pendant sa fenêtre d’analyse.

Il faut aussi préparer une procédure de recours : propriétaire du compte, canal de notification et éléments permettant d’expliquer rapidement un comportement détecté. Une publication bloquée un vendredi soir ne devrait pas dépendre d’une seule personne indisponible.

npm remplace une mise en ligne instantanée par une porte de contrôle. Le coût est quelques minutes et un peu d’ingénierie CI ; le bénéfice potentiel est d’arrêter une version malveillante avant qu’elle n’entre dans des milliers de chaînes de dépendances.