La semaine dernière, GitHub a lancé une fonctionnalité de révocation en libre-service des identifiants pour sa version Enterprise. Cette fonctionnalité permet aux propriétaires d'organisations de bloquer en une seule opération tous les identifiants compromis au sein de l'ensemble de l'organisation, plutôt que d'essayer de retrouver chaque jeton individuellement lors d'un incident en cours.
Cette correction s'est fait attendre longtemps, car ces derniers mois ont montré ce qui se passe lorsque la révocation est lente ou incomplète. La Trivy en mars a connu un deuxième épisode, car le premier nettoyage avait laissé au moins un identifiant actif, et cette cascade a atteint Checkmarx plus tard. En juin, les référentiels « durabletask » de Microsoft ont été touchés via un compte qui n'avait jamais été entièrement nettoyé après une attaque antérieure.
Microsoft enchaîne les correctifs de sécurité ces derniers temps . Il y a quelques jours à peine, l’entreprise a mis en place des délais de publication après toute modification de compte, et plus tôt en juin, elle a également mis à jour npm afin de désactiver les scripts automatiques post-installation. Nous resterons attentifs aux autres mises à jour qu’elle publiera et à leur impact sur les attaques visant les logiciels open source.
Ce que GitHub a mis en ligne
Les propriétaires d'entreprise disposant de l'autorisation « Gérer les identifiants de l'entreprise » peuvent désormais révoquer ou supprimer en masse les identifiants de tous les utilisateurs de l'organisation, ou cibler un compte spécifique. Cela concerne les autorisations SSO pour les jetons d'accès personnels (PAT), les clés SSH et les jetons OAuth. Une option de suppression totale est disponible pour les organisations utilisant des utilisateurs gérés par l'entreprise (EMU), et les API REST au niveau de l'organisation permettent une révocation plus fine, spécifique à chaque organisation. Chaque action génère une entrée dans le journal d'audit et envoie des notifications par e-mail aux utilisateurs concernés.
Les membres individuels disposent désormais d'une nouvelle vue « Paramètres > Identifiants » qui affiche tous les identifiants associés à leur compte, qu'ils soient autorisés par l'authentification unique (SSO) ou personnels. À partir de là, une seule action suffit pour supprimer l'accès de tous ces identifiants aux ressources d'entreprise protégées par l'authentification unique (SSO), ce qui évite le processus fastidieux consistant à parcourir une liste de jetons un par un. Les membres des organisations EMU disposent également d'une option distincte leur permettant de supprimer définitivement tous leurs jetons et clés SSH.
Avant la mise en place de cette fonctionnalité d’urgence, il fallait passer par plusieurs outils différents pour supprimer les identifiants d’un compte. Les PAT à granularité fine pouvaient être révoqués depuis l’écran des jetons de l’organisation. Les jetons classiques ne pouvaient être supprimés que par la révocation de l’autorisation SSO au cas par cas, et uniquement si le SSO SAML était activé. L’API de révocation des identifiants permettait de désactiver un jeton, mais uniquement si l’on disposait déjà de la chaîne de caractères du jeton, ce qui fonctionne en cas de fuite d’un secret, mais pas en cas de compte compromis (ceci n’est qu’un aperçu des complexités, mais nous nous arrêterons là). En résumé, cela rendait la coordination des modifications d’identifiants particulièrement compliquée.
Remarque : les jetons GitHub Actions ne sont pas concernés ici, car ils sont générés pour chaque tâche et expirent à la fin de celle-ci ; il n'y a donc rien à révoquer. Pour limiter les dégâts en cas d'incident, il convient de désactiver les Actions sur le dépôt.
Pourquoi maintenant ?
Les récentes attaques de logiciels malveillants ont touché Microsoft de plein fouet.
Le 19 mai, des pirates ont utilisé des identifiants volés précédemment pour diffuser trois versions malveillantes de Microsoft durabletask paquet sur PyPI, dans le cadre de la campagne du ver Miasma. Microsoft a retiré les paquets en quelques heures. Cependant, le 5 juin, ce même compte a publié un commit malveillant dans le dépôt GitHub `Azure/durabletask`, réintroduisant ainsi le ver. GitHub a réagi en désactivant 73 dépôts répartis dans quatre organisations GitHub de Microsoft. Parmi ceux-ci figuraient les outils Azure Functions utilisés par de nombreuses équipes pour leurs déploiements, ce qui a perturbé les pipelines CI/CD bien au-delà de Microsoft. Les chercheurs avancent plusieurs explications possibles à cette récidive, mais la plus plausible est que les identifiants de mai n’ont jamais été entièrement renouvelés. Une société de surveillance a par la suite découvert que les identifiants GitHub de ce compte figuraient dans les journaux d’un voleur d’informations remontant au mois d’avril. Quel que soit le mécanisme exact, le même compte a été utilisé lors de ces deux compromissions.
Mais ce n’est pas nouveau, et le problème s’est déjà manifesté à plusieurs reprises cette année. Fin février 2026, un programme malveillant Un bot IA a exploité une erreur de configuration pull_request_target Workflow GitHub Actions dans le dépôt Trivy, ce qui a permis à l'attaquant de s'emparer d'un PAT disposant d'un accès en écriture à plus de 33 workflows au sein de l'organisation Aqua Security . Aqua Security la faille et procédé à la rotation des identifiants. Malheureusement, cette rotation n'a pas été menée à bien, et les identifiants n'ont pas tous été révoqués simultanément.
Le 19 mars, les attaquants ont utilisé des identifiants qui avaient survécu à une rotation incomplète pour forcer la publication de 75 des 76 balises de version du dépôttrivy sous forme de commits malveillants. La charge utile s’exécutait avant le véritable Trivy dans chaque pipeline, de sorte que chaque workflow semblait se dérouler normalement. Les pipelines CI/CD exécutant Trivy les identifiants de leurs propres runners, tels que les clés SSH, cloud , les jetons Kubernetes et les PAT GitHub.
Quatre jours plus tard, les identifiants volés sur ces pipelines ont été utilisés pour infecter les GitHub Actions Checkmarx à l'aide d'une charge utile de vol de données identique. Checkmarx que l'activité des cybercriminels s'était poursuivie dans son environnement jusqu'au 22 avril, les données exfiltrées ayant été publiées sur le dark web le 25 avril.
Toute cette Checkmarx d'événements, Trivy Checkmarx , trouve son origine dans une rotation incomplète des identifiants. Si Aqua Security pu bloquer instantanément tous les identifiants du compte de service compromis après la faille de février, l'attaque se serait arrêtée là.
La rotation atomique, c'est quoi ?
La rotation atomique consiste à remplacer un identifiant en une seule opération « tout ou rien » ; il n’y a donc aucun moment où l’ancien et le nouvel identifiant fonctionnent simultanément. L’objectif est d’éviter toute interruption de service. C’est une bonne idée en théorie. Mais dans un système distribué, cela ne fonctionne tout simplement pas ainsi. Cela nécessite beaucoup trop de coordination. À l’échelle d’une organisation comme GitHub, la rotation atomique n’a aucun sens.
En réalité, la rotation des identifiants suit l'une des deux approches suivantes, toutes deux imparfaites. La rotation de routine maintient les deux identifiants valides pendant un certain délai afin d'éviter toute interruption de service, ce qui convient lorsque tout fonctionne normalement, mais laisse l'ancien identifiant actif. La réponse aux incidents fait le contraire : elle désactive immédiatement l'ancien identifiant et accepte que le service soit interrompu jusqu'à la réémission du nouvel identifiant.
Un bouton « briser la vitre » vous permet d’effectuer la seule action véritablement « atomique », à savoir supprimer d’un seul coup tous les identifiants concernés. Certes, cela perturbe le cycle CI/CD. Mais expulser un attaquant de votre infrastructure est bien plus important, et cela vaut largement quelques heures ou quelques jours de builds interrompus.
Jusqu’à présent, la suppression simultanée de toutes les informations d’identification était tout simplement difficile à mettre en œuvre. Cette nouvelle procédure de suppression en une seule étape permet de la réaliser même sous pression, et bien que la rotation atomique complète reste encore assez difficile à atteindre, cela nous rapproche du scénario idéal.
Que faire ?
Au sein de votre organisation GitHub, assurez-vous que l'autorisation « Gérer les identifiants d'entreprise » est attribuée à une personne capable d'agir immédiatement, et faites-le avant qu' un incident ne se produise. Consultez dès maintenant la section Paramètres > Identifiants afin de bien comprendre ce qui est concerné.
Par ailleurs, lorsque vous mettez à jour vos paramètres de sécurité, veillez à ancrer vos actions GitHub Actions à des SHA de commit complets plutôt qu’à des balises de version. Les balises peuvent faire l’objet d’un « force push » afin de pointer vers un code totalement différent, ce qui constitue la technique principale à l’origine de la Trivy . Un SHA de commit ancré ne peut pas être déplacé.
Aikido surveille vos applications en temps réel afin de détecter les paquets compromis. Lorsqu'un élément de votre pipeline est corrompu, vous recevez une alerte avant même que le programme de collecte d'identifiants ne s'exécute. Cette fonctionnalité s'appuie sur Aikido , qui analyse les nouvelles versions des paquets dès leur mise en ligne.
Merci pour toutes ces mises à jour, Microsoft. Continuez comme ça, s'il vous plaît. 🙏
