npm fait évoluer les configurations de publication de confiance tandis que GitHub ajoute une condition de fusion liée aux secrets exposés. Ces deux annonces ne constituent pas un verrou unique : il faut examiner séparément les droits de fusion, les identités de publication et l’approbation de diffusion.
Deux annonces, deux points de décision
Le 3 septembre 2026, npm a annoncé la disponibilité générale de plusieurs configurations de publication de confiance par paquet. Elles sont indépendantes et additives : correspondre à l’une peut suffire, sans ordre d’évaluation garanti. La mise en attente est proposée par défaut ; la publication directe est une option propre à chaque configuration. L’approbation d’un paquet en attente devient possible après la fin de l’analyse des logiciels malveillants. Cette analyse existait déjà. [annonce npm]
Le 9 septembre, GitHub a présenté en préversion publique une règle pour les clients GitHub Secret Protection ou GitHub Advanced Security : avant la fusion, l’analyse du commit de tête doit être terminée et aucune alerte concernée introduite par les commits de la pull request ne doit rester ouverte. Les catégories détectées sont configurables et les droits de contournement doivent être examinés. Cette règle complète la protection au moment de l’envoi du code, sans la remplacer. [annonce GitHub]
Décrire chaque droit avant la chaîne de livraison
CI/CD désigne l’intégration et la livraison continues : la chaîne qui construit, contrôle et diffuse un logiciel. Une pull request est une proposition de modification ; un workflow est un ensemble d’étapes automatisées. OIDC, OpenID Connect, permet ici d’identifier le workflow par un jeton de courte durée. Cette identité ne décrit pas à elle seule toutes les autorisations de l’équipe.
La revue proposée par Partitech commence par les chemins possibles : dépôt, workflow, environnement, responsable et possibilité de publication directe. Une configuration supplémentaire doit avoir un propriétaire et une justification. Conservez aussi les comptes et mécanismes qui peuvent contourner le chemin nominal, au lieu de limiter l’inventaire au fichier d’automatisation le plus visible.
| Chemin ou action | Identité / dépôt / workflow | Environnement et critères | Publication directe ou exception | Propriétaire et preuve |
|---|---|---|---|---|
| Fusion GitHub | À inventorier | À relever | Contournement à examiner | À désigner / joindre |
| Configuration stable | À inventorier | À relever | À vérifier | À désigner / joindre |
| Configuration prepublication | À inventorier | À relever | À vérifier | À désigner / joindre |
| Approbation du paquet en attente | À inventorier | À relever | À documenter | À désigner / joindre |
Un modèle OU entre configurations, pas une double validation
Dans cet exemple fictif, A désigne la configuration du workflow stable et B celle de prepublication. La table illustre uniquement la correspondance du jeton OIDC aux configurations. Elle ne remplace pas les autres contrôles et ne signifie pas que le paquet devient immédiatement public.
| Configuration A satisfaite | Configuration B satisfaite | Chemin OIDC correspondant |
|---|---|---|
| Non | Non | Non |
| Oui | Non | Oui |
| Non | Oui | Oui |
| Oui | Oui | Oui |
L’approbation humaine du paquet mis en attente est une étape distincte : elle n’est pas le second terme de cette condition OU. Lors de la revue, demandez pour chaque chemin quelles preuves sont conservées, qui peut en modifier les critères et quelle décision justifie une éventuelle publication directe.
Relier les preuves sans confondre les contrôles
Une alerte fermée n’atteste pas la révocation d’un secret. Selon le fournisseur concerné, documentez la révocation ou la rotation, vérifiez les usages affectés et conservez la décision de traitement. Une absence d’alerte signifie seulement qu’aucune alerte concernée n’est ouverte dans le périmètre contrôlé ; elle ne prouve pas une détection exhaustive.
La conception proposée sépare revue de modification, analyse des secrets, tests applicatifs, identité npm, mise en attente et approbation. Chaque étape conserve son propriétaire et sa preuve. Aucun enchaînement atomique entre fusion et publication n’est supposé. Le principe de confiance explicite rejoint notre article sur les écritures d’agents et leur environnement isolé, mais les droits étudiés ici sont ceux de la livraison GitHub/npm.
Pour un pilote autorisé et isolé, préparez des identités fictives et un paquet de démonstration : aucune configuration correspondante, une correspondance, plusieurs correspondances, analyse encore en cours et exception de fusion. Définissez ce qui devrait être accepté ou refusé à chaque étape, puis collectez les résultats réellement obtenus. Aucun de ces scénarios n’a été exécuté pour cet article ; aucun secret réel ni paquet de production n’est nécessaire à la préparation documentaire.
Le livrable de la revue est la matrice des chemins, accompagnée des propriétaires, exceptions et preuves manquantes. Réexaminez-la après chaque changement de workflow. La préversion GitHub, les limites de détection et les autorisations résiduelles restent des points à suivre ; le nombre de contrôles ne mesure pas à lui seul la sécurité de la livraison.