Un audit de sécurité mené sur l’infrastructure de déploiement continu d’un projet WordPress d’envergure, un site multirégional avec un pipeline GitHub Actions gérant les déploiements vers trois environnements (recette, préproduction, production), a mis en évidence un problème classique mais rarement corrigé : les secrets GitHub Actions du dépôt contenaient un Personal Access Token (PAT) classique, généré des années plus tôt par un développeur qui avait depuis quitté l’entreprise, donnant accès en lecture et écriture à l’ensemble des dépôts de son compte GitHub personnel, pas seulement à celui du projet audité.
Cette checklist détaille la méthode utilisée pour auditer ce type de token, comprendre pourquoi son périmètre était disproportionné, et le remplacer par des alternatives à portée strictement limitée, désormais disponibles nativement dans GitHub Actions et dans l’écosystème des tokens à portée fine.
1. Recenser tous les tokens utilisés par le pipeline
La première étape consiste à lister exhaustivement, sur chaque dépôt du projet, les secrets déclarés dans les paramètres GitHub Actions (Settings → Secrets and variables → Actions), puis à identifier, dans les fichiers de workflow YAML, lesquels sont effectivement utilisés et pour quelle action précise :
grep -rn "secrets\." .github/workflows/Sur ce projet, l’inventaire a révélé trois usages distincts d’un même secret nommé GH_PAT : le déclenchement d’un workflow dans un dépôt tiers privé contenant des thèmes partagés, la création automatique de tags de version, et la publication de commentaires automatiques sur les pull requests. Trois usages qui n’exigeaient pas nécessairement le même niveau de privilège.
2. Vérifier le périmètre réel du token en place
Un Personal Access Token classique (préfixé ghp_) se rattache au compte personnel de son créateur et hérite, par défaut, de l’ensemble de ses accès : tous les dépôts publics et privés visibles par ce compte, y compris des dépôts personnels sans rapport avec le projet professionnel. La vérification du périmètre réel se fait directement via l’API GitHub :
curl -H "Authorization: token ghp_xxx" https://api.github.com/user/repos \
--silent | jq -r '.[].full_name'Sur ce projet, cette commande a renvoyé vingt-trois dépôts accessibles avec le token en place, dont dix-neuf sans aucun rapport avec le projet audité. Un attaquant qui aurait intercepté ce secret, par exemple via une fuite de journal de build mal filtré, aurait donc pu accéder ou écrire sur l’ensemble de ces dépôts, bien au-delà de ce que la CI nécessitait.
3. Privilégier le GITHUB_TOKEN natif quand c’est possible
Pour deux des trois usages identifiés, création de tags de version et publication de commentaires sur les pull requests, le token personnel n’était en réalité pas nécessaire : GitHub Actions fournit automatiquement, à chaque exécution de workflow, un jeton temporaire nommé GITHUB_TOKEN, dont le périmètre se limite strictement au dépôt courant et dont la durée de vie n’excède pas celle du job en cours d’exécution :
permissions:
contents: write
pull-requests: write
jobs:
tag-version:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Créer le tag
run: |
git tag "v${{ github.run_number }}"
git push origin "v${{ github.run_number }}"
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}Le bloc permissions déclaré en tête de workflow restreint explicitement ce que ce GITHUB_TOKEN peut faire, y compris pour ce job précis : sans la ligne contents: write, même ce jeton natif n’aurait pas suffi à pousser le tag. Depuis 2023, GitHub recommande de déclarer ce bloc de permissions explicitement plutôt que de dépendre du réglage par défaut du dépôt, qui accorde souvent des droits en écriture plus larges que nécessaire.
4. Créer un token à portée fine pour l’accès inter-dépôts
Le troisième usage, déclencher un workflow dans un dépôt privé distinct contenant des thèmes partagés, ne pouvait pas se résoudre avec GITHUB_TOKEN, dont le périmètre reste cantonné au dépôt courant. Pour ce cas, GitHub propose depuis 2022 les fine-grained personal access tokens (préfixés github_pat_), qui permettent de restreindre l’accès à une liste explicite de dépôts et à un ensemble précis de permissions, plutôt qu’à la totalité du compte :
- Sélectionner uniquement le ou les dépôts concernés, jamais « tous les dépôts ».
- N’accorder que les permissions strictement nécessaires :
Actions: Read and writepour déclencher un workflow, sans toucher aux autres catégories (Issues, Administration, Secrets). - Fixer une date d’expiration courte, un an au maximum, plutôt que « pas d’expiration ».
Ce token à portée fine, rattaché idéalement à un compte de service dédié plutôt qu’au compte personnel d’un développeur, remplace avantageusement le GH_PAT initial : en cas de fuite, l’exposition se limite au seul dépôt de thèmes partagés, avec les seules permissions d’actions accordées.
5. Documenter et planifier la rotation
Le dernier point de la checklist consiste à consigner, pour chaque token créé, sa raison d’être, son périmètre exact et sa date d’expiration, dans un registre accessible à l’équipe plutôt que dans la mémoire du développeur qui l’a créé :
| Token | Portée | Expiration | Usage |
|---|---|---|---|
GITHUB_TOKEN | Dépôt courant, durée du job | Automatique | Tags, commentaires PR |
github_pat_theme_partage | 1 dépôt, Actions R/W | 12 mois | Déclenchement CI inter-dépôts |
Un token qui donne accès à tout un compte pour une tâche qui ne concerne qu’un seul dépôt n’est pas une facilité, c’est une dette de sécurité qui attend simplement sa fuite.
Ce qu’il faut retenir
Le remplacement du Personal Access Token classique par une combinaison de GITHUB_TOKEN natif et de tokens à portée fine a réduit l’exposition de vingt-trois dépôts accessibles à un seul, avec des permissions explicitement listées plutôt qu’héritées d’un compte personnel. Cet audit se reproduit facilement sur tout projet utilisant GitHub Actions, et mérite d’être renouvelé chaque fois qu’un développeur ayant créé des tokens personnels quitte le projet, moment où ces tokens deviennent orphelins sans que personne ne pense nécessairement à les révoquer.
