Présentation de la nouvelle fonctionnalité

GitHub Enterprise Cloud permet désormais aux administrateurs d’exporter un inventaire exhaustif de toutes les identités capables d’accéder aux dépôts d’une organisation. L’export comprend les clés SSH, les jetons d’accès personnels (PAT) classiques et à granularité fine, les jetons OAuth d’applications et les jetons d’installation des GitHub Apps. Les données sont téléchargeables au format CSV depuis les paramètres d’authentification ou récupérables via une API REST paginée, avec des filtres par utilisateur, application, type de credential ou organisation.

Chaque ligne de l’inventaire indique le propriétaire, les scopes autorisés, les dates de création et d’expiration, ainsi que la dernière utilisation enregistrée. Un droit granulaire « View enterprise credentials » a été ajouté, permettant aux équipes de sécurité ou de conformité de consulter ces informations sans disposer de droits d’administration complets.

Contexte technique et motivations

Le besoin d’une visibilité centrale s’explique par l’augmentation du volume de credentials dans les chaînes d’approvisionnement logicielles. En mai 2026, GitHub a signalé le vol d’environ 3 800 dépôts internes après l’installation d’une extension VS Code contaminée, démontrant que les clés et jetons sont des vecteurs d’accès privilégiés. Le rapport « State of Secrets Sprawl 2026 » de GitGuardian a quant à lui relevé 28,65 millions de secrets codés en dur publiés en 2025, soit +34 % d’une année sur l’autre, et 64 % des secrets détectés en 2022 restaient actifs en janvier 2026. Bien que l’inventaire ne couvre pas les secrets incrustés, il cible le problème récurrent : les credentials créés pour une tâche restent souvent actifs bien après la fin du projet ou le départ du développeur.

Analyse de l’impact opérationnel

L’accès programmatique via l’API autorise l’intégration de l’inventaire dans les processus de sécurité existants. Une organisation peut, par exemple, planifier un appel quotidien à l’endpoint, comparer les résultats avec la collecte précédente et déclencher automatiquement des alertes pour les jetons sans date d’expiration ou inactifs depuis plus de 90 jours. Ces alertes peuvent être acheminées vers un SIEM ou un outil de gouvernance d’identité, créant ainsi un contrôle continu de l’hygiène des credentials.

Le filtrage par type de credential permet d’identifier les PAT classiques aux scopes larges qui pourraient être remplacés par des tokens à granularité fine, ou les GitHub Apps dont les jetons d’installation restent valides dans des organisations qui n’utilisent plus l’application. Cette visibilité facilite la priorisation des rotations : les credentials les plus à risque sont traités en premier, réduisant la surface d’exposition.

Limites et perspectives

Le principal point faible de la solution réside dans son caractère purement descriptif : l’inventaire ne révoque pas automatiquement les credentials ni n’applique de politiques de conformité. La responsabilité de définir ce qui constitue un « credential trop ancien » ou « trop permissif » incombe toujours aux équipes internes, qui doivent mettre en place des workflows de désactivation ou de rotation. GitHub prévoit d’étendre la fonctionnalité aux instances GitHub Enterprise Server dans les versions à venir, ce qui élargira la portée de la visibilité aux environnements on‑premise.