Le trusted publishing de npm peut désormais déplacer les dist-tags via OIDC

GitHub a annoncé le 30 septembre 2026 que le trusted publishing (publication de confiance) de npm peut désormais gérer les dist-tags. Ce sont les étiquettes comme latest qui déterminent quelle version d'un paquet les gens installent. Les pipelines de publication peuvent déplacer ces étiquettes avec un jeton de connexion de courte durée plutôt qu'avec un jeton d'accès npm stocké. Cela supprime une raison courante de conserver un secret npm de longue durée dans un système de CI.

L'autorisation est optionnelle (opt-in). Elle est désactivée au départ sur chaque configuration, ancienne ou nouvelle, si bien que personne n'obtient le pouvoir de déplacer latest sans l'avoir demandé.

Ce que sont le trusted publishing et les dist-tags

Le trusted publishing permet à une tâche de CI, comme un workflow GitHub Actions, de publier sur npm sans mot de passe ni jeton stocké. La tâche prouve son identité avec OIDC, abréviation d'OpenID Connect, une méthode standard pour émettre des jetons d'identité de courte durée. Le registre npm vérifie ce jeton par rapport à une configuration définie par le propriétaire du paquet, puis autorise l'action.

Un dist-tag est un pointeur nommé vers une version d'un paquet. Le tag latest est celui que suivent la plupart des installations. Les projets en ajoutent souvent d'autres, comme next ou beta, pour les versions de test. Jusqu'ici, le trusted publishing pouvait publier un paquet mais pas déplacer ces pointeurs. Les équipes gardaient donc un jeton de longue durée pour cette étape.

Ce que permet la nouvelle autorisation

Chaque configuration de trusted publishing dispose désormais d'un réglage appelé « Allow npm dist-tag », selon le journal des modifications de GitHub. Lorsqu'il est activé, la tâche de CI peut ajouter, supprimer et promouvoir des dist-tags. La documentation de npm liste les commandes correspondantes : npm dist-tag ls, npm dist-tag add et npm dist-tag rm.

GitHub insiste sur la valeur par défaut. « Elle est désactivée par défaut pour les configurations nouvelles comme existantes, si bien qu'aucune configuration n'obtient automatiquement de nouvelle capacité », indique le journal des modifications.

L'autorisation est distincte de la publication. Une configuration peut être autorisée à faire le staging de paquets et à gérer des dist-tags sans être autorisée à exécuter npm publish, selon la documentation. Celle-ci ajoute que les configurations créées après le 3 septembre 2026 peuvent faire le staging de paquets automatiquement, mais que l'accès aux dist-tags doit toujours être activé à la main.

Une règle compte pour la sécurité. Une modification de dist-tag est autorisée « si le jeton OIDC entrant correspond à l'une quelconque des configurations où l'autorisation est activée », écrit GitHub. Chaque configuration dont la case est cochée est donc un moyen de plus de déplacer latest.

Exigences et limites

La documentation de npm fixe ces minimums :

Exigence	Ce que dit la documentation de npm
npm CLI pour les dist-tags via OIDC	11.21.0 ou plus récent
npm CLI pour le trusted publishing en général	11.5.1 ou plus récent
Node.js	22.14.0 ou plus récent
GitHub Actions	Runners hébergés par GitHub uniquement
GitLab CI/CD	Runners partagés de GitLab.com uniquement
CircleCI	CircleCI cloud uniquement
Runners auto-hébergés	Pas encore pris en charge

Selon la documentation, les runners auto-hébergés « sont prévus pour de futures versions ». Les sources divergent sur la prise en charge des services de CI. Un billet sur DEV Community écrit par un développeur nommé Leo mentionne aussi Buddy et Jenkins, ce dernier via des plugins, mais la propre documentation de npm ne liste que les trois services ci-dessus.

Pourquoi les dist-tags sont une cible

Déplacer un dist-tag est aussi puissant que publier. Le billet de Leo qualifie le contrôle des dist-tags de risque sérieux pour la chaîne d'approvisionnement, car un attaquant capable de réécrire latest peut diriger chaque nouvelle installation vers une mauvaise version. Les versions malveillantes sont un schéma bien réel : en août, des versions piégées du crate Rust arrayref ont exécuté une charge utile distante pendant les compilations.

Leo met aussi en garde contre une défaillance humaine. Les équipes confrontées à une publication bloquée risquent de cocher la case sur chaque configuration pour faire disparaître le problème. Le billet recommande plutôt une seule configuration dédiée aux publications, avec une correspondance stricte : un fichier de workflow précis, un environnement protégé et une étape d'approbation manuelle.

Ce que cela signifie pour les développeurs

Mettez d'abord à jour la npm CLI dans votre tâche de publication. Les modifications de dist-tags via OIDC exigent npm 11.21.0 ou plus récent et Node.js 22.14.0 ou plus récent. Une CLI plus ancienne dans une image de CI figée échouera, même avec le réglage activé.

N'activez l'autorisation qu'à un seul endroit. Comme n'importe quelle configuration correspondante peut à elle seule déplacer latest, activez-la sur votre configuration de publication et laissez-la désactivée sur les configurations de staging et de test. Revoyez la liste après chaque changement.

Verrouillez étroitement la configuration. Liez-la au fichier de workflow exact qui produit les versions, et exigez un environnement protégé avec une étape d'approbation. Ainsi, ni un workflow de pull request ni une tâche annexe compromise ne pourra déplacer vos tags.

Supprimez l'ancien jeton une fois la bascule opérationnelle. Le but de ce changement est de ne plus stocker de secrets npm de longue durée dans la CI. Après une publication réussie via OIDC, retirez le jeton restant de vos secrets de CI et révoquez-le sur npm.

Ne gardez un jeton que là où c'est indispensable. Si vous compilez sur des runners auto-hébergés, le trusted publishing ne vous couvre pas encore. Limitez ce jeton aux paquets dont il a besoin, et renouvelez-le à intervalles réguliers jusqu'à ce que npm prenne en charge l'auto-hébergement.

Vérifiez vos tags après chaque publication. Exécutez npm dist-tag ls sur votre paquet et confirmez que latest pointe là où vous l'attendez. C'est une vérification de deux secondes qui détecte à la fois les erreurs et les attaques.