Lier l’identité de publication npm et PyPI aux artefacts de version approuvés

Ce que c'est

État au 25 octobre 2026. La publication de confiance échange une identité CI contre des identifiants temporaires de registre, au lieu de stocker un jeton de publication permanent. Avant de modifier un workflow de publication, revérifier les fournisseurs pris en charge par les registres, les restrictions relatives aux runners et les exigences de configuration. La documentation citée est une référence évolutive consultée pour cette analyse, pas un avis d’incident daté.

Pour npm, les prérequis documentés sont npm CLI 11.5.1 ou ultérieur et Node 22.14.0 ou ultérieur. Cet article porte sur les workflows GitHub Actions qui publient soit des paquets npm, soit des distributions Python sur PyPI.

Pourquoi c'est important

Le modèle de sécurité de PyPI laisse explicitement à l’éditeur la responsabilité de l’intégrité du workflow. Les identifiants temporaires restent sensibles, et un workflow autorisé compromis peut les obtenir. Supprimer les jetons stockés réduit l’exposition des identifiants sans rendre sûre l’exécution des dépendances.

La documentation npm sur la provenance distingue un lien vérifiable vers le code source et les instructions de build d’une garantie d’innocuité du code. La conséquence opérationnelle est simple : un pipeline autorisé peut attester un artefact malveillant. L’approbation doit évaluer les éléments utilisés pour la version et le résultat produit, ainsi que l’identité qui le signe.

Comment l'appliquer

• Enregistrer précisément le propriétaire, le dépôt et le workflow de publication prévus. Pour la configuration GitHub de npm, renseigner le nom du fichier de workflow et associer le nom d’environnement facultatif à l’environnement de publication protégé. Comparer l’identité configurée à la tâche réelle avant de supprimer l’ancien mode d’authentification.
• Suivre le modèle de séparation de PyPI : une tâche de build crée les distributions ; une petite tâche de publication les récupère et les téléverse. N’accorder permissions: {id-token: write} qu’à la tâche qui a besoin d’OIDC. Maintenir l’installation des dépendances, les tests et les modifications non fiables en dehors du périmètre des autorisations de cette tâche.
• Configurer les personnes chargées d’approuver les déploiements dans l’environnement, empêcher l’auto-approbation, restreindre les branches ou tags de publication et désactiver le contournement par les administrateurs lorsque cette option est disponible. Vérifier la disponibilité des fonctionnalités pour le dépôt et l’offre utilisés. Par défaut, GitHub autorise les administrateurs à contourner la protection des environnements ; un environnement nommé ne suffit pas à lui seul.
• Faire porter l’approbation sur des éléments précis : consigner la révision source, l’exécution du build et l’empreinte de l’artefact dans l’enregistrement de publication, puis publier exactement les octets ainsi vérifiés. Comparer l’identité de l’attestation et les informations sur la source à cet enregistrement. Enquêter sur les écarts au lieu de laisser un badge de provenance décider de la publication.
• Examiner le code des workflows et les actions tierces. Accorder aux jetons de dépôt les permissions minimales et fixer les actions à des identifiants complets de commits vérifiés. Ne jamais afficher les identifiants et ne pas afficher le contenu de l’environnement à des fins de débogage. GitHub avertit que le masquage automatique des journaux peut échouer, notamment lorsque les valeurs sont transformées ; examiner aussi les journaux produits en cas d’échec, pas seulement ceux des exécutions réussies.
• Après la migration, supprimer les jetons de publication inutilisés et auditer les déclarations d’éditeurs de confiance. Sur PyPI, ces déclarations appartiennent aux projets et subsistent après le retrait de la personne qui les a créées. Les intégrer explicitement à la procédure de départ des mainteneurs.

Pièges

Une étape d’approbation ne peut pas compenser la compromission du compte d’un approbateur ni des modifications non vérifiées de cette étape elle-même. Un cache de build réutilisable et un runner persistant nécessitent leur propre évaluation de confiance. Consigner les échecs des contrôles d’identité ou d’artefact comme des échecs de publication ; revenir silencieusement à un jeton d’écriture stocké compromet le contrôle recherché.