npm stage-only : pourquoi votre CI ne devrait plus publier seule

Un secret CI volé ne devrait pas suffire à publier une version malveillante d’un paquet. C’est précisément la frontière que npm renforce avec les nouveaux tokens stage-only : l’automatisation peut déposer une release en attente, mais pas la rendre installable par les utilisateurs.

Ce que change un token stage-only

Un token granulaire peut désormais recevoir le droit Read and write (stage only). Le workflow utilise alors npm stage publish au lieu de npm publish. La version est envoyée dans une zone de staging, puis un mainteneur doit l’examiner et l’approuver avec une authentification à deux facteurs avant qu’elle soit publiée.

Si la CI tente malgré tout un npm publish avec ce token, npm refuse l’opération. L’intérêt est simple : la compromission du jeton ne donne plus, à elle seule, la capacité de mettre une nouvelle version en production sur le registre.

Le pipeline devient une préparation, pas une autorité finale

Les pipelines CI/CD sont excellents pour reproduire des tâches : tests, build, génération d’artefacts et préparation d’une release. Ils sont moins adaptés lorsqu’un secret longue durée leur donne une autorité irréversible.

Le modèle stage-only sépare donc deux responsabilités : la machine prépare une version reproductible ; une personne autorisée valide le passage en production. Cette étape supplémentaire est particulièrement intéressante pour les paquets sensibles ou largement distribués.

Stage-only ne rend pas le token inoffensif

npm précise que le token conserve d’autres droits d’écriture, notamment la possibilité de déplacer des dist-tags ou de déprécier des versions. Il doit donc rester protégé comme tout autre secret disposant de droits d’écriture.

Et si l’on peut supprimer complètement le secret npm ?

Pour les plateformes compatibles, trusted publishing reste une meilleure cible : la CI s’authentifie auprès de npm avec OIDC et obtient des identifiants courts à la demande, au lieu de stocker un token npm longue durée.

npm permet aussi de combiner trusted publishing et staged publishing : le workflow s’identifie par OIDC, exécute npm stage publish, puis un mainteneur approuve la version. On réduit ainsi à la fois le risque lié au stockage d’un secret et le risque d’une publication entièrement automatisée.

Pourquoi agir avant janvier 2027 ?

Les tokens existants ne changent pas immédiatement. Mais npm vise janvier 2027 pour supprimer la publication directe de nouvelles versions via les tokens qui contournent la 2FA. Les projets qui publient encore ainsi ont donc intérêt à préparer leur migration maintenant.

Le choix dépend du contexte : trusted publishing avec OIDC lorsque la plateforme est compatible ; stage-only comme chemin de migration pour une automatisation encore basée sur token ; ou combinaison des deux pour conserver une approbation humaine avant publication.

Checklist de migration

Inventorier les workflows qui exécutent actuellement npm publish.
Préférer trusted publishing lorsqu’un fournisseur CI compatible peut utiliser OIDC.
Sinon, créer un token stage-only limité aux paquets réellement nécessaires.
Remplacer npm publish par npm stage publish dans l’automatisation.
Prévoir l’approbation 2FA du mainteneur avant mise en ligne.
Révoquer les anciens tokens une fois le nouveau flux validé.

Pour le flux stage-only documenté actuellement, npm demande notamment npm CLI 11.15.0 ou plus récent et Node.js 22.14.0 ou plus récent.

La CI doit automatiser sans concentrer tous les pouvoirs

Ce changement npm illustre une évolution plus large de la sécurité des chaînes logicielles : réduire les secrets longue durée, limiter les permissions et introduire une frontière explicite avant les actions les plus sensibles. Une pipeline compromise reste un incident sérieux, mais elle ne devrait plus pouvoir transformer automatiquement cette compromission en release publique.

Sources

Publié le 19 septembre 2026. Les comportements décrits correspondent à la documentation npm disponible à cette date.