Le jeton expire. La clé, non.
L'authentification GitHub App repose sur une clé privée qui génère un JSON Web Token (JWT) avec une durée de vie maximale de 10 minutes. Ce JWT demande ensuite un jeton d'accès d'installation, valide jusqu'à une heure. GitHub applique strictement ces expirations de jetons en aval, créant une illusion d'accès transitoire.
Cependant, la clé privée racine, source de ces informations d'identification, ne possède pas de durée de vie (TTL) native. Elle peut générer perpétuellement de nouveaux jetons jusqu'à ce qu'elle soit explicitement révoquée. Ce choix architectural fondamental signifie qu'une clé compromise ou oubliée reste une menace persistante, contrairement aux jetons à courte durée de vie qu'elle produit.
Bien que certains soutiennent que cela reflète le comportement des clés SSH, qui manquent également souvent d'expiration imposée par la plateforme, la portée des autorisations GitHub App augmente considérablement le risque. Les applications disposent souvent d'un accès large et multi-dépôts, notamment :
- Privilèges d'administration de l'organisation
- Accès en écriture au code privé
- Contrôle sur les self-hosted runners et l'exécution des workflows
Les recherches de GitGuardian ont révélé 474 clés actives, dont 44 accordant des droits complets d'administrateur d'organisation. Une clé, liée au CDC américain, a fourni un accès en écriture au code privé pendant 17 mois après sa fuite. Cela souligne pourquoi les clés GitHub App non gérées posent un risque de gouvernance important et durable, bien au-delà de celui d'une clé SSH typique.
474 clés divulguées ouvraient encore la porte
Les recherches récentes de GitGuardian ont révélé une réalité frappante : sur plus de 500 000 clés RSA exposées, 4 802 étaient liées à un ID GitHub App. Un nombre stupéfiant de 474 de ces clés étaient toujours authentifiées, représentant 440 applications distinctes, malgré leur exposition publique. Cela démontre une vulnérabilité critique dans la chaîne de sécurité.
Les implications de ces expositions persistantes sont graves. Quarante-quatre applications valides avaient un accès complet d'administrateur d'organisation, tandis que 72 % pouvaient lire des dépôts privés. De plus, 207 applications possédaient des autorisations d'écriture, ouvrant la porte à l'injection de code arbitraire et à l'empoisonnement de pipeline, un risque important pour la sécurité de la chaîne d'approvisionnement.
La persistance du problème est troublante. Une clé Crusher.dev était publique depuis 2020 et restait active. Une clé liée au CDC américain serait restée valide pendant 17 mois après son exposition. Une autre application largement utilisée, "Access Tokens for GitHub Actions", a divulgué une clé privée en janvier 2024, affectant environ 300 organisations, dont le contractant de défense Sierra Nevada Corp.
Ces exemples soulignent le danger des clés privées GitHub App : contrairement aux JWT et aux jetons d'accès d'installation à courte durée de vie qu'elles génèrent, les clés privées racine elles-mêmes n'ont pas d'expiration native. Cet oubli architectural transforme une fuite unique en une menace de sécurité perpétuelle, exigeant une attention immédiate et des stratégies robustes de rotation des clés.
Une application oubliée peut devenir un point d'ancrage dans la chaîne d'approvisionnement
Une application oubliée représente un point d'ancrage important dans la chaîne d'approvisionnement. Les clés divulguées peuvent permettre à un attaquant de lire du code privé, d'écrire dans des dépôts, de manipuler des workflows ou d'administrer des self-hosted runners. Un tel accès facilite directement la falsification de code, la compromission CI/CD et, finalement, la prise de contrôle de l'organisation.
Les intégrations obsolètes sont facilement négligées. GitGuardian a découvert que 59 % des 440 applications distinctes dotées de clés actives n'avaient qu'une seule installation, souvent pour de l'automatisation ad hoc. Lorsque les ingénieurs partent ou que les projets sont abandonnés, la propriété de ces applications disparaît fréquemment, laissant une vulnérabilité persistante. La clé de l'application Crusher.dev, exposée depuis 2020, est restée active des années après l'arrêt de la maintenance du projet.
L'organisation US Centers for Disease Control and Prevention (CDC), par exemple, a eu une clé privée divulguée avec un accès en écriture aux dépôts privés pendant 17 mois, servant d'intermédiaire pour l'accès à son infrastructure Microsoft Azure. De même, l'application largement utilisée "Access Tokens for GitHub Actions" a divulgué une clé privée, exposant environ 300 organisations.
Bien qu'une clé valide ne prouve pas automatiquement une exploitation active, elle signifie une exposition persistante. Les attaquants, une fois qu'ils obtiennent une clé valide, peuvent agir avec les autorisations accordées à l'application à tout moment. Pour plus de détails sur ces menaces persistantes, consultez les recherches de GitGuardian : GitHub App Private Keys: 474 Leaked Keys Still Work. Cela souligne le besoin critique d'une gestion rigoureuse des GitHub App private keys et de leurs autorisations associées pour atténuer les supply-chain risks.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Effectuez une rotation sans interruption de service — et retirez ce que personne ne possède
Les propriétaires d'applications doivent mettre en œuvre une stratégie robuste de rotation des clés. Générez une nouvelle private key, déployez-la et vérifiez son fonctionnement, puis révoquez l'ancienne. GitHub autorise jusqu'à 25 clés privées actives par application, permettant une rotation par étapes sans interruption de service.
Établissez une cadence de rotation documentée, des protocoles de stockage sécurisé des clés et intégrez le secret scanning dans tous les dépôts, y compris les forks publics appartenant aux développeurs. Appliquez l'accès au moindre privilège, en limitant les autorisations des applications aux seuls dépôts et actions strictement nécessaires à leur fonction. Cela minimise le rayon d'impact de tout compromis potentiel.
Les administrateurs d'organisation font face à un mandat critique pour auditer les applications installées. Identifiez et assignez des propriétaires responsables pour chaque intégration. Supprimez rapidement les applications abandonnées ou non maintenues, car elles deviennent des cibles privilégiées pour les attaquants cherchant un point d'ancrage persistant.
Enfin, vérifiez que toutes les applications survivantes fonctionnent avec le minimum absolu d'autorisations nécessaires. Examiner et resserrer ces contrôles d'accès réduit la surface d'attaque, empêchant une application oubliée de devenir une porte ouverte sur les actifs les plus sensibles de votre organisation.
Questions fréquemment posées
Les GitHub App private keys expirent-elles automatiquement ?
Non. Les GitHub App private keys n'ont pas de date d'expiration intégrée, les propriétaires doivent donc les faire pivoter et les révoquer.
Comment une clé GitHub App non expirée peut-elle être utilisée ?
Elle peut signer un JWT à courte durée de vie, qui peut être échangé contre un jeton d'accès d'installation d'une durée maximale d'une heure.
Combien de GitHub App private keys peuvent être actives en même temps ?
GitHub autorise jusqu'à 25 clés privées pour une application, permettant aux équipes de déployer un remplacement avant de supprimer l'ancienne clé.
Que doit faire une organisation concernant les applications que personne ne maintient ?
Auditez les GitHub Apps installées, supprimez les intégrations obsolètes ou sans propriétaire, et restreignez les autorisations et les dépôts accordés à celles qui restent.