Migrer vers les fine-grained PAT GitHub : 30 minutes, 80% de blast radius en moins

Les incidents Mistral AI (12 mai 2026), TanStack (Shai-Hulud), Mercedes-Benz (octobre 2025) ont un point commun rarement discuté : un token GitHub à scope trop large était dans la boucle. C'est presque toujours le multiplicateur qui transforme une intrusion limitée en exfiltration massive. La bonne nouvelle : la migration vers des tokens fine-grained prend 30 minutes par token. Et c'est la mesure qui a probablement le meilleur ratio temps / réduction de risque en 2026.

Le PAT classique en deux phrases

Un Personal Access Token (PAT) classique GitHub se configure avec des scopes : repo, read:org, workflow, etc. Le scope repo donne accès en lecture-écriture à tous les dépôts privés de l'utilisateur, sans exception. La majorité des intégrations historiques utilisent ce scope, parce que c'était le seul disponible jusqu'en 2022.

Le fine-grained PAT en deux phrases

Le fine-grained PAT, disponible depuis octobre 2022, sorti de bêta en 2024, permet de restreindre l'accès à un ou plusieurs dépôts choisis, avec des permissions granulaires (Contents: read, Pull requests: write, etc.). Un token compromis n'a accès qu'au périmètre exact que vous avez défini.

Le calcul de risque, en chiffres réels

Une PME médiane de 80 employés a typiquement :

• 30-60 dépôts privés actifs.
• 8-15 intégrations CI/CD/déploiement qui utilisent un PAT (Vercel, Netlify, Render, Heroku, Docker Hub, scripts internes, runners self-hosted).
• 3-5 utilisateurs administrateurs avec PAT personnel large.

Avec des PAT classiques repo : un seul token volé = accès à 100% des dépôts privés. Avec des fine-grained correctement scopés : un token Vercel volé = accès aux 2-3 dépôts que Vercel déploie.

L'écart de blast radius est de l'ordre d'un facteur 20-30.

Le plan de migration en 30 minutes par token

1. Lister les PAT existants (5 min)

Settings → Developer settings → Personal access tokens → Tokens (classic). Notez chaque token, sa description, sa date de dernière utilisation. Tout ce qui n'a pas servi depuis 90 jours est à révoquer immédiatement (et pas remplacé).

2. Pour chaque PAT actif : identifier le périmètre réel (10 min)

• Quelle intégration l'utilise ?
• Quels dépôts sont concernés ?
• Quelles opérations sont effectuées (read, write, workflow trigger, release, package publish) ?

Si vous ne savez pas répondre, la bonne posture est de révoquer et observer ce qui casse. Souvent rien ne casse — beaucoup de PAT historiques ne servent plus.

3. Créer le fine-grained PAT équivalent (10 min)

Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token.

• Resource owner : votre organisation (pas votre user personnel — important pour la traçabilité).
• Repository access : Only select repositories → choisir les dépôts précis. Bannir "All repositories".
• Permissions : commencer minimal, ajouter au besoin. Pour la plupart des intégrations CI/CD : Contents: read + Metadata: read suffisent. Pour publier : ajouter Contents: write. Pour les workflows : Actions: write. Pour les packages : Packages: write.
• Expiration : 90 jours maximum. Refusez "no expiration".

4. Tester en parallèle (5 min)

Remplacer le PAT dans l'intégration concernée, déclencher un workflow ou un déploiement de test, vérifier que ça passe. Si ça passe : révoquer l'ancien PAT.

Quand ne pas utiliser de PAT du tout

Trois cas où le PAT, même fine-grained, n'est pas la bonne réponse :

GitHub App pour les intégrations multi-utilisateurs

Une intégration installée chez plusieurs orgs (CI/CD SaaS, bot de review, dashboard de métriques) doit être une GitHub App authentifiée par installation token. Pas de PAT lié à un user qui peut quitter l'entreprise.

OIDC pour les déploiements depuis GitHub Actions vers le cloud

Un workflow GitHub Actions qui déploie vers AWS, Azure ou GCP doit utiliser l'OIDC federation. Le runner reçoit un token éphémère scopé au job courant. Plus de long-lived secret dans les secrets du dépôt.

Deploy keys pour les accès lecture seule à un repo unique

Si un script externe doit cloner un dépôt unique, une deploy key SSH (paire de clés ajoutée comme deploy key sur le dépôt) est plus simple, plus traçable, et limitée au dépôt par construction.

Les pièges à éviter

Le fine-grained sur le compte personnel d'un admin

Si vous créez le token sur votre compte personnel, sa visibilité organisationnelle est limitée et sa survie est liée à votre présence dans l'entreprise. Toujours créer sous le resource owner = l'organisation, et idéalement avec un compte de service dédié.

L'expiration "no expiration"

Disponible techniquement, à proscrire. Un token qui n'expire jamais est un token qu'on oublie. La rotation tous les 90 jours est inconfortable mais c'est précisément ce qui force à maintenir vos intégrations à jour.

Mettre en place sans documenter

Un fine-grained PAT créé sans documentation de son périmètre et de son usage redevient opaque en 6 mois. Le moindre tableau (token name, owner, scope, used by, expires) suffit, à condition qu'il existe.

Ce qu'on observe sur les missions WeeSec

Sur 12 audits SaaS B2B menés depuis octobre 2025, 10 utilisaient encore au moins un PAT classique repo en CI/CD. Sur ces 10, la migration vers fine-grained ou GitHub App a été faite en moins d'une semaine dans 9 cas. C'est probablement la mesure de sécurité avec le meilleur ratio effort / impact disponible aujourd'hui dans la stack de la plupart des éditeurs.

Pour la rotation automatique des secrets, Vault + Terraform + ArgoCD. Pour l'audit des actions GitHub utilisées, Supply chain GitHub Actions.