GitHub Actions gèle les actions tierces sur des commits vérifiés
Le 14 octobre 2026, GitHub a ouvert en aperçu public les lockfiles de workflow : chaque action et workflow réutilisable est épinglé sur un commit précis, de sorte que le code relu est le code exécuté. Activez le verrouillage sur vos dépôts critiques avant qu’un tag déplacé n’introduise du code malveillant dans votre CI.
14 octobre 2026. GitHub ouvre en aperçu public les lockfiles de workflow pour GitHub Actions. Mars 2025. L’attaque tj-actions/changed-files déplace un tag vers un commit piégé et siphonne les secrets CI de milliers de dépôts. 14 octobre 2026, toujours. La fonctionnalité couvre GitHub Enterprise Cloud, Team et Free. Pourquoi c’est important : un workflow qui référence actions/checkout@v4 n’exécute pas un numéro de version, mais tout ce qui se trouve derrière un pointeur mutable — et ce pointeur, presque personne ne le surveille.
Le trou : un tag qui bouge après la revue
Le modèle de sécurité implicite de GitHub Actions repose sur une hypothèse fragile. Quand vous écrivez uses: some-org/action@v1, vous faites confiance à un tag ou à une branche. Or un tag n’est pas un artefact : c’est une étiquette que son propriétaire peut déplacer à tout moment, sans que votre dépôt n’en soit averti. La revue de code que vous avez faite sur le commit de la version v1.2.0 ne protège rien si, la nuit suivante, le mainteneur — ou un attaquant qui a pris la main sur son compte — réassigne v1 à un commit contenant un stealer de secrets.
C’est exactement le scénario de l’incident tj-actions/changed-files de mars 2025. L’action, utilisée par des dizaines de milliers de dépôts, a vu ses tags redirigés vers un commit malveillant qui exfiltrait les jetons CI et les secrets d’environnement. La leçon n’était pas qu’une action avait un bug : c’est que la confiance par tag est structurellement contournable, et que le correctif manuel — épingler chaque action sur un SHA de commit — est fastidieux, illisible et vite abandonné. GitHub résume le problème dans son annonce : un tag ou une branche peut bouger après votre revue, « si bien qu’une exécution ultérieure peut lancer un code différent ».
Le cas tj-actions n’est pas isolé. En décembre 2024, le dépôt ultralytics/actions a subi le même détournement : un jeton PyPI compromis a servi à publier une version piégée de l’action, et les tags ont été réassignés en conséquence. À chaque épisode, la recommandation officielle était la même — épingler sur des SHA — et, à chaque épisode, la majorité des dépôts ne l’a pas appliquée. Le problème n’est pas le manque de conseils, c’est l’absence d’un outil qui rende l’épinglage soutenable dans le temps. C’est précisément ce que le lockfile apporte.
La réponse : un lockfile qui fige les commits
Le lockfile de workflow applique à la CI la logique des gestionnaires de paquets. Là où package-lock.json et Cargo.lock figent les dépendances d’une application, le nouveau fichier .github/workflows/actions.lock fige les dépendances d’un workflow. Chaque action, ses dépendances transitives et les workflows réutilisables y sont enregistrés avec leur commit exact. Le workflow conserve sa référence lisible (@v4), mais GitHub Actions exécute le commit verrouillé — pas le tag, pas la branche.
La génération passe par une extension CLI dédiée, gh actions-lock, à installer depuis le dépôt public gh-actions-lock. Son fonctionnement suit trois temps :
- Épingler. L’extension génère le fichier
actions.lockavec des commits vérifiables pour chaque action, ses dépendances transitives et les workflows réutilisables. - Adopter progressivement. L’onboarding se fait workflow par workflow. Une fois un workflow embarqué, chacune de ses dépendances doit avoir une entrée dans le lockfile, et GitHub Actions exécute le commit enregistré.
- Vérifier l’obsolescence. Une commande permet de contrôler que le lockfile est à jour sans modifier de fichier — idéal dans une étape de CI qui refuse de fusionner un workflow désynchronisé.
L’adoption progressive est le point fort du mécanisme. Une équipe peut verrouiller aujourd’hui son workflow de déploiement, puis étendre la couverture aux autres sans jamais casser le reste du parc. Aucune migration « tout ou rien » : le lockfile s’installe dépôt par dépôt, workflow par workflow.
Imposer le verrouillage à l’échelle
Une fonctionnalité opt-in ne protège que ceux qui l’activent. GitHub l’a compris et livre, dans le même aperçu, la politique Require lockfile. Les administrateurs d’enterprise, d’organisation ou de dépôt peuvent exiger que les workflows utilisent un lockfile — et bloquer la fusion de toute pull request qui l’omettrait. C’est la bascule qui transforme une bonne pratique individuelle en politique de gouvernance.
La boucle se ferme avec Dependabot. Quand le robot ouvre une mise à jour de version pour une action d’un workflow déjà verrouillé, il régénère l’entrée de lockfile dans la même pull request. Le workflow mis à jour et son commit verrouillé restent synchronisés sans configuration supplémentaire. Sans cette intégration, le lockfile deviendrait un cimetière de commits obsolètes que personne n’ose toucher ; avec elle, la mise à jour reste un geste unique et revu.
Ce verrouillage rejoint une série de durcissements de la supply chain de la plateforme : détection des secrets par modèle dédié, blocage par défaut des clés Anthropic, scan des pull requests. Le lockfile n’est pas un gadget isolé, c’est la pièce qui manquait au chaînon « qui exécute quoi » de la CI.
Mise en place en trois commandes
Le flux de base tient en quelques lignes : on installe l’extension, on génère le lockfile, puis on embarque le tout dans le dépôt.
gh extension install github/gh-actions-lock
gh actions-lock generate
git add .github/workflows/actions.lockUne fois le fichier généré, chaque dépendance du workflow est figée sur son commit. Pour détecter un lockfile qui a pris du retard — typiquement dans une étape de CI qui refuse la fusion — la même extension fournit un mode vérification :
- name: Vérifier le lockfile
run: gh actions-lock checkCe contrôle est la pièce que l’on oublie le plus souvent. Un lockfile non surveillé se transforme en cadenas posé sur une porte déjà ouverte : il donne l’illusion de la sécurité sans empêcher un tag de dériver silencieusement.
Ce que le lockfile ne fait pas
Il faut borner la promesse, et GitHub le fait lui-même : « le verrouillage ne détermine pas si la dépendance est elle-même sûre ». Le lockfile garantit l’immuabilité — vous exécutez le code que vous avez relu —, pas l’innocuité. Si vous verrouillez une action déjà compromise, vous figez le mal en place. La revue des dépendances reste donc un préalable : on relit une action avant de la verrouiller, pas après.
La seconde limite est opérationnelle. Un lockfile ajoute une étape de maintenance à chaque montée de version d’action. Sans Dependabot ni contrôle d’obsolescence en CI, les équipes finissent par figer des commits anciens qui accumulent les failles — le problème symétrique du premier. Le verrouillage n’a de valeur que s’il est couplé à un processus de mise à jour régulier.
Verdict
Si vos dépôts utilisent des actions tierces sur des workflows sensibles — déploiement, publication, accès à des secrets — installez gh actions-lock dès cette semaine et verrouillez ces workflows en premier. Si vous administrez une organisation, activez la politique Require lockfile sur les dépôts critiques et laissez Dependabot maintenir les entrées à jour. Si votre parc tourne déjà avec des actions épinglées sur des SHA, migrez-les vers le lockfile : vous gagnez la lisibilité des tags et l’immuabilité des commits, sans le coût manuel. Le lockfile ne remplace pas la revue des dépendances ; il garantit seulement qu’après la revue, rien ne bouge. Dans une CI où un tag déplacé peut vider un coffre de secrets en une nuit, cette garantie-là vaut largement l’étape de maintenance qu’elle ajoute.