Les lockfiles de workflow de GitHub Actions passent en préversion publique

GitHub a placé les lockfiles de dépendances de workflow pour GitHub Actions en préversion publique le 14 octobre 2026. Un nouveau fichier, .github/workflows/actions.lock, enregistre le commit exact derrière chaque action qu'utilise un workflow. Une exécution ultérieure ne peut plus intégrer discrètement un code différent. C'était une faille de la chaîne d'approvisionnement que les équipes devaient combler à la main.

GitHub Actions est le système de GitHub qui exécute des tâches automatisées, comme les tests et les déploiements, quand le code change. Ces tâches sont construites à partir d'étapes réutilisables appelées actions. La plupart des actions se trouvent dans les dépôts d'autres personnes.

Le problème que résout le lockfile

Un workflow désigne généralement une action par un tag ou une branche, comme actions/checkout@v6. Ce nom peut pointer vers un code différent demain. « Les tags et les branches peuvent bouger après que vous avez relu un workflow, si bien qu'une exécution ultérieure pourrait lancer un code différent », indique le changelog de GitHub. La documentation de GitHub cite une façon dont cela arrive : le compte d'un mainteneur en amont est piraté et un tag est déplacé.

Jusqu'ici, la principale défense consistait à épingler chaque action sur le hash complet de son commit, appelé SHA, dans le fichier de workflow. La documentation de GitHub indique que ce n'est « plus nécessaire » pour les dépôts qui adoptent un lockfile. L'épinglage manuel oubliait aussi les actions que d'autres actions intègrent. Le lockfile couvre également ces dépendances indirectes, dites transitives.

Comment fonctionne actions.lock

Un outil en ligne de commande appelé gh actions-lock écrit le fichier. C'est une extension du client en ligne de commande gh de GitHub. Installez-le avec gh extension install github/gh-actions-lock, puis lancez gh actions-lock depuis la racine du dépôt. Le fichier commence par un avertissement qui interdit de le modifier à la main.

Chaque entrée de dépendance stocke quatre valeurs : la référence, le commit résolu, et les identifiants numériques du propriétaire et du dépôt. À l'exécution, Actions vérifie ces identifiants. Cela confirme que le dépôt derrière le nom est toujours celui qui a été verrouillé.

Élément	Détail
Fichier	.github/workflows/actions.lock
Outil	gh actions-lock, une extension de GitHub CLI
Couvre	Actions directes, actions transitives, dépendances des workflows réutilisables
Offres dans la préversion	Free, Team, Enterprise Cloud, Enterprise Cloud avec résidence des données
Application	Une politique « Require lockfile » pour les admins d'entreprise, d'organisation ou de dépôt
Statut	Préversion publique depuis le 14 octobre 2026

Les équipes peuvent intégrer les workflows un par un ou tous à la fois, par exemple avec gh actions-lock .github/workflows/ci.yml. Ensuite, chaque action utilisée par le workflow doit avoir une entrée, et Actions exécute le commit enregistré. L'outil réécrit aussi une référence approximative comme @v3 en la version exacte qu'il a trouvée, comme @v3.1.0.

Quand un tag en amont bouge pour une bonne raison, gh actions-lock --relock met l'entrée à jour. Si un commit verrouillé a disparu, par exemple après un force-push, la documentation renvoie à --relock --accept-moved.

Qui y a accès, et ce que fait Dependabot

Le changelog cite quatre offres : Free, Team, Enterprise Cloud et Enterprise Cloud avec résidence des données. Une note de la rédaction indique que GitHub a modifié cette liste le 14 octobre. Les premiers articles, dont celui d'OpenTools, décrivaient la préversion comme réservée à Enterprise Cloud. Aucune des sources ne mentionne GitHub Enterprise Server, l'édition auto-hébergée.

Une politique « Require lockfile », elle aussi en préversion, permet aux admins de rendre les lockfiles obligatoires. Elle s'applique au niveau de l'entreprise, de l'organisation ou du dépôt.

Dependabot est le bot de GitHub qui met à jour les dépendances. Quand il met à jour une action dans un workflow intégré, il régénère désormais l'entrée correspondante du lockfile dans la même pull request. Il n'intègre pas de nouveaux workflows de lui-même, selon la documentation de GitHub.

Ce que le lockfile ne fait pas

Un lockfile fige le code, mais il ne le vérifie pas. Le changelog de GitHub demande aux équipes de relire les dépendances avant de les verrouiller. Le développeur Dave Kurian a fait la même remarque dans son guide sur DEV Community. « Le verrou enregistre le commit vers lequel se résout une dépendance de workflow ; il n'évalue pas si l'action est sûre. »

Les workflows réutilisables comportent un piège. Un workflow réutilisable est un workflow complet que d'autres workflows appellent. Il est couvert par le lockfile du dépôt où il est défini, pas par ceux de ses appelants. Les équipes qui partagent des workflows depuis un dépôt central devraient verrouiller ce dépôt en premier, conseille la documentation.

Ce que cela signifie pour les développeurs

• Commencez par un seul workflow. Verrouillez d'abord un workflow de déploiement ou de release, car ce sont généralement eux qui détiennent les identifiants les plus puissants. Observez quelques exécutions avant d'aller plus loin.
• Corrigez vos listes d'autorisation. Certaines organisations autorisent les actions par tag, comme actions/checkout@v6. Selon la documentation de GitHub, ces entrées ne correspondent plus aux workflows verrouillés, donc remplacez-les par un caractère générique ou un SHA complet.
• Activez d'abord Dependabot pour les actions. Il tient les entrées du lockfile à jour dans la même pull request, pour que les workflows verrouillés ne deviennent pas obsolètes.
• Détectez les lockfiles obsolètes dans la CI. L'outil peut vérifier les entrées sans modifier aucun fichier. OpenTools suggère une vérification obligatoire qui échoue sur un lockfile obsolète, ainsi qu'une revue du fichier par les code owners.
• Attendez que la couverture soit prête pour activer la politique. « Activer la politique avant que la couverture et l'automatisation des mises à jour soient prêtes peut bloquer des exécutions de workflow », prévient OpenTools. Mesurez d'abord, puis imposez.
• Traitez un changement d'identifiant de propriétaire ou de dépôt comme une alerte. Selon la documentation de GitHub, un tel changement devrait être rare. Enquêtez avant de fusionner.