npm accepte dix éditeurs OIDC, avec validation humaine après le scan

Depuis le 3 septembre 2026, npm permet à un même paquet d’utiliser plusieurs configurations de publication fiable fondées sur OIDC. Désormais disponibles pour tous, les changements couvrent ces configurations multiples, l’historique des versions staged et, pour ces dernières, une approbation humaine qui ne devient possible qu’après le scan antiprogiciel, selon le changelog de GitHub.

Depuis cette date, la limite atteint dix trusted publishers par paquet. Les équipes peuvent donc attribuer des identités distinctes aux flux stable, préversion et staging sans conserver de jeton d’écriture durable pour chacun ; l’examen indépendant d’AiCybr confirme également que la publication directe reste optionnelle par configuration et que l’approbation staged attend la fin du scan.

Plusieurs identités courtes pour un même paquet

Un trusted publisher établit une relation de confiance entre npm et un workflow CI/CD déterminé. Lors de la publication, le fournisseur d’intégration continue présente une identité OIDC de courte durée ; npm la compare aux critères enregistrés pour cette connexion, tels que le dépôt, le fichier de workflow et, lorsqu’il est proposé, l’environnement ou le contexte.

La documentation de la publication fiable npm fixe le plafond à dix connexions et prend actuellement en charge GitHub Actions sur les runners hébergés par GitHub, GitLab CI/CD sur les runners partagés de GitLab.com et CircleCI Cloud. Les runners auto-hébergés ne sont pas encore compatibles ; GitHub Actions exige notamment la permission id-token: write.

Les connexions peuvent être ajoutées et supprimées indépendamment dans les réglages du paquet. Elles ne sont toutefois pas modifiables sur place : changer de fournisseur ou de critères d’identité impose de supprimer la connexion concernée, puis d’en créer une nouvelle.

Trois architectures pour stable, préversion et staging

Une première architecture consiste à créer trois configurations étroites et à ne leur permettre que npm stage publish. Les workflows stable, préversion et staging déposent alors leurs versions dans la file d’attente ; aucune ne devient publique sans l’approbation d’un mainteneur authentifié avec la double authentification.

Une deuxième architecture réserve npm publish au workflow stable, identifié par un dépôt, un fichier de workflow et, si le fournisseur le permet, un environnement de production précis. Les préversions et les essais utilisent npm stage publish. La livraison stable peut ainsi rester automatisée, tandis que les chemins expérimentaux conservent une décision humaine avant leur mise à disposition.

Une troisième architecture répartit les connexions entre plusieurs fournisseurs, par exemple pendant une migration de GitHub Actions vers GitLab CI/CD ou CircleCI. L’ancien et le nouveau pipeline disposent chacun de leur configuration OIDC, d’abord limitée au staging ; une fois le nouveau chemin validé, l’ancienne connexion peut être retirée sans réintroduire un secret d’écriture commun.

Ces trois architectures sont des choix de conception, et non des modes prédéfinis par npm. Elles exploitent les mêmes briques : plusieurs connexions simultanées, des critères d’identité propres à chacune et une autorisation de publication directe accordée séparément.

Les configurations s’additionnent sans priorité

Le modèle est additif : une opération de publication ou de staging est autorisée dès que l’identité OIDC reçue correspond à l’une des configurations qui permettent cette action. Les entrées ne se restreignent pas mutuellement et leur ordre d’évaluation n’est pas garanti.

Une connexion trop permissive peut donc annuler le bénéfice pratique d’une configuration plus stricte. Protéger soigneusement le workflow stable ne suffit pas si un autre workflow correspondant au même paquet possède aussi le droit d’exécuter npm publish. Il faut considérer chaque connexion comme une porte d’accès autonome, et non comme une règle intégrée à une chaîne où la plus restrictive l’emporterait.

Pour les nouvelles configurations, npm stage publish est autorisé par défaut, alors que npm publish doit être activé explicitement. Le réglage essentiel se situe donc sur chaque connexion : un chemin limité au staging ne peut pas publier directement, mais une autre identité autorisée à publier reste utilisable indépendamment.

Le scan précède l’approbation humaine en staging

Dans le flux staged, l’ordre est désormais contraint. Le pipeline soumet la version, npm exécute ses contrôles et son analyse antiprogiciel, puis le bouton d’approbation devient accessible. Pendant le scan, ce bouton reste désactivé et l’état de la file est actualisé périodiquement.

Une fois l’analyse terminée, un mainteneur peut approuver ou rejeter la version depuis la CLI ou npmjs.com avec une authentification interactive et la double authentification. Les commandes npm stage list, view, approve et reject ne peuvent pas employer l’identité OIDC : npm réserve cette dernière à npm publish et npm stage publish.

Cette séquence ne signifie pas que toute version ayant achevé le scan est sûre. Elle sépare deux contrôles différents : l’analyse automatisée précède la décision humaine, tandis que le staging empêche l’artefact de devenir public avant cette décision. Une configuration autorisée à publier directement ne bénéficie pas de cette barrière humaine, même si npm analyse aussi les paquets avant leur mise à disposition.

Provenance et jetons gardent des limites précises

Avec la publication fiable, npm produit automatiquement une attestation de provenance pour les paquets publics issus de dépôts publics sur GitHub Actions ou GitLab CI/CD. CircleCI ne bénéficie pas encore de cette génération automatique, et un dépôt privé ne produit pas cette provenance même lorsque le paquet publié est public.

La provenance renseigne l’origine et le chemin de construction ; elle ne remplace ni le scan antiprogiciel ni l’approbation du mainteneur. Les trois mécanismes répondent à des questions distinctes : d’où vient l’artefact, ce que l’analyse automatisée y détecte et si une personne autorisée accepte sa publication.

OIDC supprime le besoin d’un jeton durable pour publier, mais pas nécessairement toute authentification npm dans le pipeline. L’installation de dépendances privées peut encore exiger un jeton granulaire en lecture seule. La séparation utile consiste donc à retirer les secrets persistants dotés d’un droit de publication, tout en isolant les éventuels identifiants nécessaires à la lecture.

Les mainteneurs disposent désormais de dix connexions additives et d’un staging dont l’approbation attend la fin du scan. Le point restant à décider paquet par paquet est la frontière d’automatisation : quelles identités s’arrêtent obligatoirement au staging et lesquelles reçoivent aussi le droit de publier directement.

À lire aussi:

• Veeda AI démarre avec 90 millions, avant d’avoir prouvé ses simulations
• Recruter avec une IA peut refroidir les candidats sans paraître plus compétent
• Pasqal arrive au Nasdaq avec 360 M$, mais les défis quantiques demeurent