La récente compromission de Grafana Labs — confirmée le 18 mai 2026 après le vol d’un token GitHub non autorisé et l’exfiltration du code source — rappelle brutalement que la sécurité des tokens GitHub en PME-ETI reste l’angle mort le plus fréquemment exploité. Pour une PME ou une ETI qui pousse du code sur GitHub, héberge ses pipelines CI/CD et déploie via Actions, un seul Personal Access Token (PAT) compromis suffit à donner aux attaquants la même surface qu’un développeur senior.
Ce tutoriel pas-à-pas vous donne la méthode à appliquer dès aujourd’hui pour auditer, faire tourner et durcir vos tokens GitHub avant que la prochaine fuite ne devienne la vôtre.
1. Comprendre la surface d’attaque des tokens GitHub
Un token GitHub n’est pas un simple mot de passe. C’est un secret long-vivant qui survit à la rotation des mots de passe utilisateur, contourne la MFA et donne accès à tout ce que son scope permet : lecture/écriture de dépôts privés, gestion d’organisations, déclenchement de workflows, publication de paquets. Dans l’affaire Grafana, c’est précisément ce type de jeton — non protégé par MFA — qui a permis aux attaquants d’accéder au code source complet.
Les quatre familles de jetons que vous devez identifier dans votre PME-ETI :
- Classic PAT : large scope, longue durée — le plus dangereux.
- Fine-grained PAT : scope limité par dépôt — à privilégier systématiquement.
- OAuth App tokens : générés par intégrations tierces (CI, observabilité, IDE plugins).
- GitHub App installation tokens : courte durée, scope précis — la cible à atteindre.
2. Auditer immédiatement vos tokens GitHub
Avant de faire tourner quoi que ce soit, il faut savoir ce qui existe. Lancez ce diagnostic en moins d’une heure :
- Connectez-vous à GitHub, ouvrez Settings → Developer settings → Personal access tokens sur chaque compte ayant accès à votre organisation.
- Au niveau organisation, ouvrez Settings → Personal access tokens → Active tokens pour lister tous les PAT qui touchent vos dépôts privés.
- Pour chaque token, notez : propriétaire, scopes, date de création, date de dernière utilisation, dépôts concernés.
- Listez en parallèle vos secrets CI/CD (
GH_TOKEN,GITHUB_PAT,REPO_TOKEN) dans GitLab, Jenkins, CircleCI, Azure DevOps, n8n. - Identifiez les tokens qui n’ont jamais été utilisés depuis 90 jours : ce sont vos premiers candidats à la révocation immédiate.
Cette cartographie est le préalable à toute rotation. Sans elle, vous tournez à l’aveugle.
3. Faire tourner les tokens GitHub critiques
La rotation doit suivre un ordre précis pour éviter de casser la production :
- Créez le nouveau token en fine-grained PAT avec le scope strictement nécessaire (lecture seule par défaut, écriture uniquement si justifiée).
- Fixez une expiration courte : 30 jours maximum pour la production, 7 jours pour les pipelines automatisés.
- Mettez à jour les secrets dans votre coffre (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, ou GitHub Secrets de niveau organisation).
- Validez le rollout sur un environnement de staging avant production.
- Révoquez l’ancien token dans l’interface GitHub une fois la bascule confirmée.
- Vérifiez les logs GitHub via Settings → Audit log pour confirmer qu’aucune activité suspecte n’a eu lieu avant la révocation.
4. Durcir durablement vos tokens GitHub
La rotation n’est que la moitié du chemin. Pour empêcher la prochaine fuite, appliquez ces huit règles de durcissement :
- Bannir les Classic PAT au niveau organisation via Settings → Personal access tokens → Restrict access.
- Forcer SSO + MFA sur tous les comptes ayant accès aux dépôts privés.
- Limiter la durée de vie des tokens à 90 jours maximum (politique Token lifetime).
- Migrer vers GitHub Apps pour toutes les intégrations CI/CD — les installation tokens expirent en 1 heure.
- Activer l’audit log streaming vers votre SIEM (Wazuh, Splunk, Sentinel) pour détecter les exfiltrations.
- Scanner les fuites accidentelles avec GitHub Secret Scanning et Push Protection sur tous les dépôts publics et privés.
- Restreindre les IP sources via IP allow lists pour les comptes administrateurs (GitHub Enterprise).
- Documenter une politique de rotation dans votre PSSI : qui, quoi, quand, comment révoquer en urgence.
5. Détecter une compromission active
Si un attaquant possède déjà votre token, la rotation seule ne suffit pas. Recherchez ces signaux d’alerte dans l’audit log GitHub des 90 derniers jours :
- Clones de dépôts depuis des IP inhabituelles (hors géographie de l’équipe).
repo.add_memberouorg.invite_membernon sollicités.- Workflows GitHub Actions modifiés ou nouveaux runners auto-hébergés enregistrés.
- Push forcés sur la branche par défaut hors fenêtre de déploiement.
- Création de tokens, deploy keys ou webhooks par un compte de service.
Toute anomalie justifie une révocation immédiate de tous les tokens du compte concerné, suivie d’une rotation forcée des secrets dérivés (clés AWS, tokens npm, jetons applicatifs présents dans les variables d’environnement CI).
Pour aller plus loin
La sécurité des tokens GitHub en PME-ETI s’inscrit dans une stratégie plus large de protection de la supply chain logicielle. Si vous avez déjà subi une compromission npm ou GitHub, consultez notre guide checklist supply chain Shai-Hulud ; pour les fuites de credentials sur Bitwarden CLI, voyez notre tutoriel CI/CD post-Bitwarden.
L’enseignement de la fuite Grafana est clair : un token GitHub mal sécurisé donne autant d’accès qu’un développeur senior compromis. Appliquez ce playbook avant la prochaine alerte — pas après.