GitHub Actions ajoute un jeton vulnérabilités et le contexte job des workflows réutilisables
Le 3 septembre 2026, GitHub a livré trois mises à jour de GitHub Actions : une permission vulnérabilités pour GITHUB_TOKEN, le contexte job des workflows réutilisables et une API de dépréciation des runners. Remplacez vos portées larges par la permission vulnérabilités et adoptez job.workflow_ref dans vos workflows réutilisables.
3 septembre 2026. GitHub publie trois mises à jour de GitHub Actions qui resserrent le contrôle et la visibilité des pipelines. Depuis 2021. Le GITHUB_TOKEN imposait des compromis de portée pour lire les alertes Dependabot ; la nouvelle permission vulnerability-alerts y met fin. Jusqu’ici. Un workflow réutilisable ne pouvait pas déterminer sa propre identité ; le contexte job le corrige. Pourquoi c’est important : trois changements discrets qui, cumulés, réduisent la surface d’un secret trop large et rendent les workflows réutilisables enfin auditables.
Un jeton vulnérabilités pour lire Dependabot sans tout donner
La nouveauté la plus attendue est sécuritaire. Jusqu’à présent, un workflow qui voulait lire les alertes Dependabot devait s’octroyer une portée large — souvent le périmètre security-events, qui couvre aussi l’écriture dans l’onglet Security, ou pire, des permissions trop généreuses. La nouvelle permission vulnerability-alerts pour le GITHUB_TOKEN ne donne que ce qu’il faut : un accès lecture seule aux alertes Dependabot.
permissions:
contents: read
vulnerability-alerts: readLa permission accepte deux valeurs, read et none. C’est exactement le motif du moindre privilège appliqué au CI/CD : un workflow de tri ou de rapport qui agrège les alertes n’a plus à hériter d’une portée qui pourrait être détournée si le dépôt est compromis. Pour une équipe qui suit le principe « chaque workflow déclare ce qu’il lit », c’est un point de friction en moins — et une raison de plus d’abandonner les permissions implicites ou globales.
Concrètement, un workflow de synthèse hebdomadaire qui liste les alertes Dependabot critiques n’a plus besoin d’aucune autre portée. Il se déclare en deux lignes, puis interroge l’API dédiée :
gh api -H "Accept: application/vnd.github+json" \
"/repos/$OWNER/$REPO/dependabot/alerts?state=open&severity=critical,high" \
--jq '.[] | .security_advisory.cve_id + " " + .security_advisory.summary'La sortie renvoie, pour chaque alerte ouverte, l’identifiant CVE et le résumé — de quoi alimenter un rapport sans jamais exposer un jeton capable d’écrire dans le dépôt ou dans l’onglet Security. C’est la différence de fond entre une portée qui lit et une portée qui peut écrire : la seconde est un levier d’escalade, la première ne l’est pas.
Le contexte job : un workflow réutilisable qui sait d’où il vient
La deuxième nouveauté résout un irritant réel des workflows réutilisables. Le contexte github expose github.workflow_ref et github.workflow_sha, mais ces valeurs décrivent le workflow appelant, pas le workflow qui définit le job en cours d’exécution. Pour un workflow réutilisable, il était donc impossible de savoir, à l’intérieur de son propre code, quelle version de lui-même s’exécutait.
Le contexte job comble ce trou avec quatre propriétés nouvelles :
job.workflow_ref— la référence complète du fichier de workflow qui définit le job courant ;job.workflow_sha— le SHA de commit de ce fichier ;job.workflow_repository— le dépôtowner/repoqui héberge ce fichier ;job.workflow_file_path— le chemin du fichier relatif à la racine du dépôt.
jobs:
audit:
uses: acme/shared-workflows/.github/workflows/audit.yml@mainecho "exécuté depuis ${{ job.workflow_repository }} @ ${{ job.workflow_ref }}"Pour un job défini directement dans un workflow, job.workflow_ref coïncide avec github.workflow_ref ; les deux ne divergent que dans le cas réutilisable. Conséquence pratique : un workflow réutilisable peut désormais journaliser son origine, signer ses artefacts avec sa propre version, ou appliquer des règles de conformité qui dépendent de la branche exacte du workflow partagé. Attention, ces propriétés ne sont pas disponibles sur GitHub Enterprise Server — à vérifier avant d’en faire une dépendance de votre pipeline d’entreprise.
L’usage le plus structurant reste la provenance. Un workflow réutilisable peut désormais émettre une attestation qui enregistre job.workflow_sha et job.workflow_ref à côté de sa sortie, afin qu’un consommateur en aval vérifie quelle version exacte a produit un artefact de build. Pour les équipes qui avancent déjà vers SLSA ou les builds signés, cela referme l’écart entre « un workflow a tourné » et « on peut prouver quel workflow a tourné ».
Une API pour planifier la fin de vie des runners
La troisième mise à jour s’adresse aux responsables d’infrastructure de build. Une nouvelle API REST renvoie les dates de fin de support d’une version de runner : GET /actions/runners/deprecations/{version}, disponible aux niveaux dépôt, organisation et entreprise.
curl -s -H "Authorization: Bearer $GITHUB_TOKEN" \
https://api.github.com/repos/acme/app/actions/runners/deprecations/2.323.0La réponse contient trois champs : runner_version, runtime_deprecates_at et registration_deprecates_at. La distinction entre les deux dates est le point utile — un runner peut cesser d’accepter de nouvelles inscriptions avant de cesser de s’exécuter. Savoir planifier, plutôt que découvrir une version dépréciée au moment où un job échoue, transforme une mise à niveau subie en opération programmée.
L’angle supply chain : d’où vient le workflow qui s’exécute
Les workflows réutilisables ont un défaut structurel peu discuté : quand vous appelez uses: org/repo/.github/workflows/audit.yml@main, le workflow appelé s’exécute avec le GITHUB_TOKEN et les permissions du dépôt appelant. C’est précisément ce qui en fait un vecteur de supply chain : un tag mutable comme @main, s’il est forcé par un push compromis, fait exécuter du code dans tous les dépôts qui le référencent.
Les propriétés job.workflow_ref et job.workflow_sha changent la donne parce qu’elles permettent au workflow réutilisable de s’attester lui-même. Un job peut journaliser la référence exacte qui s’exécute, et une politique de conformité peut comparer job.workflow_sha à une valeur attendue avant de poursuivre. C’est un pas vers le pinning par SHA — la recommandation de fond pour tout workflow réutilisable partagé : référencer un commit précis, jamais une branche.
La leçon vaut pour les deux camps. Pour l’éditeur d’un workflow partagé, journaliser son origine transforme un incident de provenance en enquête traçable. Pour l’utilisateur, exiger une origine vérifiable réduit la surface de confiance accordée à un dépôt tiers.
Ce que ça change pour vos pipelines
Pris ensemble, les trois changements dessinent une même direction : GitHub Actions gagne en granularité sans ajouter de complexité. Le jeton vulnerability-alerts élimine une catégorie de secrets trop larges. Le contexte job supprime l’ambiguïté d’identité qui forçait les équipes à bricoler des variables d’environnement ou à lire github de travers. L’API de dépréciation déplace la gestion des runners d’une posture réactive vers une posture planifiée.
La contrepartie est une dette à rembourser. Les workflows qui lisent aujourd’hui les alertes Dependabot via security-events gagneraient à être rétrécis vers vulnerability-alerts — une revue rapide des permissions de chaque workflow s’impose. Et les équipes qui dépendent de workflows réutilisables partagés devraient tester le contexte job avant de le généraliser, en gardant en tête l’exception Enterprise Server.
Aucun de ces changements n’exige une migration big-bang. Commencez par le gain le plus simple — rétrécir le bloc permissions des workflows qui lisent déjà les alertes Dependabot —, puis ajoutez le contexte job aux un ou deux workflows réutilisables que vous maintenez réellement, et branchez enfin votre supervision sur l’API de dépréciation. Chaque changement est sûr indépendamment, ce qui permet de les adopter dans l’ordre dicté par votre registre des risques.
Verdict
Si vous agrégez les alertes Dependabot dans un workflow, remplacez dès maintenant votre portée large par permissions: vulnerability-alerts: read : c’est un gain de sécurité sans coût, et la première ligne de défense d’un dépôt compromis.
Si vous maintenez des workflows réutilisables, adoptez les propriétés job.workflow_ref et job.workflow_sha pour journaliser l’origine réelle de vos jobs — mais validez d’abord la disponibilité sur votre version de GitHub Enterprise Server si vous en utilisez une.
Si vous gérez des runners auto-hébergés, branchez l’API de dépréciation dans votre supervision et programmez les mises à niveau avant les dates annoncées, plutôt que de les subir au premier job en échec.