Le tag relu n'est pas le code exécuté : lockfiles GitHub Actions

Vous relisez une pull request qui ajoute uses: some-org/deploy-action@v4 à un workflow. L'action a l'air correcte, vous approuvez, elle tourne. Un mois plus tard, le même workflow repart, toujours sur v4, et exécute un code que personne dans l'équipe n'a lu. Rien n'a bougé dans votre dépôt. C'est le tag qui a bougé. Le 14 octobre 2026, GitHub a ouvert en préversion publique les lockfiles de workflow pour combler précisément ce trou, et la fonction est disponible sur les offres Free et Team en plus d'Enterprise Cloud.

Un workflow relu n'est pas une exécution relue

Les tags et les branches peuvent être déplacés après la revue d'un workflow. GitHub décrit le risque sans détour : si une action est compromise, un tag ou une branche déplacés peuvent faire entrer du code malveillant dans vos exécutions sans aucun changement dans votre dépôt. L'historique des diffs reste propre, la protection de branche ne se déclenche jamais, et le changement n'existe que dans le dépôt de quelqu'un d'autre. Pour un workflow qui détient une clé de déploiement ou un jeton de registre, c'est toute la partie qui se joue là.

Ce que le lockfile fige

Selon GitHub, le lockfile vous laisse garder des références lisibles comme @v4 dans le workflow, tandis qu'Actions exécute les commits exacts que vous avez verrouillés. On le génère avec l'extension gh actions-lock de GitHub CLI, qui écrit .github/workflows/actions.lock avec des commits vérifiables pour vos actions, leurs dépendances transitives et les dépendances des workflows réutilisables que vous appelez. Si le tag bouge ensuite, GitHub indique que l'exécution reste sur le commit enregistré.

La différence avec l'épinglage manuel des SHA

La parade manuelle classique, en pratique générale, consiste à écrire le SHA complet de 40 caractères du commit dans la ligne uses:. Ça marche, mais c'est illisible, on oublie facilement de le mettre à jour, et cela ne fige que l'action nommée. Si cette action est une action composite qui appelle d'autres actions par tag, ces références internes restent libres de bouger. Le lockfile couvre cette couche transitive. Et avec Dependabot, selon GitHub, une mise à jour de version d'une action dans un workflow déjà intégré régénère l'entrée correspondante du lockfile dans la même pull request : l'épinglage et la montée de version se relisent ensemble.

L'adopter sans tout changer d'un coup

L'extension de GitHub permet d'intégrer les workflows un par un. Une fois intégré, un workflow doit avoir des entrées de lockfile pour ses dépendances, et ses exécutions utilisent les commits enregistrés. La même extension peut détecter un lockfile périmé sans modifier de fichier, ce qui convient à une étape de CI qui fait échouer la pull request quand le lock n'est plus à jour. Les administrateurs au niveau du dépôt, de l'organisation ou de l'entreprise peuvent aussi activer une politique « Require lockfile », elle aussi en préversion publique.

Une première étape concrète : prenez le workflow de votre dépôt qui détient le secret le plus sensible, en général celui du déploiement, lancez gh actions-lock dessus, lisez les commits qu'il enregistre, puis ajoutez la vérification de lockfile périmé à la CI. Passez ensuite au workflow suivant. GitHub remercie Andrew Nesbitt, François Proulx, Jesse Houwing et William Woodruff d'avoir travaillé avec l'équipe sur la fonction. Source : GitHub Changelog, workflow lockfiles in public preview.