633 paquets npm malveillants ont passé la vérification Sigstore sans déclencher la moindre alerte
Les 633 versions ont été publiées en une seule salve. Chaque paquet portait une attestation de provenance Sigstore valide, ce qui signifie qu'un outil automatisé ou un humain vérifiant la chaîne de confiance npm n'aurait rien trouvé à redire. Le certificat de signature avait été émis par Fulcio, le service d'autorité de certification de Sigstore, sur la base d'un jeton OIDC obtenu depuis l'environnement CI du mainteneur dont le compte avait été compromis. Rekor, le log de transparence, a enregistré chaque opération. Tout était en ordre.
Sigstore a été conçu pour résoudre un problème précis : prouver qu'un artefact logiciel a bien été construit dans un pipeline CI identifié, avec un certificat éphémère lié à une identité vérifiée. Il ne prétend pas vérifier que l'identité en question n'a pas été volée. La nuance est technique. Ses conséquences ne le sont pas.
Le dernier signal automatisé
npm a introduit les attestations de provenance en 2023, s'appuyant sur Sigstore et les SLSA (Supply-chain Levels for Software Artifacts) pour offrir aux consommateurs de paquets un moyen de vérifier l'origine d'un build. GitHub Actions génère automatiquement ces attestations pour les paquets publiés depuis ses workflows. L'idée : si un paquet porte une provenance vérifiée, il a été construit dans un environnement contrôlé, par un acteur identifié. C'est devenu, dans beaucoup d'organisations, le dernier filtre automatisé avant d'accepter une dépendance.
Le problème est que ce filtre vérifie la cohérence d'une chaîne cryptographique, pas l'intention de la personne au bout. Un compte compromis avec un accès au pipeline CI produit des attestations rigoureusement identiques à celles d'un mainteneur légitime faisant son travail un mardi matin. Sigstore ne distingue pas les deux cas. Il n'a jamais été conçu pour ça.
Santiago Torres-Arias, professeur à Purdue et contributeur au projet Sigstore et aux spécifications in-toto, a rappelé après l'incident que les attestations de provenance vérifient « d'où vient un artefact, pas si la personne qui l'a publié avait le droit de le faire ». Il a comparé le mécanisme à un reçu de caisse : il prouve que la transaction a eu lieu dans le magasin, pas que la carte de crédit n'était pas volée.
Compromission de compte, pas compromission de pipeline
Le vecteur d'attaque initial reste, au moment de la publication de cet article, imparfaitement documenté. Ce qui est établi : l'attaquant disposait des credentials du mainteneur, y compris l'accès au workflow CI qui déclenche la publication. Il n'a pas eu besoin de contourner la MFA au niveau de npm si le token de publication était généré automatiquement par le pipeline — un schéma courant dans les projets qui utilisent les OIDC tokens de GitHub Actions pour publier sans secret statique.
npm a détecté et retiré les paquets. Le délai exact entre la publication et le retrait n'a pas été communiqué. 633 versions, c'est un volume qui suggère une automatisation côté attaquant, probablement un script qui itérait sur des noms de paquets existants ou des variantes de typosquatting.
En avril 2024, npm comptait environ 2,5 millions de paquets. Le registre a durci ses règles de publication à plusieurs reprises — obligation de 2FA pour les mainteneurs de paquets à forte adoption, introduction des attestations de provenance, granular access tokens. Chaque couche a réduit la surface d'attaque sur un axe précis. Aucune ne couvre le cas où l'attaquant hérite de l'ensemble des droits d'un mainteneur légitime.
Ce que la provenance prouve, ce qu'elle ne prouve pas
Le tableau ci-dessous résume ce que les attestations de provenance Sigstore vérifient effectivement et ce qu'elles laissent hors périmètre.
Les lignes surlignées sont celles qui comptent dans un scénario de supply chain attack. La provenance Sigstore ne les couvre pas, et ses concepteurs n'ont jamais prétendu le contraire. Le problème est ailleurs : dans la manière dont l'écosystème npm a transformé cette attestation en signal de confiance terminal.
Plusieurs outils de vérification de dépendances — Socket, Snyk, les policies OPA internes de certaines entreprises — utilisent la présence d'une attestation de provenance comme indicateur positif dans leur scoring. Un paquet avec provenance vérifiée est mieux noté qu'un paquet sans. Après le 19 mai, 633 paquets malveillants avaient le meilleur score possible sur cet axe.
Le maillon manquant
La question que l'incident pose aux équipes sécurité n'est pas « Sigstore est-il fiable » — il l'est, dans les limites de ce qu'il fait. La question est : qu'est-ce qui, dans votre chaîne de vérification, détecte qu'un mainteneur dont le compte a été compromis publie 633 versions en une session ? La réponse, pour la majorité des organisations qui consomment des paquets npm, est : rien.
npm n'expose pas, à ce jour, de mécanisme natif de détection d'anomalies comportementales sur les comptes mainteneurs — volume de publications, horaires inhabituels, changement soudain de scope des paquets publiés. GitHub a des outils de détection de compromission de compte côté plateforme (sessions suspectes, connexions depuis des IP inhabituelles), mais la publication npm via un token OIDC généré par un workflow CI ne passe pas nécessairement par les mêmes signaux.
En mars 2024, l'attaque contre xz-utils avait montré qu'un contributeur patient pouvait insérer une backdoor dans un projet critique sur plusieurs mois. Le vecteur était différent — ingénierie sociale prolongée contre un mainteneur isolé — mais la leçon convergente est la même : la confiance dans la supply chain logicielle repose in fine sur la sécurité de comptes individuels, et les couches cryptographiques ajoutées au-dessus ne compensent pas une compromission d'identité.
Le dépôt Sigstore sur GitHub précise dans sa documentation que « provenance attestations are not a substitute for code review or vulnerability scanning ». La phrase est là depuis le début. Elle n'a jamais empêché personne de traiter l'attestation comme un feu vert.
Le mainteneur dont le compte a été utilisé n'a pas été identifié publiquement.
TL;DR
633 paquets npm malveillants ont passé toutes les vérifications de provenance Sigstore parce que l'attaquant disposait du compte légitime d'un mainteneur — le système a fonctionné comme prévu, ce qui est exactement le problème.
- Sigstore vérifie la chaîne cryptographique d'un build, pas l'identité réelle de la personne qui le déclenche : un compte compromis produit des attestations indistinguables d'un compte légitime.
- npm et les outils de scoring de dépendances utilisent la provenance Sigstore comme signal de confiance terminal, transformant une vérification partielle en feu vert complet.
- Aucun mécanisme natif de détection comportementale (volume de publications, horaires, scope) n'existe côté npm pour repérer l'exploitation d'un compte mainteneur compromis.
Questions fréquentes
Sigstore est-il défaillant dans cet incident?
Non. Sigstore a fait exactement ce pour quoi il a été conçu : vérifier qu'un artefact a été construit dans un pipeline CI identifié avec un certificat valide. Il n'a jamais eu vocation à détecter une compromission de compte. Le problème réside dans l'interprétation de l'attestation comme preuve de légitimité complète.
Quelles mesures une équipe sécurité peut-elle prendre concrètement?
Ne pas utiliser la provenance Sigstore comme unique signal de confiance. Ajouter des vérifications complémentaires : analyse statique du code, détection d'anomalies sur les patterns de publication (volume, timing, scope), et monitoring des dépendances nouvellement publiées avant intégration automatique.
Combien de temps les paquets malveillants sont-ils restés disponibles?
npm n'a pas communiqué le délai exact entre la publication et le retrait des 633 versions. Le volume suggère une automatisation côté attaquant, ce qui implique une fenêtre d'exposition potentiellement courte mais suffisante pour des pipelines CI/CD qui résolvent les dépendances en temps réel.