When you install a JavaScript library, it usually comes with hundreds of transitive dependencies, i.e. libraries that are installed as a side effect because they are essential to the operation of the library you want to use.
This proliferation of dependencies opens the door to supply chain attacks. All it takes is for one of the repositories hosting one of these hundreds of libraries, or one of the maintainers, to be malicious, and it becomes possible to inject malware into yours, which can target you or your organization, and even the end users of your software.
As I explained back in 2018, the PHP ecosystem is slightly less susceptible to this type of attack than the JavaScript ecosystem, because maintainers of popular libraries and frameworks are relatively careful not to rely on too many third-party dependencies, which limits the problem... but doesn't totally prevent it though.
What if we could do better with our favorite library management software: Composer? During this talk, I present how supply chain attacks work, outline some organizational methods that could limit the problem, and finally, explain how to take back full control of your vendor/ folder thanks to a Composer patch I crafted for this occasion.