Le même flux d’événements GitHub que les organisations traitent souvent comme des données d’audit peut être utilisé comme télémétrie comportementale pour détecter les attaques de la chaîne d’approvisionnement logicielle.
De nombreuses attaques récentes contre la chaîne d’approvisionnement auraient pu être détectées plus tôt si les défenseurs avaient examiné de près la télémétrie déjà fournie par GitHub, ont déclaré les chercheurs.
Lors de leur présentation Black Hat USA 2026, les chercheurs Yossi Weizman de Microsoft et Mor Weinberger d’Echo ont argumenté en disant : « GitHub peut dire que vous êtes piraté. Vous n’écoutez tout simplement pas. »
Le duo a décrit une approche de détection de type EDR construite à partir du propre flux d’événements de GitHub plutôt que de s’appuyer uniquement sur la télémétrie conventionnelle des points de terminaison ou du réseau.
Après avoir étudié les récentes attaques de la chaîne d’approvisionnement, notamment Shai-Hulud, Trivy et Megalodon, les chercheurs ont découvert que des incidents apparemment différents utilisaient à plusieurs reprises les mêmes techniques, depuis les fausses identités de validation et les balises empoisonnées jusqu’à l’abus de flux de travail, le vol d’OpenID Connect (OIDC) et les tentatives d’effacement des preuves.
Ils ont déclaré avoir transformé ces techniques récurrentes en détections comportementales, combinant les webhooks GitHub, les données API et l’inspection du référentiel Git pour créer une vue historique de l’activité.
Leur nouvel outil open source, baptisé « GitHub Threat Detector », comprendrait 22 règles de détection de production et 12 règles bêta, avec des détections composées conçues pour corréler individuellement les signaux les plus faibles en alertes de haute confiance.
Tout laisse des preuves sur GitHub
L’observation centrale des recherches de Weizman et Weinberger est que les attaques contre la chaîne d’approvisionnement répètent souvent les mêmes schémas, même lorsque les projets ciblés ne sont pas liés.
Une identité compromise, par exemple, peut ne pas être évidente lors de la validation elle-même, car les métadonnées Git peuvent être falsifiées. Un attaquant peut définir le nom de l’auteur, l’adresse e-mail, l’horodatage, le parent et d’autres métadonnées pour qu’un commit malveillant paraisse légitime.
Mais GitHub enregistre séparément l’utilisateur authentifié qui a poussé la validation.
Lorsque l’auteur du commit ne correspond pas au pousseur authentifié, les défenseurs ont quelque chose qui mérite d’être étudié, ont-ils expliqué. De plus, leur analyse a révélé que les attaquants réutilisent parfois les mêmes identités forgées sur plusieurs victimes. Rechercher sur GitHub l’e-mail du même auteur peut donc aider à relier des incidents apparemment sans rapport dans une campagne plus large.
« Les identités forgées dans le repo, qui apparaissent également dans d’autres repos, constituent une forte indication de compromis », ont-ils déclaré.
La recherche a révélé qu’une « fausse identité du responsable » était utilisée dans de nombreuses attaques, notamment Trivy, tj-actions, Megalodon, TanStack et Red Hat.
Une autre détection basée sur le même principe consistait à suivre « l’empoisonnement massif des tags ». L’empoisonnement massif des balises implique le déplacement forcé de nombreuses balises de version sur une validation malveillante afin que les flux de travail utilisant une version telle que @v1 exécutent du code contrôlé par l’attaquant. Les chercheurs ont recommandé d’ajouter le suivi de l’historique des balises GitHub via l’API GitHub et de comparer les anciennes et les nouvelles références de validation pour détecter cela.
OIDC offre un autre signal. Les attaquants peuvent modifier les flux de travail pour générer des identités de courte durée pour les registres cloud ou de packages au lieu de voler des informations d’identification de longue durée. Selon les chercheurs, il peut être utile de surveiller les flux de travail nouveaux ou modifiés permettant l’émission de jetons OIDC.
Corréler les signaux faibles pour une détection plus forte
GitHub Threat Detector suit un pipeline de type EDR : collectez l’activité, enrichissez-la avec du contexte, détectez les comportements suspects, puis enquêtez ou répondez. Les signaux qu’il ingère incluent les webhooks GitHub en direct, les événements API, les validations, les balises et l’activité Actions, tandis que l’inspection Git fournit un contexte supplémentaire tel que la provenance des balises.
De plus, un magasin d’activités soutenu par PostgreSQL conserve l’historique nécessaire pour corréler les événements au fil du temps.
L’outil a repris 30 règles de détection et les a testées sur 52 simulations d’attaques, y compris la reproduction d’incidents Trivy, TanStack, Megalodon et Bitwarden CLI. Un « laboratoire de bruit » distinct a aidé les chercheurs à mesurer la prévalence et le rappel des détections, tout en ajustant les règles via des ajustements de liste verte et de gravité.
Le système n’est cependant pas sans inconvénients. Certains des compromis qu’il implique incluent des webhooks éventuellement désactivés, des API à débit limité et une inspection Git qui n’est pas en temps réel.
