Le 14 octobre 2026, GitHub a ouvert en préversion publique les fichiers de verrouillage pour GitHub Actions (workflow dependency lockfiles). Le principe ressemble à celui d’un package-lock.json : on garde des références lisibles comme actions/checkout@v4 dans ses workflows, mais l’exécution se fait sur un commit précis, enregistré et relu à l’avance. Pour les équipes qui livrent du code avec des pipelines d’intégration continue, c’est une réponse directe à un risque connu de la chaîne d’approvisionnement logicielle.
Plan de l'article
Le problème : un tag qui bouge après la relecture #
Dans un workflow GitHub Actions, la plupart des développeurs appellent une action par un tag ou une branche. C’est pratique, mais rien ne garantit que ce tag pointe demain vers le même code qu’aujourd’hui. L’annonce de GitHub le résume en une phrase : les tags et les branches peuvent bouger après la relecture d’un workflow, si bien qu’une exécution ultérieure peut lancer un code différent.
Le scénario n’a rien de théorique. En mars 2025, l’action très utilisée tj-actions/changed-files a été compromise. L’alerte de l’agence américaine CISA décrit une faille référencée CVE-2025-30066, qui permettait d’exposer des secrets (clés d’accès, jetons d’accès personnels GitHub, jetons npm, clés RSA privées) dans les journaux d’exécution. La compromission aurait été rendue possible par celle d’une autre action, reviewdog/action-setup@v1 (CVE-2025-30154). Les dépôts qui appelaient ces actions par leur tag ont exécuté le code malveillant sans avoir modifié une seule ligne de leurs workflows.
La parade jusqu’ici : épingler les SHA à la main
La bonne pratique consistait à remplacer chaque tag par le SHA complet du commit. Efficace, mais pénible : les fichiers deviennent illisibles, les mises à jour sont manuelles, et surtout les dépendances transitives restent hors de portée. Une action composite que vous avez épinglée peut elle-même appeler d’autres actions par leur tag.
Ce que fait le fichier actions.lock #
Le nouveau mécanisme repose sur un fichier unique, .github/workflows/actions.lock. Selon la documentation de GitHub, il associe un SHA de commit à chaque action, y compris les dépendances transitives, et à chaque workflow réutilisable dont dépendent vos workflows. Il ne s’écrit pas à la main : il est généré par gh actions-lock, une extension de la ligne de commande GitHub.
Le fichier contient deux parties. Une section workflows liste les dépendances de chaque workflow pris en charge. Une section dependencies indique, pour chaque référence, le tag ou la branche utilisés, le commit vers lequel ils ont été résolus, et l’identifiant numérique du dépôt source. Ce dernier point compte : au moment de l’exécution, GitHub vérifie que le dépôt est toujours celui qui a été verrouillé. Un dépôt supprimé puis recréé sous le même nom par un tiers ne passe donc pas.
Une adoption workflow par workflow
Pas besoin de tout basculer d’un coup. Les workflows peuvent être pris en charge un par un ou tous ensemble. Une fois qu’un workflow est intégré, toutes ses dépendances doivent figurer dans le fichier, et c’est le commit enregistré qui s’exécute, même si le tag a été déplacé entre-temps. La documentation précise que, pour les dépôts qui adoptent ce fichier, l’épinglage des SHA dans les workflows n’est plus nécessaire : on peut revenir à des fichiers YAML lisibles.
À lire Camel Caps : Guide Notation Programmation 2026
L’extension permet aussi de vérifier que le fichier est à jour sans rien modifier, ce qui se branche facilement dans une étape de CI. Côté maintenance, Dependabot suit : quand il propose la mise à jour d’une action dans un workflow pris en charge, il régénère l’entrée correspondante du fichier dans la même pull request.
Une règle « Require lockfile » pour les organisations #
Pour les entreprises, GitHub ajoute une règle baptisée Require lockfile, elle aussi en préversion publique. Les administrateurs d’une entreprise, d’une organisation ou d’un dépôt peuvent imposer la présence du fichier de verrouillage sur tous les workflows de leur périmètre. La préversion est ouverte aux offres GitHub Enterprise Cloud (y compris avec résidence des données), Team et Free.
Les limites à connaître
GitHub prend soin de rappeler qu’un verrou ne dit rien de la qualité du code verrouillé : il faut relire les dépendances avant de les figer. Si vous verrouillez un commit déjà malveillant, le fichier le protégera fidèlement. Autre exception notable, la couverture des dépendances transitives ne s’étend pas aux dépendances des appels de workflows réutilisables : un workflow réutilisable relève du fichier de verrouillage du dépôt où il est défini, pas de celui qui l’appelle. Enfin, il s’agit d’une préversion, donc d’une fonction susceptible d’évoluer.
Comment s’y mettre dès maintenant #
La démarche proposée tient en trois étapes : installer l’extension depuis le dépôt public github/gh-actions-lock, générer le fichier pour un premier workflow, puis relire et committer le fichier généré avec les modifications du workflow. Le plus raisonnable est de commencer par les workflows qui manipulent des secrets sensibles, par exemple ceux qui publient un paquet npm, déploient en production ou signent des artefacts.
À lire Horizontal Rule HTML : Guide CSS 2026
Pour un développeur ou une équipe en formation, c’est aussi l’occasion de revoir une notion souvent survolée : la reproductibilité d’un build ne s’arrête pas aux dépendances de l’application. Les outils qui construisent, testent et déploient ce code en font partie, et ils méritent le même niveau de verrouillage que le reste du projet.
