La confusion de dépendances est une attaque de la chaîne d’approvisionnement qui exploite le comportement de résolution des paquets des outils de build et des gestionnaires de paquets. Lorsqu’un environnement de développement est configuré pour résoudre des paquets à la fois depuis des registres publics (npm, PyPI, Maven Central) et depuis des registres privés ou internes, de nombreux gestionnaires de paquets préfèrent, par défaut ou à la suite d’une mauvaise configuration, un paquet public portant un numéro de version plus élevé à un paquet privé de même nom portant un numéro de version inférieur. Un attaquant qui identifie le nom d’un paquet interne, grâce à des offres d’emploi, des dépôts GitHub, des messages d’erreur ou de la documentation, peut publier dans le registre public un paquet malveillant portant ce nom avec un numéro de version plus élevé. Le système de build résout la version publique, exécute le code de l’attaquant, et la compromission se produit lors d’une installation de dépendances de routine plutôt que par une quelconque vulnérabilité du logiciel lui-même.
Le mécanisme de découverte constitue la première phase de l’attaque. Les attaquants identifient les noms de paquets internes par de multiples canaux : offres d’emploi qui mentionnent des frameworks d’outillage internes, dépôts GitHub publics dont les fichiers de configuration contiennent des noms de paquets internes, messages d’erreur qui affichent des noms de paquets lorsque des paquets internes sont introuvables, documentation qui fait référence à des outils internes et contributions open source d’employés qui révèlent les conventions de nommage internes. Le nom d’un paquet n’est pas un secret : il figure dans les fichiers de build, dans les documents de configuration et dans la mémoire collective de l’équipe de développement. Le traiter comme confidentiel n’est pas une défense viable.
Le mécanisme de priorité de résolution est la vulnérabilité technique. Les gestionnaires de paquets comme npm, pip et Maven sont conçus pour résoudre la version la plus élevée d’un paquet correspondant à la plage de versions spécifiée. Lorsque des registres publics et privés sont tous deux configurés, de nombreuses mises en œuvre interrogent les registres publics et appliquent des règles de priorité des versions qui permettent à un paquet public portant un numéro de version plus élevé de supplanter un paquet privé de même nom. Ce comportement est configurable (la priorité du registre privé peut être imposée), mais ce n’est pas la configuration par défaut de nombreuses installations courantes.
Pourquoi c’est important
La confusion de dépendances compte pour le TPRM, car c’est une attaque de la chaîne d’approvisionnement à laquelle vos fournisseurs peuvent être exposés, en particulier les éditeurs de logiciels et les fournisseurs d’outils de développement qui utilisent des registres de paquets internes en plus de dépendances publiques. Un fournisseur dont l’environnement de build est exposé à la confusion de dépendances peut voir son pipeline de build compromis sans aucune exploitation de vulnérabilité classique, et produire des artefacts logiciels qui contiennent le code de l’attaquant tout en passant la revue de code et les analyses de sécurité standard.
- Exposition de l’environnement de build du fournisseur à la confusion de dépendances non évaluée
- Configuration de la priorité du registre privé absente des questions de sécurité posées aux fournisseurs
- Exposition des noms de paquets internes dans des sources publiques non évaluée
- Configuration de la résolution des dépendances hors du périmètre de l’évaluation TPRM
- Vecteurs d’attaque au moment du build non évalués en plus de la sécurité à l’exécution
À quoi ressemblent les bonnes pratiques
Les programmes matures de sécurité de la chaîne d’approvisionnement logicielle évaluent la configuration des environnements de build des fournisseurs au regard des vulnérabilités de confusion de dépendances, en vérifiant notamment si la priorité du registre privé est imposée, si les noms de paquets internes sont réservés dans les registres publics et si les environnements de build sont configurés pour rejeter les paquets provenant de sources inattendues.
- Application de la priorité du registre privé : paquets privés résolus avant les paquets publics
- Réservation des noms de paquets internes dans les registres publics à titre de mesure défensive
- Isolation de l’environnement de build : accès réseau restreint pendant les builds
- Vérification de l’intégrité des paquets : vérification des empreintes de tous les paquets résolus
- Audit de la résolution des dépendances : examen de la configuration de résolution des registres
Outils
Détection de la confusion de dépendances : Confused, Protect by Socket.dev pour les tests de confusion de dépendances
Les outils de test de la confusion de dépendances permettent d’identifier les noms de paquets internes qui ne sont pas enregistrés dans les registres publics et qui constituent donc des cibles potentielles d’attaques par confusion de dépendances. Pour les praticiens du TPRM, demander aux fournisseurs s’ils ont vérifié la disponibilité de leurs noms de paquets internes dans les registres publics et s’ils les ont réservés à titre défensif constitue une question précise sur l’atténuation de la confusion de dépendances.
Enjeux de gouvernance
Le défi de gouvernance que pose la confusion de dépendances tient à la complexité de la configuration. Configurer correctement la priorité des registres des gestionnaires de paquets dans tous les environnements de développement, pipelines CI/CD et postes de travail des développeurs exige une politique et une application délibérées : la configuration par défaut est souvent non sécurisée. La réponse en matière de gouvernance consiste à définir des normes explicites de configuration des registres, appliquées de manière cohérente dans tous les environnements de build.
- Imposez la priorité du registre privé dans toutes les configurations des gestionnaires de paquets
- Réservez à titre défensif les noms de paquets internes dans les registres publics
- Auditez la configuration des registres dans tous les environnements de build
- Testez la confusion de dépendances à l’aide d’outils de détection automatisés
- Intégrez la résolution des dépendances à l’évaluation de la sécurité des builds des fournisseurs
Si vous êtes une petite équipe
Posez à vos fournisseurs de logiciels les plus critiques une question que leur questionnaire de sécurité standard ne traite pas : utilisez-vous des registres de paquets privés en plus des registres publics et, si oui, comment vous assurez-vous que vos systèmes de build résolvent d’abord depuis les registres privés afin d’empêcher la confusion de dépendances ? Un fournisseur qui utilise des registres publics et privés sans imposer explicitement la priorité du registre privé est exposé à cette attaque. Demandez-lui s’il a vérifié que ses noms de paquets internes ne sont pas enregistrés par des tiers dans les registres publics.
- Demandez si le fournisseur utilise des registres privés et publics, et comment la priorité de résolution est configurée
- Demandez si les noms de paquets internes ont été réservés dans les registres publics
- Interrogez les tests de confusion de dépendances dans l’environnement de build
- Intégrez la configuration des registres à l’évaluation de la sécurité des builds
Ce qu’il faut exiger
Demandez directement :
« Utilisez-vous des registres de paquets privés en plus des registres publics dans votre environnement de build, et comment vous assurez-vous que les paquets privés sont résolus en priorité afin d’empêcher les attaques par confusion de dépendances, dans lesquelles un paquet public de version supérieure supplante vos paquets internes ? »
Preuves attendues
- Documentation de la configuration de la priorité des registres
- Réservation des noms de paquets internes dans les registres publics
- Résultats des tests de confusion de dépendances
- Isolation de l’environnement de build vis-à-vis des accès au réseau externe
Il faut interroger précisément un fournisseur qui affirme appliquer des pratiques de build sécurisées sur l’atténuation de la confusion de dépendances. La sécurité de l’environnement de build comprend la configuration des registres, et pas seulement la revue de code et l’analyse statique.
Comment le prouver
- Audit de la configuration de la priorité des registres
- Vérification de la réservation des noms de paquets internes
- Registres des tests de confusion de dépendances
- Normes de configuration des environnements de build
À retenir
Nom du paquet interne : dans une offre d’emploi. Registre public : l’attaquant a enregistré le même nom, avec une version plus élevée. Système de build : il a résolu le paquet public. 23 applications : le code de l’attaquant a été exécuté pendant l’installation des dépendances. Aucune vulnérabilité exploitée. Aucune revue de code contournée. Le mécanisme de résolution a fait ce pour quoi il était configuré. Imposer la priorité du registre privé l’empêche : le paquet privé est résolu en premier, quel que soit le numéro de version. Réserver le nom dans les registres publics l’empêche : l’attaquant ne peut pas enregistrer un paquet portant un nom que l’entreprise détient déjà. Ce sont deux décisions de configuration, pas des refontes architecturales.