GitHub Actions verrouille les dépendances des workflows et borne les secrets pour casser les attaques supply chain

Mars 2025. L’attaque tj-actions repositionne un tag de version vers un commit malveillant : 23 000 dépôts exécutent du code de récolte d’identifiants, et 14 brèches secondaires sont confirmées. 26 mars 2026. GitHub publie sa feuille de route de sécurité pour Actions. Entre les deux, la conclusion est sans appel : le problème n’est pas une erreur de configuration, c’est une faille d’architecture.

Le vecteur de tj-actions est d’une simplicité déconcertante. Quand un workflow écrit uses: actions/checkout@v4, GitHub résout le tag au moment de l’exécution — et v4 peut pointer demain vers un commit différent d’aujourd’hui. L’épinglage par SHA (le hash de 40 caractères) colmate le niveau supérieur, mais pas les dépendances transitives : une composite action appelle elle-même d’autres actions, dont les références restent muables. C’est exactement ce trou que la feuille de route de GitHub entend refermer.

Un vecteur qui se propage à la vitesse d’un tag

Le cas tj-actions n’est pas isolé. Sur la dernière année, des incidents touchant Nx et trivy-action ont suivi le même scénario : une dépendance compromise se propage en amont, les workflows s’exécutent sans observabilité ni contrôle, et des identifiants sur-privilégiés partent via un accès réseau non restreint. La constante n’est pas la sophistication de l’attaque — repositionner un tag est trivial — mais la vitesse de propagation : un seul commit malveillant atteint, en quelques heures, des milliers de dépôts qui ne sauront jamais ce qui s’est exécuté chez eux.

C’est ce constat qui explique la structure de la feuille de route en trois couches : écosystème (dépendances déterministes), surface d’attaque (politiques et secrets scopés), infrastructure (observabilité et pare-feu d’égression). L’objectif n’est pas de rendre l’attaque impossible, mais de faire en sorte qu’elle soit visible et bornée — qu’un compromis de dépendance cesse d’être un compromis de toute la chaîne.

Le lockfile de workflow, le changement central

La pièce maîtresse est un bloc dependencies: dans le YAML du workflow. Comme un go.sum ou un package-lock.json, il enregistre l’arbre complet des dépendances — directes et transitives — avec leur SHA de commit. Le comportement est celui d’un verrou : si un hash ne correspond pas, le job échoue avant d’exécuter le moindre code.

dependencies:
  actions/checkout:
    version: v4.2.2
    sha: 11bd71901bbe5b1630ceea73d27597364c9af683
  actions/setup-node:
    version: v4.1.0
    sha: 39370e3970a6d050c480ffad4ff0ed4d3fdee5af

L’intérêt dépasse la simple sécurité : les mises à jour de dépendances deviennent des diffs de pull request, soumis à la revue de code, au lieu de se propager silencieusement au prochain run. La résolution se fait via la CLI GitHub, qui régénère le lockfile. La fonctionnalité entre en preview au deuxième ou troisième trimestre 2026, pour une disponibilité générale fin d’année.

Les secrets scopés et la fin de l’héritage implicite

Le second chantier attaque le problème des identifiants. Aujourd’hui, les secrets Actions sont scopés au niveau du dépôt ou de l’organisation, et ils se propagent largement par défaut — en particulier à travers les reusable workflows. Le modèle à venir, les secrets scopés, lie chaque identifiant à un contexte d’exécution explicite : un dépôt, une branche, un environnement, une identité de workflow, ou un reusable workflow de confiance.

Une rupture structurelle accompagne ce changement : l’accès en écriture à un dépôt ne conférera plus la gestion des secrets. Cette permission bascule vers un rôle dédié. C’est le passage au moindre privilège par défaut : un secret n’est délivré que si le workflow et le contexte d’exécution sont tous deux explicitement approuvés.

Les politiques d’exécution et le pare-feu d’égression

Deux briques complètent le dispositif. Les politiques d’exécution portent le cadre de rulesets de GitHub sur les déclencheurs de workflow : qui peut lancer un workflow, et quels événements sont autorisés — par exemple restreindre workflow_dispatch aux mainteneurs, ou interdire pull_request_target pour les contributions externes. Un mode évaluation permet de voir ce qui aurait été bloqué avant d’activer l’application.

