npm durcit la publication de paquets : ce qui change depuis le 2 octobre pour vos pipelines

Les attaques contre la chaîne d’approvisionnement logicielle se sont multipliées en 2026, et l’écosystème JavaScript en est la première cible. Le 2 octobre, GitHub a annoncé deux nouvelles règles pour la publication de confiance (trusted publishing) sur npm. Si vous publiez des paquets depuis GitHub Actions, il y a peut-être un réglage à revoir.

Rappel : la publication de confiance, c’est quoi ?

Disponible pour tous depuis juillet 2025, la publication de confiance permet de publier un paquet npm sans stocker de jeton npm dans les secrets du dépôt. Le registre fait confiance à un dépôt et à un workflow précis : au moment de publier, GitHub Actions obtient un identifiant OIDC de courte durée, que npm accepte à la place d’un jeton permanent. Le CLI npm publie au passage une attestation de provenance.

Moins de secrets qui traînent, donc moins de jetons à voler. Mais encore faut-il que la relation de confiance soit bien configurée.

Règle n° 1 : une configuration non validée expire en 48 heures

Depuis le 2 octobre 2026, une configuration de publication de confiance qui n’a jamais servi expire 48 heures après sa création. Passé ce délai, elle ne peut plus autoriser de publication.

• Une configuration devient validée dès sa première publication réussie, et n’expire plus ensuite.
• Changer de dépôt ou d’identité de projet impose une nouvelle relation de confiance, avec un nouveau délai de 48 heures. Les modifications ordinaires ne relancent pas le compteur.
• Les configurations expirées restent visibles dans les réglages, mais ne comptent plus dans les limites par paquet. Les autres configurations du même paquet ne sont pas touchées.

L’intérêt : une configuration créée « pour plus tard », pointant vers un dépôt qui n’a jamais publié, ne reste plus indéfiniment une porte ouverte.

Règle n° 2 : fini les publications déclenchées par un commentaire

npm refuse désormais les jetons de publication de confiance issus d’événements issue_comment de GitHub Actions. Cette restriction s’ajoute à celle qui existait déjà pour les événements pull_request_target.

Pourquoi ? Parce que ces deux événements peuvent être déclenchés par des personnes extérieures au projet : un commentaire sur une issue, une pull request depuis un fork. Les laisser aboutir à une publication, c’est laisser un inconnu déclencher le code qui signe vos versions.

L’affaire TanStack, en arrière-plan

Ces restrictions font écho à une attaque très documentée. Le 11 mai 2026, en six minutes, un attaquant a publié 84 versions piégées de 42 paquets @tanstack/*. Il n’a volé aucun jeton npm. Il a enchaîné un workflow pull_request_target qui exécutait le code d’un fork, un empoisonnement du cache de GitHub Actions et l’extraction du jeton OIDC depuis la mémoire du runner. Nous revenons sur ce cas en détail dans un prochain article.

La leçon : la publication de confiance prouve d’où vient une publication, pas que le code exécuté dans le workflow est digne de confiance.

Ce qu’il faut vérifier dans vos projets

1. Vos déclencheurs de publication : si un workflow publie sur issue_comment, déplacez-le vers un événement autorisé comme push, release ou workflow_dispatch, comme le recommande GitHub.
2. Vos configurations en attente : si vous avez créé une publication de confiance sans encore publier, elle a peut-être expiré. Recréez-la au moment de publier.
3. Vos workflows pull_request_target : s’ils récupèrent et exécutent le code d’un fork, c’est un risque majeur, publication npm ou non.
4. Vos actions tierces : épinglez-les par empreinte de commit (SHA) plutôt que par étiquette ou par branche (@main).
5. Vos secrets : un workflow ne devrait avoir accès qu’aux secrets dont il a besoin, au moment où il en a besoin.

Côté poste de développement, les agents IA qui lancent des commandes posent la même question de confiance : notre outil open source cmdguard relit chaque commande shell avant exécution et bloque les plus destructrices.

Source

• GitHub Changelog, « Unvalidated npm trusted publishing configurations now expire », 2 octobre 2026 : https://github.blog/changelog/2026-10-02-unvalidated-npm-trusted-publishing-configurations-now-expire
• GitHub Changelog, « npm trusted publishing with OIDC is generally available », 31 juillet 2025 : https://github.blog/changelog/2025-07-31-npm-trusted-publishing-with-oidc-is-generally-available/
• TanStack, « Postmortem: npm supply-chain compromise » : https://tanstack.com/blog/npm-supply-chain-compromise-postmortem