Le point intéressant n’est pas seulement qu’un paquet npm ait été compromis. C’est la chaîne complète : dépendance compromise, poste développeur infecté, token GitHub récupéré, puis lecture de dépôts privés. Chaque maillon pris isolément semble limité ; leur combinaison suffit pourtant à exposer une partie importante du patrimoine de code.
La chaîne de compromission
Dans son retour d’expérience, CrowdSec explique qu’un ancien employé restait membre de l’organisation GitHub afin de finaliser certains travaux. Son poste a récupéré une version compromise d’un paquet issu de l’écosystème TanStack, dans le contexte de la campagne Shai-Hulud.
Selon CrowdSec, le malware a permis aux attaquants d’obtenir un token GitHub valide. Le 22 mai 2026, ce token a ensuite été utilisé pour télécharger le contenu d’environ 170 dépôts privés.
La société indique que l’accès était en lecture seule dans les faits observés : aucune modification du code, des pipelines de build, des bases de données ou de l’infrastructure n’a été constatée. L’exposition concernait principalement du code source privé.
Le vrai sujet : l’offboarding ne doit pas être informel
L’accès GitHub du collaborateur concerné n’avait pas été révoqué immédiatement après son départ, parce que la séparation s’était bien passée et qu’il souhaitait terminer du travail. C’est humainement compréhensible, mais techniquement risqué.
Un compte qui n’est plus dans le fonctionnement quotidien de l’équipe peut recevoir moins d’attention : poste moins supervisé, sessions plus anciennes, tokens oubliés ou droits conservés plus longtemps que nécessaire.
Un départ ne doit pas produire une « zone grise »
Si une personne doit continuer à intervenir après la fin de son contrat ou de sa mission, mieux vaut recréer un accès temporaire, limité et daté que conserver les autorisations historiques du compte.
Un token GitHub est un accès, pas seulement un secret
Les tokens personnels, OAuth ou applicatifs doivent être gérés comme des identités techniques : propriétaire connu, portée définie, date d’expiration, dernière utilisation et ressources accessibles.
Lors d’un incident, la bonne question n’est donc pas seulement « quel secret a fuité ? », mais aussi : quels dépôts et quelles organisations ce secret permettait-il réellement d’atteindre ?
Cette visibilité devient d’autant plus importante que les outils modernes multiplient les credentials : CLI, IDE, agents IA, applications OAuth, automatisations, GitHub Apps et pipelines CI/CD.
Les mesures à retenir
- Révoquer les accès à la date de départ, puis recréer si nécessaire un accès temporaire et limité.
- Inventorier régulièrement les credentials : PAT, OAuth, SSH, GitHub Apps et comptes techniques.
- Réduire la durée de vie des tokens et éviter les credentials sans expiration.
- Limiter les scopes et les dépôts accessibles au strict nécessaire.
- Surveiller la dernière utilisation afin de repérer les accès dormants ou inattendus.
- Traiter le poste développeur comme une frontière de sécurité, car il concentre souvent code, tokens et accès CI/CD.
- Préparer la réponse forensique : journaux d’audit, historique des accès et capacité à relier un token à son propriétaire.
Pourquoi l’inventaire des credentials devient stratégique
GitHub a justement annoncé le 21 septembre 2026 un export d’inventaire des credentials pour GitHub Enterprise Cloud. L’outil peut regrouper clés SSH, PAT, tokens OAuth et GitHub Apps avec leurs propriétaires, permissions, dates et ressources cibles.
La fonctionnalité est réservée à l’offre Enterprise, mais le principe vaut pour toutes les équipes : être capable de répondre rapidement à « qui peut encore accéder à quoi ? » est une capacité de sécurité à part entière.
La supply chain ne s’arrête pas au paquet compromis
L’incident CrowdSec rappelle qu’une attaque de dépendance n’a pas besoin de compromettre directement la production pour avoir un impact. Un poste développeur peut être le pont entre une dépendance externe et des ressources internes sensibles.
La meilleure défense combine donc sécurité de la supply chain et hygiène des accès : dépendances surveillées, tokens courts et limités, révocation rapide, inventaire continu et règles d’offboarding explicites.
Sources
- CrowdSec — Analyse de l’attaque de la supply chain TanStack, 21 septembre 2026
- CrowdSec — TanStack Supply Chain Attack Analysis, 18 septembre 2026
- GitHub Changelog — Credential inventory exports, 21 septembre 2026
Publié le 22 septembre 2026. Les faits sur l’incident sont synthétisés à partir du retour d’expérience public de CrowdSec.