GITHUB_TOKEN gagne une permission de lecture dédiée aux alertes Dependabot

12 août 2026. GitHub publie sa mise à jour « Early August 2026 » pour GitHub Actions, statut Shipped. Au programme, une nouveauté qui passe trop souvent inaperçue : une permission vulnerability-alerts: read sur le GITHUB_TOKEN. Août 2026. La feuille de route sécurité de GitHub Actions promet des défauts plus sûrs et un contrôle plus fin des politiques. La question n’est plus « peut-on durcir le token de CI ? », mais « qui le fait encore sans ? ».

Le vrai sujet tient en une phrase : pendant des années, le jeton automatique de vos workflows ne pouvait tout simplement pas lire les alertes Dependabot, et les équipes contournaient cette limite avec des jetons plus larges qu’il n’en fallait.

Un trou connu, comblé à moitié

Le GITHUB_TOKEN est un jeton d’authentification généré automatiquement pour chaque exécution de workflow. Il est censé être l’outil du moindre privilège : vous déclarez ses permissions dans le bloc permissions du workflow, et il n’en a pas une de plus. C’est l’inverse d’un PAT (personal access token), qui porte l’identité d’un compte humain et toutes ses autorisations.

Sauf qu’il existait une exception gênante. L’API qui liste les alertes Dependabot d’un dépôt — GET /repos/{owner}/{repo}/dependabot/alerts — exigeait une permission que le GITHUB_TOKEN ne pouvait pas recevoir. La discussion communautaire #60612 le résume crûment : le jeton par défaut ne pourra jamais lister ces alertes, parce que l’Actions App qui le frappe ne peut pas être configurée pour porter la permission Dependabot alerts read.

Résultat : toute équipe qui voulait automatiser la remédiation — par exemple fermer une alerte quand le correctif est mergé, ou journaliser les alertes dans un SIEM — devait injecter un PAT dans le workflow. Un secret à longue durée de vie, portant les droits d’un humain, pour lire une liste de vulnérabilités. C’est précisément le genre de compromis que la sécurité de la supply chain reproche aux pipelines CI/CD.

La permission qui débloque le moindre privilège

La mise à jour d’août 2026 corrige ce déséquilibre. Le GITHUB_TOKEN accepte désormais une permission granulaire vulnerability-alerts: read, qui lui donne un accès en lecture aux alertes Dependabot — et rien d’autre.

Concrètement, un workflow qui devait auparavant importer un PAT peut maintenant déclarer :

permissions:
  contents: read
  vulnerability-alerts: read

Puis interroger l’API avec le jeton intégré, sans secret supplémentaire :

# Lister les alertes Dependabot du dépôt courant avec le token de CI
gh api repos/${{ github.repository }}/dependabot/alerts \
  --jq '.[] | {number, severity, state, package: .dependency.package.name}'

L’intérêt n’est pas cosmétique. Un PAT est un secret statique : s’il fuit, il reste valide jusqu’à révocation manuelle, et il ouvre tout ce que le compte qui l’a émis peut ouvrir. Le GITHUB_TOKEN, lui, expire à la fin de l’exécution et ne porte que ce que le bloc permissions déclare. Remplacer un PAT par cette permission, c’est transformer une dette de sécurité permanente en un droit éphémère et borné.

Deux autres livraisons dans la même vague

La mise à jour ne s’arrête pas à cette permission. Deux autres éléments méritent l’attention d’une équipe plateforme.

• Une API REST de dépréciation des runners. Elle permet de consulter les échéances de dépréciation des versions de runners avant qu’elles ne deviennent un problème, au lieu de découvrir la suppression au moment où le pipeline casse. Pour les organisations qui gèrent des centaines de runners, c’est la différence entre planifier une migration et subir une panne.
• Quatre nouvelles propriétés du contexte job. Elles permettent à un workflow réutilisable de connaître sa propre identité d’origine à l’exécution — de quel dépôt, quelle branche, quel workflow appelant il provient. Pour les bibliothèques de workflows partagés, c’est la base d’une automatisation plus « consciente d’elle-même », qui adapte son comportement à son appelant.

Pris ensemble, ces trois changements dessinent une même trajectoire : rendre la CI/CD pilotable par politique et observable, plutôt que par des secrets humains et des scripts ad hoc.

Pourquoi le moindre privilège se joue d’abord sur le token

La menace de fond n’a pas changé depuis des années : une action tierce compromise qui s’exécute dans votre pipeline hérite de tout ce que le token porte. Si votre GITHUB_TOKEN est configuré en write-all, une seule dépendance piégée peut pousser du code, lire vos secrets ou pivoter vers vos environnements de production. C’est le vecteur exact des attaques de supply chain documentées sur GitHub Actions — notamment la compromission d’actions populaires pour exfiltrer des secrets.

Le réflexe à installer est donc simple : dans chaque dépôt, forcer la permission par défaut en lecture seule, et n’élever des droits que dans le bloc permissions des workflows qui en ont besoin. La nouvelle permission vulnerability-alerts: read supprime le dernier alibi qui justifiait un PAT dans une pipeline d’automatisation des alertes.

Le réglage se joue au niveau de l’organisation :

# Vérifier la politique de permissions par défaut de l'organisation
gh api orgs/${{ github.repository_owner }} --jq '.default_repository_permission'

Et au niveau du dépôt, le contrôle s’applique via Settings → Actions → General → Workflow permissions, en cochant « Read repository contents and packages permissions », puis en déclarant les élévations au cas par cas.

Verdict

Si vous automatisez déjà la remédiation Dependabot, remplacez sans attendre le PAT par la permission vulnerability-alerts: read : c’est un gain immédiat de surface d’attaque sans coût fonctionnel. Le geste est mécanique — une ligne dans le bloc permissions et la suppression du secret — mais il retire un secret statique à longue durée de vie d’un pipeline.

Si vous ne lisez pas encore ces alertes par API, le vrai chantier n’est pas la permission, c’est la politique : passez les permissions par défaut en lecture seule, puis traitez chaque write comme une décision à justifier. La permission Dependabot n’est qu’un cran de plus dans une chaîne qui ne tolère plus les tokens tout-puissants.

Références

• GitHub Actions: Early August 2026 Updates [GA] — github/roadmap #1313, 12 août 2026
• What’s coming to our GitHub Actions 2026 security roadmap — GitHub Blog
• Can’t access Dependabot alerts API via GitHub Action default token — GitHub Community #60612
• Use GITHUB_TOKEN for authentication in workflows — GitHub Docs