Menu

SlugFest : un nom de repo n’est pas une identité, de npm à vos rôles IAM

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
2 min de lecture
⏱️
Temps de lecture estimé
~4 minutes

Un mainteneur lie son package npm à un nom de repo GitHub, ne publie jamais, puis renomme son organisation. N’importe qui peut réclamer l’ancien nom et publier à sa place, sans voler le moindre token. SlugFest touche plus de 1 500 packages npm, et le même défaut de conception guette vos trust policies OIDC vers AWS, Azure et GCP.

Un mainteneur lie son package npm à PandaFactory/widget via le Trusted Publishing, ne publie rien, puis l’organisation PandaFactory est renommée. Le nom PandaFactory/widget redevient libre. Quelqu’un le réclame, y pousse un workflow du bon nom, et npm lui remet des identifiants de publication valides pour le package d’origine. Pas de token volé, pas de compte compromis : un nom qui se fait passer pour une identité.

Ce que dit la recherche

  • La cause : npm stockait le nom du repo et celui du workflow, pas les identifiants numériques repository_id et repository_owner_id que GitHub met pourtant dans son jeton OIDC.
  • La condition : une liaison jamais utilisée pour publier, vers un nom devenu réclamable.
  • La portée : plus de 1 500 packages et plus de 10 millions de téléchargements cumulés, selon Bloom Security, qui vend aussi des outils de sécurité de la chaîne d’approvisionnement. Aucune exploitation réelle rapportée.
  • Le correctif : depuis le 2 octobre, une configuration non validée expire après 48 heures, et les jetons issus d’événements issue_comment sont refusés. Le modèle ne change pas, la fenêtre d’exposition se réduit.

Au menu de la version abonnés

Au Menu, la suite de l’analyse :

  • le diagramme de séquence de l’attaque et son scénario en cinq temps, avec la provenance Sigstore qui reste valide vers le mauvais repo ;
  • le rapprochement avec vos trust policies OIDC vers AWS, Azure et GCP : la condition sub est un nom, et un nom peut se libérer ;
  • le script d’audit des rôles IAM qui font confiance à GitHub ;
  • l’analyse STRIDE et le tableau d’impact détaillés ;
  • les sept mitigations, des liaisons npm aux claims sub immuables, et le cas des agents qui installent la dernière version sans regarder ;
  • un aperçu du contenu premium : audit comparant vos noms à l’état réel de GitHub, durcissement Terraform, requête de détection CloudTrail et playbook si un nom a été libéré.
📬 Analyse complète réservée aux abonnés Substack
Le mécanisme, le pont vers vos trust policies cloud, le STRIDE et les mitigations partent d'abord aux abonnés Substack, avant d'être publiés intégralement ici.

📚 Quelques références pour aller plus loin

LinkedIn Reddit Substack