
Teknik - Clés privées GitHub App - Parce que... c'est l'épisode 0x365!
Parce que… c’est l’épisode 0x365!
Shameless plug
- 13 et 14 novembre 2026 - Worldwide - DEATHCon
- 16 au 19 novembre - Rennes, France - European Cyber Week 2026
- 25 et 26 février 2027 - Québec, Canada - SéQCure 2027
- 9 au 11 mars 2027 - Lilles, France - Forum INCYBER - Europe 2027
- I.A. Café - Enquête au cœur de la recherche sur l’intelligence artificielle
- 16 novembre 2026 - Paris, France - CNIL - Convaincre ou manipuler ? L'éthique du numérique à l'épreuve des urnes
- Boostsecurity - Dazio
Description
Cette description a été faite à l’aide de GLM 5.3 Flash, à partir de la transcription qui a été effectuée par ElevenLabs Scribev2. Aucune vérification humaine n’a été faite. Si vous découvrez des erreurs ou des inexactitudes, vous pouvez m’en faire part afin que je procède aux modifications appropriées.
Une application GitHub, un plugin aux privilèges étendus
Une application GitHub fonctionne comme un plugin que l’on greffe sur une organisation. Ce bout de logiciel reçoit des droits et des privilèges, puis agit au nom de l’organisation sur ses dépôts, par exemple pour l’analyse de code dans la CI, la revue automatisée ou le scan de secrets, comme GitGuardian. Le marketplace de GitHub recense des dizaines de milliers d’applications publiques. À l’installation, l’application demande des permissions allant de la simple lecture des dépôts jusqu’à l’administration complète de l’organisation, ainsi qu’un périmètre appelé scope, qui limite l’accès à tous les dépôts ou à une sélection. La combinaison des droits et du scope définit ce qu’elle peut accomplir.
Un mécanisme d’authentification en deux jetons
Côté GitHub, la création d’une application se résume à un nom, une description et surtout une clé privée d’authentification. L’application, déployée où l’on veut, signe un jeton JWT avec cette clé pour interroger l’API et obtenir quelques métadonnées, dont ses permissions et la liste de ses installations. Elle échange ensuite ce jeton d’application contre un jeton d’installation qui lui permet d’agir avec l’identité de l’organisation où elle est installée. Ce second jeton expire au bout de dix minutes maximum, ce qui le rend peu exposé en cas de fuite. Le point critique demeure la clé privée, qui n’a aucune date d’expiration et qui permet de générer un jeton d’installation pour n’importe laquelle des installations de l’application.
Une méthodologie issue du travail sur les clés privées
Gaetan Ferry et son équipe prolongent leurs travaux du NorthSec sur les clés privées fuitées et les certificats. Ils ont exploité leur jeu de données d’environ 500 000 clés privées, restreint aux clés RSA puisque GitHub n’en génère que pour ses applications. Une étape de filtrage contextuel a retenu environ 5 000 candidats dont le contexte de fuite mentionnait GitHub ou un identifiant d’application, typiquement un fichier associant une clé hardcodée et un identifiant reconnaissable, souvent préfixé par Iv1. Chaque clé candidate a ensuite servi à signer un jeton envoyé à l’API pour vérifier sa validité.
Un taux de validité étonnant et un effet de levier
Au total, 474 clés se sont révélées valides, soit près de 10 %, alors que le taux habituel des secrets exposés sur GitHub tourne autour de 1 à 2 %, un résultat surprenant mais qui s’explique. Leur danger tient à l’effet de levier, car une seule clé peut donner accès à des centaines, voire des milliers d’organisations selon le nombre d’installations.
Deux profils d’applications compromises
L’échantillon distingue deux familles. Environ neuf applications sur dix sont à usage très restreint, avec une ou deux installations, souvent privées et conçues pour un besoin interne, comme la coordination avec une infrastructure cloud de build et de test. Leur compromission pénètre en profondeur dans l’écosystème de l’organisation, un atout précieux pour une attaque ciblée. Les applications de marketplace peuvent au contraire toucher un immense public. L’application compromise la plus installée en affichait environ 330 et échangeait des jetons OIDC dans la CI, notamment chez des chaînes automobiles. À l’opposé, la clé de BuildBuddy, un système de build issu de Google, donnait accès au dépôt de l’entreprise elle-même et aurait permis de compromettre ses serveurs, puis par rebond les clients de son offre SaaS.
Une divulgation aux résultats mitigés
L’équipe a contacté les mainteneurs en retrouvant les comptes associés aux applications. Les réactions sont rapides et positives quand l’impact est manifeste, certaines clés ayant été révoquées en moins de deux heures. Les entreprises privées répondent en revanche rarement, voire négativement. Le cas du CDC est emblématique. Une application rattachée à deux organisations du Center for Disease Control servait de pont entre l’organisation GitHub hébergeant leur code et leur infrastructure Azure, où le code poussé s’exécutait ensuite. Le signalement via leur programme de divulgation, un bug bounty sans récompense, est resté sans réponse pendant deux semaines, et des contacts ouverts depuis l’affaire CISA ont fini par débloquer la situation. Gaetan y voit la difficulté de révoquer un secret au cœur d’une infrastructure complexe sans savoir ce qui va casser, la clé étant exposée depuis 2022 sans avoir été exploitée. S’y ajoutent des projets abandonnés, tel un framework de test JavaScript mort depuis 2023, dont la clé reste valide sans aucun canal de contact, les domaines étant rachetés par des squatteurs. GitHub, sollicité pour faire révoquer ces clés orphelines, n’a pas répondu.
Des recommandations concrètes
Le premier réflexe consiste à dresser l’inventaire des applications installées, de leurs scopes, des dépôts accessibles et des permissions, afin de repérer les applications oubliées. À l’installation, il faut examiner les permissions demandées et réduire le périmètre plutôt que d’accepter l’accès à tout, selon le moindre privilège. Les développeurs sont invités à révoquer régulièrement leurs clés, d’autant que GitHub n’offre ni expiration automatique ni gestion par API, la rotation se faisant manuellement dans l’interface. Le dialogue avec les éditeurs pour recadrer des permissions excessives reste précieux. L’étude révèle enfin que 44 des 474 applications compromises, soit près de 10 %, détenaient la totalité des droits sur l’API, dont l’administration de l’organisation, toutes relevant de l’outillage interne. Compromettre une seule de ces clés revient à remettre les clés de la maison.
Un dernier mot sur l’hygiène de base
Les intervenants rappellent que ces recommandations relèvent de l’hygiène de base, répétée depuis des décennies, mais qui continue pourtant de générer des incidents. L’épisode se termine sur une proposition amusante, un lexique Polysecure nourri des synonymes improvisés pour traduire blast radius, dont la mémorable zone de déflagration.
Notes
Contributeurs
.contributors-table { border-collapse: separate; border-spacing: 20px 8px; } .contributors-table td, .contributors-table th { border: none; background: transparent; text-align: center; vertical-align: top; } .contributors-table img.contributor-photo { width: 100px; height: 100px; object-fit: cover; border-radius: 50%; } .contributors-table .contributor-name { display: block; margin-bottom: 4px; font-weight: bold; } .contributors-table .contributor-socials img { margin: 0 2px; } Nicolas-Loïc Fortin Gaetan FerryCrédits
- Montage par Intrasecure inc
- Locaux virtuels par Riverside.fm
D'autres épisodes de "PolySécure Podcast"



Ne ratez aucun épisode de “PolySécure Podcast” et abonnez-vous gratuitement à ce podcast dans l'application GetPodcast.








