9 min de lecture - Fichiers de verrouillage GitHub Actions : approuvez le commit qui sera exécuté

Le 14 octobre 2026, GitHub a lancé la préversion publique des fichiers de verrouillage des dépendances de workflows. Une équipe peut conserver une référence lisible comme actions/checkout@v6 dans son workflow, tandis que .github/workflows/actions.lock enregistre le commit précis que GitHub Actions exécutera.

Ce mécanisme évite aux personnes qui relisent le code de choisir entre un tag de version compréhensible et une empreinte opaque sur chaque ligne uses:. Il crée aussi une responsabilité : le diff du fichier de verrouillage détermine désormais quel code externe s'exécute dans une tâche de build, de test ou de déploiement.

GitHub l'indique dans son annonce du 14 octobre : le verrouillage protège un workflow contre le déplacement inattendu d'un tag ou d'une branche, mais il ne détermine pas si la dépendance verrouillée est sûre. Pour une startup ou une ETI, la politique raisonnable tient en une phrase : aucun changement du fichier de verrouillage ne doit être fusionné comme un simple bruit généré. Examinez ensemble la référence demandée, le commit résolu et les pouvoirs de la tâche.

Ce que change la préversion

Sans fichier de verrouillage, Actions résout un tag ou une branche au démarrage de la tâche. Un même commit de workflow peut donc exécuter un code amont différent à deux dates si sa référence a été déplacée. La documentation GitHub sur le verrouillage précise qu'un workflow intégré au dispositif exécute au contraire le commit enregistré dans le fichier. Chaque dépendance utilisée par ce workflow doit disposer d'une entrée.

Le fichier ne contient pas qu'une empreinte. Sa section workflows relie chaque workflow intégré à ses dépendances ; la section dependencies stocke la référence demandée, le commit résolu, l'identifiant du propriétaire et celui du dépôt. Ces identifiants numériques permettent au runner de détecter un renommage, un transfert ou une substitution du dépôt au lieu de faire confiance à son seul nom affiché.

GitHub résout également les dépendances qu'une action utilise elle-même. Les appels à des workflows réutilisables suivent une autre règle : leurs dépendances internes relèvent du fichier de verrouillage du dépôt qui définit le workflow réutilisable. Une équipe plateforme qui centralise les livraisons doit donc examiner le fichier de l'application et celui du dépôt partagé. Un contrôle vert dans le dépôt appelant ne décrit pas toute la chaîne d'exécution.

La préversion concerne les offres Free, Team et GitHub Enterprise Cloud. Le dépôt gh-actions-lock exclut GitHub Enterprise Server et prévient que le format, les options et le comportement peuvent changer avant la version 1.0. Prévoyez les mises à jour et un retour arrière.

Séparez l'intention de l'exécution

Un fichier de verrouillage offre deux vues utiles d'une même dépendance. Le workflow exprime l'intention humaine, par exemple « utiliser la version majeure 6 ». Le fichier indique l'identité d'exécution, c'est-à-dire le commit qui sera lancé maintenant.

Aucun de ces faits ne suffit à établir la confiance. L'approbation doit aussi expliquer pourquoi ce dépôt, cette référence et ce commit sont acceptables dans ce workflow, avec ces permissions.

Les recommandations indépendantes d' OpenSSF Scorecard préconisent un verrouillage par empreinte, car un tag de version peut être renommé, ainsi qu'un outil de mise à jour afin que les dépendances verrouillées ne vieillissent pas sans suivi. Le fichier de GitHub fournit l'empreinte à l'exécution tout en gardant la référence de version dans le YAML. Il ne remplace pas la seconde partie du conseil : les mises à jour doivent toujours arriver, être examinées et parcourir la chaîne de validation.

Faites du diff généré un contrôle de livraison

« Généré par une machine » ne signifie pas « faible risque ». Les fichiers de verrouillage des gestionnaires de paquets l'ont déjà montré, mais les workflows méritent encore plus d'attention : une action peut recevoir le jeton du dépôt, des secrets, une identité OIDC, des identifiants de déploiement ou un droit d'écriture sur les artefacts.

