Lorsque vous installez une bibliothèque JavaScript, elle vient généralement avec des centaines de dépendances transitives, c'est à dire des bibliothèques qui sont installées par effet de bord car elles sont indispensables au fonctionnement de la bibliothèque que vous souhaitez utiliser.
Cette prolifération des dépendances ouvre la porte aux supply chain attacks. Il suffit que l'un des dépôts hébergeant l'une de ces centaines de bibliothèques, ou que l'un des mainteneurs soit malveillant, et il devient possible d'injecter des logiciels malveillants dans le vôtre, qui peuvent vous cibler, vous ou votre organisation, et même les utilisateurs et utilisatrices finaux de vos logiciels.
Comme je l'expliquais déjà en 2018, l'écosystème PHP est relativement moins sensible à ce type d'attaques que celui en JavaScript, car les mainteneuses et mainteneurs des bibliothèques et frameworks populaires font relativement attention à ne pas dépendre de trop de dépendances tierces, ce qui limite le problème... mais ne l'empêche pas totalement pour autant.
Et si l'on pouvait faire mieux grâce à notre logiciel de gestion de bibliothèques préféré : Composer ? Au cours de ce talk, je présenterai - exemple à l'appui - comment fonctionnent les attaques de la chaînes logistique, puis j'ébaucherai quelques méthodes organisationelles qui pourraient limiter le soucis, et finalement je vous montrerai comment reprendre le contrôle total de votre dossier vendor/ grâce à un plugin Composer que je publierai pour l'occasion.
