Le 14 octobre 2026, GitHub a publié en preview publique un mécanisme qui manquait cruellement à Actions depuis ses débuts : un vrai lockfile. Jusqu’ici, épingler une action sur un SHA de commit restait une discipline manuelle, facile à oublier sur une dépendance transitive planquée dans une action composite. Les actions.lock changent la donne : ils figent tout le graphe de dépendances d’un workflow, pas seulement ce que tu écris toi-même dans le YAML.
Si tu as lu notre article sur les immutable actions et la fermeture de la faille tj-actions, tu sais déjà que GitHub avance par étapes sur la sécurité de la chaîne d’approvisionnement Actions. Les lockfiles sont la pièce suivante : là où les immutable actions sécurisent la distribution côté mainteneur, les lockfiles verrouillent la consommation côté utilisateur.
Le problème que le SHA-pinning seul ne couvre pas
Épingler actions/checkout@a1b2c3d... plutôt que actions/checkout@v4 protège contre une réécriture de tag. Mais une action composite peut elle-même appeler d’autres actions en interne, sans que tu le voies dans ton propre workflow. Si cette dépendance de second niveau n’est pas épinglée par son mainteneur, ton pinning de surface ne sert à rien : le code qui s’exécute réellement peut changer sous tes pieds.
C’est exactement le schéma de l’attaque tj-actions de mars 2025, qu’on a détaillée dans notre article sur les leçons supply chain : environ 23 000 dépôts touchés par une seule action compromise, propagée via des dépendances en cascade. Le pinning manuel ne scale juste pas sur un graphe de dépendances profond.
Ce qu’un lockfile GitHub Actions verrouille concrètement
Le fichier généré s’appelle .github/workflows/actions.lock, en schéma v0.0.2 (encore amené à évoluer, le projet est pré-1.0). Il contient deux sections : workflows, qui associe chaque fichier de workflow aux actions et reusable workflows qu’il référence, et dependencies, qui enregistre pour chaque référence le tag (ref), le SHA de commit résolu, et les identifiants numériques owner_id/repo_id — utiles pour détecter un renommage ou une redirection de dépôt, un vecteur d’attaque réel.
Trois niveaux sont couverts, et c’est là que ça dépasse le simple pinning :
- Actions directes : tag et SHA résolu enregistrés côte à côte.
- Actions transitives : pour une action composite, tout le graphe de dépendances imbriqué est verrouillé dans le lockfile de ton propre dépôt.
- Reusable workflows : ton lockfile épingle le commit du fichier de workflow réutilisable appelé, mais les dépendances internes de ce workflow réutilisable restent gouvernées par le lockfile du dépôt qui le définit — raison de plus pour onboarder en priorité les dépôts qui hébergent des workflows partagés.
À l’exécution, Actions lance le commit verrouillé, point final — peu importe où pointe le tag amont au moment du run. Les politiques « allowed actions » sont évaluées contre ce commit verrouillé, pas contre le tag.
Générer et vérifier le lockfile
L’outillage passe par une extension GitHub CLI :
gh extension install github/gh-actions-lock
gh actions-lockLancée depuis la racine du dépôt, cette commande scanne .github/workflows/ et écrit le lockfile. Un scan complet du dossier retire aussi les entrées des workflows supprimés ; tu peux aussi cibler un workflow précis pour ne toucher que celui-là.
Deux modes de vérification, pour deux contextes différents :
gh actions-lock --verifycontrôle que le lockfile est à jour sans rien modifier — pensé pour un job de CI sur une pull request.gh actions-lock --verify-local --no-fixtourne hors ligne, pour un hook pre-commit. Il ne vérifie que la complétude structurelle, pas la validité des pins côté GitHub.
Dependabot s’intègre à la mécanique : quand il bump une action déjà onboardée, il régénère l’entrée correspondante dans la même pull request. Il ne crée en revanche pas d’entrée pour un workflow qui n’a encore aucune couverture — l’onboarding initial reste à faire manuellement.
La politique « Require lockfile » côté administration
Pour les organisations qui veulent imposer la pratique plutôt que la suggérer, une politique « Require lockfile » existe en parallèle, elle aussi en preview publique, réglable au niveau entreprise, organisation ou dépôt. Deux modes : Evaluate, disponible uniquement sur GitHub Enterprise, qui remonte dans Policy insights ce qui serait bloqué sans réellement bloquer — et Active, qui bloque pour de vrai l’exécution des workflows ciblés dès qu’une dépendance d’action n’est pas couverte par le lockfile du dépôt.
La documentation officielle recommande un déploiement en quatre étapes plutôt qu’un passage en force : pilote sur quelques dépôts, automatisation de la maintenance des lockfiles, renforcement de la revue de code via CODEOWNERS sur actions.lock, puis activation large. Vu le nombre de dépôts qui n’ont encore aucun lockfile, basculer direct en mode Active sans ce palier casserait des pipelines pour de mauvaises raisons.
Ce que ça ne règle pas
Un lockfile fige quelle révision s’exécute, pas si cette révision est saine. Verrouiller une action compromise revient juste à garantir que c’est toujours la version compromise qui tourne — la revue du code tiers reste nécessaire, lockfile ou pas. Et comme l’ensemble CLI/schéma est pré-1.0, les flags et le format peuvent encore changer avant stabilisation. GitHub Enterprise Server n’est pour l’instant pas couvert : seul Enterprise Cloud (y compris avec data residency) a accès à la fonctionnalité.
FAQ
Faut-il abandonner le SHA-pinning manuel si on adopte les lockfiles ?
Non. Les politiques de SHA-pinning existantes peuvent coexister : pour une dépendance verrouillée, l’exigence de SHA est simplement vérifiée contre le commit du lockfile plutôt que contre le tag.
Est-ce que ça marche sur GitHub Enterprise Server ?
Pas pour l’instant. La preview publique du 14 octobre 2026 couvre uniquement GitHub Enterprise Cloud, y compris les configurations avec data residency.
Que se passe-t-il si un mainteneur renomme son dépôt d’action ?
Le lockfile stocke owner_id et repo_id, vérifiés à l’exécution — ce qui permet de détecter un renommage ou une redirection, plutôt qu’un simple suivi par nom qui se ferait avoir silencieusement.
Passer à l’action
Si tu gères plus d’une poignée de workflows avec des actions tierces, installer gh-actions-lock et lancer un premier gh actions-lock en mode diagnostic coûte dix minutes et te donne une photo exacte de ce qui tourne vraiment dans tes pipelines. Garde la politique « Require lockfile » en mode Evaluate le temps d’onboarder tes dépôts les plus critiques — l’activer trop tôt reviendrait à bloquer tes propres builds pour une couverture encore partielle.
Laisser un commentaire