GitHub Actions en septembre 2026 : les nouveautés sécurité et la feuille de route à connaître

Si tes pipelines GitHub Actions tournent depuis un moment sans que tu aies retouché aux permissions ou à l’épinglage des actions tierces, cet article est pour toi. GitHub a publié début septembre 2026 trois nouveautés qui touchent directement la sécurité et la fiabilité de tes workflows, et elles s’inscrivent dans une feuille de route 2026 bien plus large sur le sujet. Tu vas voir ce qui change concrètement, comment en profiter dès maintenant, et ce qui arrive ensuite pour que tu puisses anticiper plutôt que subir.

Ce qui vient de sortir : les mises à jour de début septembre 2026

Le changelog officiel du 3 septembre 2026 apporte trois changements concrets.

1. Une API pour anticiper la dépréciation des runners

Nouvel endpoint REST : GET /actions/runners/deprecations/{version}, disponible au niveau repository, organisation ou entreprise. Il te renvoie runner_version, runtime_deprecates_at et registration_deprecates_at — de quoi programmer tes montées de version de runners self-hosted au lieu de découvrir la dépréciation le jour où un job casse en production.

curl -H "Authorization: Bearer $GH_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  https://api.github.com/repos/ORG/REPO/actions/runners/deprecations/2.319.1

2. Une permission dédiée aux alertes Dependabot

Le GITHUB_TOKEN gagne une permission vulnerability-alerts (valeurs read ou none), qui donne un accès en lecture seule aux alertes Dependabot depuis un workflow. Ça t’évite de devoir accorder des scopes beaucoup plus larges juste pour qu’un job lise l’état des vulnérabilités connues :

permissions:
  vulnerability-alerts: read
  contents: read

C’est exactement le genre de granularité que recommande la documentation officielle sur l’usage sécurisé de GitHub Actions : donner à chaque job le minimum nécessaire, jamais plus.

3. Quatre nouvelles propriétés de contexte pour les workflows réutilisables

Si tu factorises tes pipelines avec des reusable workflows, le contexte job expose désormais job.workflow_ref, job.workflow_sha, job.workflow_repository et job.workflow_file_path. Ça permet à un workflow réutilisable de savoir précisément d’où il est appelé et sur quelle version — utile pour du logging, de l’audit, ou pour appliquer des règles différentes selon l’appelant. Seule limite à noter : ces propriétés ne sont pas disponibles sur GitHub Enterprise Server.

La feuille de route sécurité 2026 : ce qui arrive ensuite

Ces trois nouveautés s’inscrivent dans une feuille de route sécurité plus large que GitHub a partagée avec la communauté. Voici les chantiers à surveiller, parce qu’ils vont probablement changer tes habitudes de configuration :

• Verrouillage des dépendances au niveau workflow : à terme, les actions tierces devront être épinglées à un SHA de commit précis pour que le workflow s’exécute — la meilleure protection connue contre une action compromise qui pousserait une mise à jour malveillante sur son tag.
• Protections sur le déclenchement des workflows : donner aux administrateurs un contrôle plus fin sur quels acteurs et quels événements peuvent déclencher un workflow, en particulier pour les opérations sensibles (déploiement, publication de packages).
• Secrets mieux scopés : limiter l’accès aux secrets par workflow, par job, voire par step, plutôt que de les exposer à l’ensemble d’un run.
• Flux d’audit immuable (« actions data stream ») : une piste d’audit séparée des logs de run classiques, pensée pour rester exploitable même si un run est compromis et ses logs supprimés, avec une intégration envisagée vers des outils SIEM.
• Pare-feu de sortie natif : blocage par défaut du trafic sortant des runners hébergés par GitHub, avec liste d’autorisation — d’abord sur les runners managés, le support des runners self-hosted étant encore à l’étude.

Rien de tout ça n’est encore généralisé au moment où j’écris ces lignes, mais la direction est claire : GitHub muscle sérieusement la sécurité par défaut de ses pipelines, dans la continuité des attaques de chaîne d’approvisionnement qui ont touché plusieurs actions populaires ces dernières années.

Ce que tu peux faire dès maintenant

Épingler tes actions tierces sans attendre l’obligation

Plutôt que d’attendre que ça devienne obligatoire, remplace dès aujourd’hui tes références de tags (uses: actions/checkout@v4) par des SHA de commit complets :

steps:
  - uses: actions/checkout@8edcb1bdb4e267140fa742c62e395cd74f332d84 # v4.2.2

Ça demande un peu plus de maintenance (Dependabot peut s’en charger automatiquement), mais ça neutralise le scénario où un tag existant est réécrit pour pointer vers du code malveillant.

Auditer tes permissions existantes

Beaucoup de workflows historiques tournent encore avec des permissions par défaut trop larges. Un audit rapide consiste à passer en revue chaque fichier .github/workflows/*.yml et à vérifier qu’un bloc permissions explicite est défini au niveau du workflow ou du job, plutôt que de laisser GitHub appliquer ses valeurs par défaut.

Ne pas négliger les runners self-hosted

Si une partie de tes workflows tourne sur des runners self-hosted plutôt que sur l’infrastructure managée par GitHub, garde en tête que plusieurs des protections à venir (pare-feu de sortie notamment) cibleront d’abord les runners hébergés par GitHub. Sur du self-hosted, la responsabilité du durcissement réseau et système reste largement la tienne — un sujet sur lequel Azure DevOps propose une approche comparable avec ses Managed DevOps Pools, si tu veux comparer les deux écosystèmes.

FAQ

Faut-il déjà épingler toutes ses actions par SHA ?

Ce n’est pas encore obligatoire, mais c’est déjà une bonne pratique recommandée par GitHub, en particulier pour les actions tierces peu maintenues ou à fort accès (secrets, déploiement). Pour les actions officielles GitHub, le risque est plus faible mais le principe reste valable.

La permission vulnerability-alerts remplace-t-elle un scope Dependabot plus large ?

Oui, dans les cas où un workflow n’a besoin que de lire l’état des alertes Dependabot. Avant cette permission dédiée, il fallait souvent accorder des droits plus étendus sur le repository pour arriver au même résultat.

Le pare-feu de sortie va-t-il casser mes workflows actuels ?

Une fois généralisé, oui potentiellement, si tes jobs contactent des services externes non listés dans l’allowlist. C’est justement pour ça qu’il vaut mieux commencer dès maintenant à documenter les destinations réseau utilisées par tes workflows, plutôt que de le découvrir en heurtant un blocage.

En résumé

Les nouveautés de septembre 2026 sont modestes prises isolément, mais elles annoncent une évolution de fond : GitHub Actions va progressivement imposer une hygiène de sécurité qui, aujourd’hui encore, dépend surtout de la discipline de chaque équipe. Autant prendre les devants — épingler tes actions, resserrer tes permissions, documenter tes flux réseau — plutôt que de découvrir ces contraintes le jour où elles deviennent obligatoires.