Le fichier de verrouillage GitHub Actions fixe le code exécuté, mais pas tout le CI

Peut-on faire confiance à GitHub Actions lorsqu’un workflow référence une action par une balise telle que @v3 ? Le fichier de verrouillage précise quel commit de l’action sera exécuté, même si la balise est déplacée par la suite. L’équipe peut examiner les mises à jour de dépendances dans le diff et tenir une liste vérifiable des actions utilisées par le CI. Limite pratique : le fichier couvre les actions appelées par des étapes, tandis qu’un workflow réutilisable appelé au niveau d’un job doit être épinglé séparément. Le mécanisme décrit est disponible dans GitHub Enterprise Cloud.

Que fixe précisément le fichier de verrouillage ?

Les références à des branches et à des balises sont pratiques, mais la version qu’elles désignent peut changer. Une entrée telle que uses: octo-org/deploy-action@v3 pointe vers le nom d’une balise ; GitHub résout cette référence en commit au lancement. Si le propriétaire du projet déplace la balise, une exécution ultérieure sans dépendance épinglée peut récupérer un code différent.

Selon la documentation GitHub sur les fichiers de verrouillage, le fichier .github/workflows/actions.lock stocke les références aux dépendances et les SHA de commit correspondants, y compris les dépendances transitives — les actions utilisées par d’autres actions. Le fichier est créé par l’extension GitHub CLI gh actions-lock ; il ne doit pas être modifié manuellement.

Le générateur peut également préciser les références uses dans les fichiers de workflow : par exemple, rendre plus précise une référence vers une balise flottante en conservant le commit qu’elle résolvait lors de la création du fichier de verrouillage. Lors de la mise en place, il faut donc examiner l’intégralité du diff — les modifications des workflows et du fichier de verrouillage — et vérifier que la version épinglée est bien celle que l’équipe souhaite exécuter.

Une mise à jour de dépendance devient alors une modification visible dans le dépôt : l’équipe peut examiner le changement de commit, en discuter et l’accepter par le processus habituel de revue. Le fichier de verrouillage facilite l’audit du code des actions et la cohérence des dépendances ; à lui seul, il ne garantit pas la sécurité du code sélectionné.

Où s’arrête le périmètre de l’épinglage ?

L’appel d’un workflow réutilisable dans jobs.<job_id>.uses n’est pas épinglé par le fichier de verrouillage du dépôt qui l’appelle. Les dépendances du workflow réutilisable relèvent du dépôt dans lequel ce workflow est défini. Pour épingler l’appel lui-même, indiquez le SHA de commit complet ; pour épingler ses actions dans le dépôt source, il faut un fichier de verrouillage propre à ce dépôt.

Le fichier de verrouillage contrôle le code des actions, mais pas les autres entrées de compilation, comme les paramètres transmis à une action, les secrets ou l’image du runner. Il répond à une question précise : quel commit du code de l’action sera exécuté ? Ces autres éléments nécessitent leurs propres règles de gestion.

Il existe aussi un cas particulier : une action locale appelée par un chemin tel que uses: ./. Selon les instructions de GitHub, l’extension gh actions-lock n’épingle ni n’analyse le chemin d’une action locale. Si cette action utilise d’autres actions, il faut gérer les dépendances séparément ; la documentation décrit une méthode consistant à migrer les références aux actions locales vers le format $/.

Une entrée du fichier de verrouillage peut donc faire partie d’une chaîne sans remplacer le contrôle de tous ses maillons. Pour un workflow réutilisable externe, vérifiez que l’appel est épinglé et examinez l’état du dépôt source ; pour les actions locales, vérifiez précisément comment leurs dépendances sont prises en compte.

Comment mettre en place le contrôle sans interrompre inopinément le CI ?

GitHub recommande de commencer par un projet pilote sur des dépôts et workflows sélectionnés. La politique Require lockfile bloque l’exécution des workflows ciblés sans fichier de verrouillage valide, y compris les workflows sans dépendance uses:. Le mode Evaluate pour les politiques est uniquement disponible dans GitHub Enterprise Cloud. Il faut donc d’abord définir le périmètre et l’automatisation des mises à jour, puis activer la règle obligatoire.

1. Vérifiez les références initiales. Avant de créer le fichier de verrouillage, assurez-vous que les actions pointent vers les versions que l’équipe souhaite réellement épingler. Le générateur fixe le commit résolu à partir de la référence actuelle.
2. Créez et examinez le fichier de verrouillage. Installez l’extension gh-actions-lock, lancez gh actions-lock depuis la racine du dépôt et examinez l’intégralité du diff, y compris les références uses réécrites.
3. Configurez la mise à jour et la vérification. Dependabot peut mettre à jour les entrées correspondantes pour les workflows déjà configurés. Dans le CI des pull requests, vous pouvez configurer une tâche de vérification avec gh actions-lock --verify afin de détecter un fichier de verrouillage obsolète avant la compilation principale.
4. Désignez des responsables de revue. Ajoutez .github/workflows/actions.lock à CODEOWNERS et exigez que les modifications soient examinées par les personnes responsables de la sécurité de la compilation.
5. Testez la politique à petite échelle. Commencez par les dépôts et workflows configurés. En mode Evaluate, analysez les résultats ; avant de passer au mode Active, vérifiez que tous les workflows ciblés sont prêts et que les fichiers de verrouillage sont à jour.

Require lockfile et la politique distincte Require actions to be pinned to a full-length commit SHA sont deux règles différentes ; GitHub précise qu’elles peuvent être appliquées simultanément. La vérification dans le CI et la politique obligatoire remplissent également des fonctions différentes : la première détecte un fichier obsolète pendant le travail sur une pull request, la seconde bloque l’exécution d’un workflow qui ne respecte pas l’exigence.

Exemple : mise à jour d’une action de déploiement

Supposons qu’un workflow publie une application avec octo-org/deploy-action@v3. L’équipe vérifie d’abord quelle version cette référence résout, puis lance gh actions-lock et examine le diff du workflow ainsi que l’entrée du commit dans le fichier de verrouillage. Lors d’une mise à jour de l’action, la personne chargée de la revue voit les modifications des références et du commit épinglé ; elle peut ainsi évaluer précisément la mise à jour, au lieu de supposer qu’une balise mobile pointera toujours vers le même code.

Si le déploiement est exécuté par un workflow réutilisable provenant d’un autre dépôt, le fichier de verrouillage local ne couvre pas ses dépendances. Épinglez la référence du workflow réutilisable avec un SHA complet et vérifiez que le dépôt source gère ses propres dépendances d’actions. Dans les grandes organisations, cette démarche transforme des règles disparates en un processus vérifiable, tout en maintenant un contrôle distinct des paramètres, des secrets et du runner.

Le fichier de verrouillage constitue une couche de contrôle utile pour le code des actions : il rend visibles les versions et les mises à jour, y compris les dépendances transitives. Pour garantir une couverture fiable, vérifiez également les workflows réutilisables et les actions locales, automatisez les mises à jour et ne rendez la politique obligatoire qu’après un projet pilote.