L’incident touchant @subql/common@5.8.3 rappelle une distinction essentielle : sécuriser le dépôt source et le compte de publication ne suffit pas si le pipeline peut modifier ou remplacer l’artefact juste avant sa diffusion.
Que s’est-il passé ?
Le 5 octobre 2026, StepSecurity a documenté du code malveillant dans la version 5.8.3 du paquet npm @subql/common. Le payload pouvait collecter des identifiants et fournir des capacités d’accès distant dans les environnements où le paquet était installé ou importé.
OpenSSF/OSV référence cette version sous l’identifiant MAL-2026-17571 comme paquet contenant du code malveillant.
Le point important
Le risque ne vient pas seulement du paquet lui-même : il vient aussi de la manière dont l’artefact final a été construit et publié.
Le dépôt source ne racontait pas toute l’histoire
Selon l’analyse de StepSecurity, le workflow de publication pouvait récupérer un artefact externe juste avant la release et remplacer le contenu normalement produit depuis le dépôt.
Autrement dit, le code visible et auditable dans Git pouvait diverger du paquet effectivement envoyé vers npm.
Cela change la question à poser :
« Le dépôt est-il propre ? » ne suffit plus. Il faut aussi demander : « l’artefact publié correspond-il réellement au code audité ? »
Une provenance valide ne garantit pas un contenu sûr
Les mécanismes de provenance restent utiles. Ils permettent d’identifier le workflow, l’identité de publication et l’environnement utilisés pour produire une release.
Mais une provenance valide indique surtout quel pipeline a publié. Elle ne garantit pas à elle seule que chaque fichier du paquet provient directement du code source attendu.
Si le workflow légitime est modifié pour télécharger ou substituer un artefact externe, la publication peut rester correctement authentifiée tout en diffusant un contenu inattendu.
Le pipeline devient un actif critique
Dans une chaîne de publication automatisée, le workflow CI/CD devient une frontière de sécurité à part entière.
Une modification de quelques lignes peut suffire à :
- télécharger un artefact depuis une source externe ;
- remplacer le résultat du build ;
- publier le nouveau contenu avec l’identité officielle du projet.
Le registre voit alors une publication autorisée, alors que le contenu n’est plus nécessairement celui produit depuis la source attendue.
Les dépendances transitives aggravent le problème
Le risque ne concernait pas uniquement les projets déclarant directement @subql/common. Des dépendances utilisant des plages de versions pouvaient résoudre automatiquement vers 5.8.3.
Une application pouvait donc récupérer la version compromise sans l’avoir explicitement ajoutée dans son propre package.json.
Les lockfiles versionnés et des installations déterministes réduisent ce type de dérive, mais ils ne remplacent pas l’analyse de la chaîne complète des dépendances.
Que vérifier si la version 5.8.3 a pu être utilisée ?
- examiner les lockfiles et caches de dépendances ;
- identifier les postes développeurs et runners CI ayant installé le paquet ;
- considérer les credentials disponibles dans ces environnements comme potentiellement exposés ;
- reconstruire les environnements temporaires ou images de build si nécessaire ;
- vérifier les accès cloud et tokens qui étaient disponibles pendant l’exécution.
Le simple blocage des scripts postinstall n’est pas une protection suffisante dans tous les cas, car du code malveillant peut aussi s’exécuter lors de l’import d’un paquet.
Comment réduire ce type de risque ?
1. Protéger les workflows de release
Les fichiers de CI qui publient des artefacts doivent être traités comme du code sensible : revue obligatoire, protection de branche et contrôle renforcé des changements de permissions ou de sources externes.
2. Construire une fois, publier le même artefact
Une chaîne plus sûre consiste à produire un artefact dans une étape contrôlée puis à publier exactement ce même artefact, sans reconstruction ou substitution ultérieure.
3. Limiter les téléchargements externes pendant une release
Un workflow qui utilise curl, wget ou télécharge dynamiquement des fichiers depuis une infrastructure externe doit pouvoir expliquer précisément pourquoi et d’où vient chaque fichier publié.
4. Comparer source, build et paquet distribué
Pour les composants critiques, comparer périodiquement le code source, l’artefact produit et le paquet effectivement distribué permet de détecter des écarts inattendus.
5. Rendre les installations déterministes
Versionner les lockfiles et utiliser des installations reproductibles comme npm ci aide à empêcher qu’une nouvelle résolution de dépendances modifie silencieusement l’environnement.
La supply chain réelle est plus longue qu’on ne le pense
La chaîne logicielle ressemble désormais davantage à :
développeur → dépôt → workflow CI → build → artefact → publication → registre → dépendances transitives → application
Chaque étape peut devenir un point de substitution ou de compromission.
Ce que cela suggère pour TechAtelier
Ce type d’incident renforce une idée utile pour l’analyse de posture : observer l’état final ne suffit pas toujours ; il faut aussi comprendre comment cet état a été produit.
Pour une chaîne CI/CD, plusieurs signaux deviennent particulièrement intéressants :
- utilisation de Trusted Publishing ;
- téléchargements externes dans les workflows ;
- permissions GitHub Actions excessives ;
- secrets disponibles pendant le build ;
- dépendances non figées ;
- scripts lifecycle npm ;
- écarts entre source et artefact distribué.
Ce qu’il faut retenir
L’incident @subql/common@5.8.3 ne montre pas que la provenance est inutile. Il montre qu’elle n’est qu’une pièce de la chaîne de confiance.
Un paquet peut être publié par la bonne organisation, depuis le bon workflow et avec une identité légitime, tout en contenant un artefact différent de celui que l’on pensait publier.
La sécurité de la supply chain doit donc relier directement :
code audité → build → artefact → publication.
Sources
- StepSecurity — SubQuery Ecosystem Compromise: Hidden Credential Theft and Backdoors
- OpenSSF / OSV — MAL-2026-17571
Publié le 6 octobre 2026. Les informations correspondent aux analyses et avis disponibles à cette date.