npm, PyPI, Docker Hub : pourquoi la supply chain open source est devenue une cible majeure

Faits, analyse et incertitudes

Pourquoi les registres sont devenus une cible de premier plan

Une application contemporaine est composée à plus de quatre-vingts pour cent de code qu'elle n'a pas écrit. Ce code provient de registres publics, est récupéré automatiquement lors de chaque construction, et s'exécute avec les droits de la chaîne d'intégration continue. Pour un attaquant, c'est une configuration remarquable : le code n'a pas à franchir de périmètre, il est téléchargé volontairement.

• La cible n'est pas l'organisation visée mais un mainteneur, souvent bénévole, dont les moyens de protection sont sans rapport avec ceux d'une entreprise
• La portée est démultipliée : un paquet largement utilisé donne accès à tous ceux qui l'installent, y compris à des organisations qui ignorent en dépendre
• L'exécution est privilégiée : les scripts d'installation et les étapes de construction s'exécutent avec les secrets du pipeline
• La détection est difficile : un paquet malveillant fait aussi ce qu'il est censé faire, et le comportement anormal se noie dans une construction qui réussit
• La fenêtre nécessaire est courte : quelques heures suffisent à atteindre des dizaines de milliers d'environnements
• Le butin est directement réutilisable : les secrets collectés donnent accès à d'autres registres, d'autres dépôts, d'autres environnements cloud

Les voies d'entrée documentées

• Compte de mainteneur compromis

  Hameçonnage ciblé, jeton exposé dans un journal de construction, réutilisation de mot de passe. C'est la voie la plus productive, parce qu'elle permet de publier sous une identité légitime, avec la réputation du projet.

• Étiquettes de version réécrites

  Une étiquette Git n'est pas immuable. Un attaquant qui dispose d'un accès en écriture peut la faire pointer ailleurs. Les utilisateurs qui référencent une version par son étiquette récupèrent alors un autre contenu sans rien changer chez eux.

• Typosquatting

  Publication d'un paquet au nom proche d'un paquet légitime, misant sur une faute de frappe ou une confusion de nom. Coût nul pour l'attaquant, efficacité faible mais non nulle, et durée de vie limitée par la modération des registres.

• Confusion de dépendances

  Publication, sur un registre public, d'un paquet portant le nom d'un paquet interne à une organisation. Si l'outil de construction interroge le registre public avant le registre privé, ou privilégie la version la plus élevée, il installe celui de l'attaquant.

• Compromission d'une dépendance légitime

  Le cas le plus difficile à détecter : le paquet attendu, publié par le projet attendu, contenant en plus du code malveillant. C'est ce qui s'est produit avec Trivy, puis avec les paquets Python atteints ensuite.

• Images de conteneurs publiques

  Les images publiques sont récupérées automatiquement par les chaînes de construction et les orchestrateurs. Unit 42 a documenté des campagnes d'images de minage publiées sur un registre public et téléchargées à très grande échelle avant leur retrait.

Ces six voies ne sont pas concurrentes : elles s'enchaînent. La compromission d'un compte de mainteneur permet la réécriture d'étiquettes, qui permet la collecte de secrets, qui permet la compromission d'autres comptes dans un autre écosystème. C'est ce mécanisme de propagation, et non la sophistication technique d'un paquet particulier, qui fait la gravité du phénomène.

Ce que cherche un paquet malveillant

Le code injecté dans l'écosystème Trivy donne une image précise des objectifs. Il ne cherchait ni à chiffrer des données ni à saboter des constructions : il cherchait des identifiants, méthodiquement, dans la mémoire du processus d'exécution et dans plus de cinquante emplacements du système de fichiers.

• Clés SSH privées, qui ouvrent des accès à des serveurs et à des dépôts
• Identifiants d'accès aux fournisseurs cloud, qui ouvrent des environnements entiers
• Jetons Kubernetes, qui donnent la main sur des charges de travail en production
• Configurations de registres d'images, qui permettent de publier à son tour
• Fichiers d'environnement et identifiants de bases de données
• Secrets du pipeline d'intégration continue, présents en mémoire au moment même de l'exécution

Un détail mérite d'être relevé : après la collecte, le code lançait le scan légitime. La construction réussissait, les rapports étaient produits, rien n'était visible. C'est la signature d'une opération pensée pour durer, et non pour un gain immédiat.

Les mesures qui réduisent réellement l'exposition

Aucune mesure ne supprime le risque d'utiliser du code écrit par d'autres. En revanche, plusieurs pratiques transforment une compromission d'écosystème en incident circonscrit. Elles ont un point commun : elles rendent la chaîne de construction reproductible, donc vérifiable.

Figer ce qui est installé

Le délai de refroidissement mérite une mention particulière. Les fenêtres documentées par PyPI sont de deux à quatre heures entre publication et mise en quarantaine. Un délai d'adoption de trois jours aurait suffi, dans ces deux cas, à ne jamais installer les versions piégées. C'est une mesure simple, gratuite et efficace, qui coûte seulement une part de réactivité sur les mises à jour.

Supprimer les secrets de longue durée

Les deux grands registres ont fait converger leurs orientations. npm a révoqué en décembre 2025 l'ensemble de ses jetons historiques, introduit des sessions courtes et plafonné la durée de vie des jetons en écriture. PyPI généralise la publication de confiance, qui remplace un jeton stocké par une identité vérifiée auprès du fournisseur d'intégration continue, et génère automatiquement une attestation de provenance.

Pour une organisation, la transposition est directe : aucun secret de publication ne devrait être stocké de façon permanente dans une variable de pipeline. Ce qui ne peut pas être volé n'a pas besoin d'être surveillé.

Savoir ce que l'on utilise

• Inventaire des composants

  Une nomenclature logicielle, ou SBOM, répond à une question que beaucoup d'organisations ne peuvent pas trancher en quelques heures : est-ce que ce paquet compromis est présent quelque part chez moi, et dans quelles versions ?

• Provenance et signature

  Les attestations de provenance permettent de vérifier qu'un artefact a bien été produit par la chaîne de construction annoncée. Le référentiel SLSA formalise des niveaux de garantie progressifs sur ce point.

• Veille sur les paquets malveillants

  Le dépôt public de l'OpenSSF rassemble les signalements de paquets malveillants au format Open Source Vulnerability, ce qui permet de les intégrer aux outils existants plutôt que de suivre des annonces éparses.

• Analyse automatisée

  Les outils de mise à jour automatique et de recherche de vulnérabilités dans les dépendances restent utiles, à condition de ne pas les configurer pour appliquer sans délai la dernière version publiée.

• Moindre privilège dans la chaîne de construction

  Permissions minimales par tâche, séparation des environnements, interdiction pour une tâche de construction d'accéder à des secrets de production. La collecte décrite plus haut ne récupère que ce qui est accessible.

• Authentification forte des mainteneurs

  Pour les organisations qui publient elles-mêmes des paquets : authentification à deux facteurs par clé matérielle sur tous les comptes de publication, sans exception ni procédure de secours affaiblie.