Le 14 octobre 2026, GitHub a ouvert en préversion publique les lockfiles de dépendances de workflow pour GitHub Actions. La fonctionnalité répond à un angle mort connu des pipelines CI/CD : un workflow qui référence une action par son tag (uses: owner/action@v3) peut exécuter un code différent d’une exécution à l’autre si ce tag est déplacé, y compris en cas de compromission de l’action. Les lockfiles figent chaque dépendance sur un commit revu, sans changer la syntaxe des workflows existants.
Le problème : des tags qui peuvent bouger
Dans un workflow GitHub Actions classique, les références par tag ou par branche ne garantissent rien sur la stabilité du code exécuté : un mainteneur peut réassigner un tag à un nouveau commit, intentionnellement ou après une prise de contrôle du dépôt. C’est l’un des vecteurs d’attaque de chaîne d’approvisionnement les plus documentés sur les plateformes CI/CD, et jusqu’ici la seule parade fiable consistait à épingler manuellement chaque action sur un hash de commit, une pratique rarement tenue à jour.
Comment fonctionnent les lockfiles
La mise en œuvre passe par une extension du CLI GitHub, gh actions-lock, qui génère un fichier .github/workflows/actions.lock. Ce fichier enregistre les commits à utiliser pour chaque action, y compris leurs dépendances transitives et les workflows réutilisables appelés. L’adoption se fait workflow par workflow : une fois un workflow intégré, toutes ses dépendances doivent figurer dans le lockfile, et GitHub Actions exécute alors exactement les commits enregistrés.
gh extension install github/gh-actions-lock
gh actions-lock init
gh actions-lock verifyLa commande verify contrôle que le lockfile est à jour sans modifier aucun fichier, ce qui permet de l’intégrer comme vérification obligatoire dans une pull request plutôt que de la lancer seulement en local.
Dependabot et politique d’application
Lorsque Dependabot ouvre une mise à jour de version pour une action déjà verrouillée, il régénère automatiquement l’entrée correspondante du lockfile dans la même pull request, sans configuration supplémentaire. En parallèle, une politique « Require lockfile », elle aussi en préversion publique, permet à un administrateur d’imposer l’usage des lockfiles à l’échelle de l’entreprise, de l’organisation ou du dépôt.
| Niveau | Qui l’active | Effet |
|---|---|---|
| Dépôt | Administrateur du dépôt | Impose le lockfile aux workflows de ce dépôt uniquement |
| Organisation | Administrateur d’organisation | Impose le lockfile à tous les dépôts de l’organisation |
| Entreprise | Administrateur d’entreprise | Impose le lockfile à l’ensemble des organisations rattachées |
Verrouiller une dépendance fige une révision précise, mais ne garantit pas sa sûreté : la relecture du code reste la responsabilité de l’équipe qui l’adopte.
github/gh-actions-lock.L’adoption reste volontaire tant que la politique « Require lockfile » n’est pas activée par un administrateur, ce qui laisse le temps aux équipes de migrer leurs workflows les plus sensibles en premier, typiquement ceux qui touchent au déploiement ou à la publication de paquets. Pour une équipe qui pratique déjà le durcissement systématique de ses environnements de production, le lockfile de workflow s’inscrit dans la même logique : réduire la surface d’attaque en éliminant les références mouvantes plutôt qu’en les surveillant après coup.
Mise en route
L’extension s’installe depuis le dépôt public github/gh-actions-lock, au même titre que les autres extensions listées dans le panorama des outils en ligne de commande pour le développement web. Après génération, le lockfile et les modifications de workflow qu’il entraîne doivent être revus et commités comme n’importe quel changement de configuration CI.
Ce qu’il faut retenir
- Les lockfiles de workflow épinglent chaque action GitHub Actions sur un commit précis, au lieu d’un tag ou d’une branche qui peut bouger.
- L’adoption se fait workflow par workflow via l’extension
gh actions-lock, avec une vérification intégrable en CI. - Dependabot régénère automatiquement les entrées du lockfile lors des mises à jour de version.
- Une politique d’application existe à trois niveaux, mais reste optionnelle tant qu’un administrateur ne l’active pas.
- Le verrouillage protège contre le déplacement d’un tag, pas contre l’intégration d’une dépendance déjà malveillante au moment où elle est figée.
Ce type de fonctionnalité aurait dû exister depuis longtemps : épingler une action sur un hash de commit est une bonne pratique connue depuis des années, mais presque personne ne la maintient à la main. Automatiser le verrouillage et le relier à Dependabot change la donne, à condition que les équipes activent réellement la politique d’application plutôt que de laisser le lockfile comme une option qu’on oublie. — Simon Janvier
Pour aller plus loin : l’annonce officielle sur le changelog GitHub.