Attribuez une propriété de code à .github/workflows/** et à .github/workflows/actions.lock. Exigez les mêmes personnes pour examiner une référence de workflow et le commit verrouillé correspondant. Si le fichier change sans mise à jour déclarée du workflow, arrêtez la fusion et identifiez pourquoi le résolveur a produit une nouvelle valeur.

Ouvrez la comparaison entre l'ancien et le nouveau commit. Lisez les métadonnées de l'action, son JavaScript embarqué ou sa définition de conteneur, puis recherchez les nouveaux appels réseau, binaires téléchargés et besoins en permissions.

Les exigences source de SLSA distinguent les révisions immuables, les changements lisibles et la continuité des contrôles. Elles ne certifient pas cette préversion, mais fournissent un bon test : identifiez l'entrée, lisez son diff et maintenez le contrôle après le pilote.

Commencez par le workflow qui a le plus de pouvoirs

GitHub permet d'intégrer les workflows un par un. Choisissez le premier candidat selon ses pouvoirs, pas selon sa simplicité : un déploiement en production expose les questions auxquelles la politique doit répondre.

Inventoriez chaque référence uses:, y compris les workflows réutilisables et les actions composites. Notez le déclencheur, les permissions, les secrets, la configuration OIDC et la destination des sorties. Générez ensuite le fichier sur une branche qui ne peut pas déployer.

Effectuez quatre contrôles avant d'imposer le fichier au niveau du dépôt ou de l'organisation :

1. Vérifiez qu'une exécution normale utilise les commits enregistrés et produit encore l'artefact ou le résultat de test attendu.
2. Modifiez une dépendance du workflow sans actualiser le fichier, puis confirmez que le contrôle de vérification échoue.
3. Générez une mise à jour légitime, examinez les deux diffs et vérifiez que l'ancien commit reste disponible pour un retour arrière.
4. Testez la procédure de réponse à une compromission amont sans identifiants de production.

Conservez le commit du workflow, les commits verrouillés, la version de la CLI, l'exécution de test et la personne ayant approuvé.

Ne laissez pas le verrouillage devenir de la négligence

Les commits verrouillés empêchent un déplacement silencieux ; ils bloquent aussi les évolutions utiles. Le contrôle Pinned-Dependencies d'OpenSSF prévient que des dépendances figées peuvent manquer des correctifs de sécurité. Il recommande des notifications automatiques et des mises à jour rapides.

GitHub indique que les mises à jour de version Dependabot régénèrent désormais l'entrée correspondante lorsqu'elles modifient la référence d'une action dans un workflow intégré. Gardez les deux modifications dans la même pull request. Celle-ci doit présenter la version demandée, le nouveau commit et les tests exécutés sur cette révision.

La CLI distingue les déplacements habituels des exceptions. Une exécution normale conserve les commits existants. --relock résout de nouveau les références lorsqu'un projet amont a évolué légitimement, alors que --accept-moved peut accepter un déplacement suspect qui resterait sinon en erreur. Réservez cette dernière option à un incident ou à une procédure de récupération documentée. Une commande destinée à outrepasser une alerte ne doit jamais devenir la recette standard de mise à jour.

Fixez un délai adapté aux pouvoirs du workflow, sans inventer une durée universelle. Nommez la personne responsable, l'événement qui déclenche la revue et celle qui peut approuver un changement d'urgence.

Associez le verrouillage aux autres frontières du workflow

Les fichiers de verrouillage traitent l'identité des dépendances. Ils ne réduisent pas les permissions du GITHUB_TOKEN, ne suppriment pas les secrets, n'isolent pas les pull requests non fiables, ne vérifient pas les artefacts téléchargés et n'empêchent pas une action examinée de mal se comporter. Étudiez ces contrôles en même temps que le fichier au lieu d'affirmer que la chaîne CI est désormais sûre.

Une action verrouillée peut toujours restaurer des octets écrits par un autre workflow. Notre guide sur les frontières du cache GitHub Actions explique comment relier les producteurs, les consommateurs et les pouvoirs de livraison avant d'accorder un droit d'écriture.

Pour une petite équipe, une règle CODEOWNERS, une vérification requise et un court modèle de pull request peuvent suffire. Demandez quel commit sera exécuté, quel test a réussi et comment revenir en arrière.

Quand le pilote est stable, activez la politique « Require lockfile » en préversion au niveau utile le plus restreint, puis avancez workflow par workflow. Un basculement global avant d'attribuer les workflows partagés, les exceptions et les commandes de récupération peut remplacer une défaillance silencieuse par une série visible de builds bloqués.

Les services de conseil et de Custom Engineering d'Exceev peuvent aider une équipe à cartographier les frontières de confiance de sa CI et à préparer une adoption progressive. Le propriétaire du dépôt reste responsable de l'approbation des dépendances, des règles d'accès et des décisions d'incident.

Sources et limites

Nous avons ouvert et examiné toutes les sources ci-dessous le 15 octobre 2026.

• L'annonce GitHub du 14 octobre établit la préversion publique, les offres concernées, la politique de verrouillage, l'intégration progressive et la prise en charge par Dependabot. Elle précise aussi que le verrouillage n'évalue pas la sûreté d'une dépendance.
• La documentation GitHub sur le verrouillage définit la résolution à l'exécution, l'identité du dépôt enregistrée, la couverture transitive et la limite liée aux workflows réutilisables.
• Le dépôt gh-actions-lock documente la vérification par la CLI, la nouvelle résolution, le traitement des références déplacées, les limites actuelles et l'avertissement antérieur à la version 1.0.
• Le conseil d'OpenSSF Scorecard sur le verrouillage recommande les empreintes et un outil de mise à jour ; son contrôle Pinned-Dependencies explique le risque créé par des commits figés trop longtemps.
• Les exigences source de SLSA fournissent des définitions indépendantes pour les révisions immuables, les changements lisibles et les contrôles techniques continus.

GitHub constitue la source primaire concernant sa préversion. OpenSSF et SLSA ne certifient ni l'implémentation de GitHub ni la méthode de revue proposée par Exceev. Nous n'avons pas testé la préversion dans un dépôt de production, examiné les actions d'un client ou mesuré l'effort de migration. Le format, les plateformes prises en charge et le comportement de la politique peuvent changer pendant la préversion ; vérifiez la documentation en vigueur avant de l'imposer.