Le pare-feu d’égression natif, le plus ambitieux et le plus lointain (preview fin 2026, disponibilité générale 2027), opère en couche 7, hors de la VM du runner. Il reste donc efficace même si un attaquant obtient le root à l’intérieur du runner. Deux modes : monitor, qui audite tout le trafic sortant corrélé au workflow, au job et à l’étape, puis enforce, qui bloque tout ce qui n’est pas sur la liste d’autorisation.

La télémétrie qui manquait : Actions Data Stream

À côté du pare-feu, GitHub prépare Actions Data Stream, un flux de télémétrie qui expose les signaux d’exécution des runners — process, système de fichiers, comportement réseau — en quasi temps réel. Aujourd’hui, un workflow compromis tourne dans une boîte noire ; demain, la plateforme promet de rendre visible ce qui s’y passe, et de corréler l’activité au workflow, au job et à l’étape qui l’ont déclenchée.

C’est le pendant indispensable du reste du dispositif : un pare-feu sans visibilité ne fait que bloquer à l’aveugle, et un lockfile sans télémétrie ne détecte pas ce qui a déjà été compromis avant le verrouillage. Pour les équipes qui gèrent des runners auto-hébergés, la télémétrie est aussi le seul moyen de savoir ce qu’un runner, par nature jetable, a réellement exécuté.

Ce qu’il faut faire dès maintenant

Deux mesures sont déjà disponibles, et ce sont elles qui comptent aujourd’hui.

Épinglez vos actions par SHA. Cela ne règle pas les dépendances transitives, mais ferme le vecteur « tag repositionné ». Un audit tient en une commande :

grep -rn 'uses:' .github/workflows/ | grep -v '@[a-f0-9]\{40\}'

Toute ligne remontée est une exposition potentielle : remplacez actions/checkout@v4 par le hash de commit complet, en gardant le tag en commentaire pour la lisibilité.

Basculez sur l’OIDC avec les custom property claims. Disponible en GA depuis avril 2026, l’OIDC émet des jetons courts et scopés, au lieu de stocker des identifiants longue durée comme AWS_ACCESS_KEY_ID dans les secrets du dépôt. Les custom property claims permettent de définir des politiques IAM cloud fondées sur les métadonnées de l’organisation — un dépôt ajouté à l’équipe backend hérite automatiquement du bon rôle, sans toucher au YAML.

Le calendrier compte : la plupart des briques entrent en preview ce trimestre et en disponibilité générale d’ici la fin d’année. Attendre la GA pour s’y intéresser, c’est découvrir d’un coup un changement de modèle de confiance en production. Commencer maintenant — en épinglant par SHA et en cartographiant les déclencheurs — transforme une migration subie en migration préparée. La chaîne d’approvisionnement n’est aussi solide que son tag le plus lâche, et la plupart des pipelines reposent encore sur des tags lâches.

Verdict

Si vous maintenez des workflows GitHub Actions, épinglez vos actions par SHA et basculez vos identifiants cloud vers l’OIDC dès cette semaine — ce sont les deux leviers immédiats et gratuits. Si vous gérez une organisation, préparez la bascule vers les secrets scopés et les politiques d’exécution en commençant par cartographier qui peut déclencher quoi : le mode évaluation des règles vous y aidera sans rien casser. Le lockfile de dépendances, lui, arrivera avec la preview et représentera la vraie rupture — mais d’ici là, l’épinglage par SHA est le filet qui vous sépare du prochain tj-actions.

Références

• What’s coming to our GitHub Actions 2026 security roadmap — GitHub Blog, 26 mars 2026
• GitHub Actions 2026 Security Roadmap: Workflow Lockfiles, Scoped Secrets, and Egress Firewall — ByteIota
• GitHub Actions supply chain attack (tj-actions) — Palo Alto Networks Unit 42
• Actions OIDC tokens now support repository custom properties — GitHub Changelog, 12 mars 2026