GitHub Actions : les lockfiles de workflow en test
GitHub Actions teste des lockfiles de workflow qui figent chaque action sur un commit précis. Fonctionnement, outil gh actions-lock et limites.
Les tags bougent, les lockfiles restent. Depuis le 14 octobre 2026, GitHub Actions propose en préversion publique des lockfiles de workflow. Le principe, familier des gestionnaires de paquets, arrive dans la CI de GitHub : chaque action utilisée par un workflow est figée sur un commit précis, consigné dans un fichier versionné. L'objectif est de fermer une brèche connue de la chaîne d'approvisionnement logicielle.
Le problème : des références qui changent
Dans un workflow, une action est le plus souvent appelée par un tag (v4) ou une branche. Or ces références peuvent être déplacées après la relecture du workflow. Une action compromise, ou un tag réécrit par un attaquant, peut ainsi changer le code exécuté dans la CI sans qu'aucune ligne ne bouge dans le dépôt. Jusqu'ici, la parade consistait à épingler manuellement chaque action sur son SHA complet, une pratique efficace mais fastidieuse à maintenir, notamment pour les dépendances transitives.
Comment fonctionnent les lockfiles
Le lockfile prend la forme d'un fichier .github/workflows/actions.lock. Il est généré par gh actions-lock, une extension de la CLI GitHub publiée dans le dépôt public github/gh-actions-lock. Selon le changelog de GitHub, l'outil enregistre les commits des actions, de leurs dépendances transitives et des workflows réutilisables appelés.
L'adoption se fait workflow par workflow, ce qui permet une migration progressive. Une fois un workflow intégré, chaque dépendance doit avoir une entrée dans le lockfile, et GitHub Actions exécute le commit enregistré, même si le tag ou la branche correspondante a été déplacé entre-temps. L'extension sait aussi vérifier, sans rien modifier, que le lockfile est à jour : de quoi en faire un contrôle automatique dans la CI elle-même.
Politique d'obligation et Dependabot
Une politique « Require lockfile », elle aussi en préversion, permet aux administrateurs d'entreprise, d'organisation ou de dépôt d'imposer l'usage des lockfiles à leur niveau. Dependabot suit le mouvement : lorsqu'il propose la mise à jour d'une action dans un workflow déjà intégré, il régénère l'entrée correspondante du lockfile dans la même pull request. La référence et le commit verrouillé restent ainsi synchronisés sans configuration supplémentaire.
Qui peut l'utiliser
D'après la note mise à jour par GitHub le 14 octobre, la préversion est ouverte aux offres GitHub Enterprise Cloud (y compris avec résidence des données), Team et Free. La documentation précise que la fonctionnalité est susceptible d'évoluer.
Ce que les lockfiles ne font pas
GitHub insiste sur une limite : verrouiller une dépendance ne dit rien de sa sûreté. Le lockfile garantit que le code exécuté est bien celui qui a été relu, pas que ce code est sain. La revue des actions tierces reste donc nécessaire avant de les verrouiller, de même que la limitation des permissions du GITHUB_TOKEN.
Ce qu'il faut faire
Pour les équipes qui dépendent de nombreuses actions tierces, tester les lockfiles sur un workflow sensible (déploiement, publication de paquets) est un premier pas raisonnable, avant d'envisager la politique d'obligation. Cette évolution s'inscrit dans un mouvement plus large de durcissement des plateformes DevOps, après la fin des PAT globaux sur Azure DevOps ou les nouveaux quotas d'API de GitLab.com.