Attacking a well-defended organisation directly is expensive. Compromising something that organisation installs automatically is far cheaper, which is why dependencies have become a primary target.
Applications are mostly other people's code
A typical application written today includes a small amount of original code and a large amount of imported libraries, each of which imports further libraries of its own.
The resulting tree is often hundreds of packages deep, and most of them were never chosen deliberately. They arrived as dependencies of dependencies.
Every one of those packages executes with the same privileges as the application, which means a single compromised entry has the reach of the whole program.
Trust is inherited without inspection
Package managers install what a project declares and everything that declaration implies. Reviewing all of it is impractical for any team of ordinary size.
Popularity is used as a proxy for safety, but popularity measures how many projects depend on something, not how carefully it is maintained.
Many widely used components are maintained by one unpaid person, which makes them both critical and structurally fragile.
Maintainer accounts are the easiest route
Publishing a malicious version usually requires control of a maintainer account rather than any flaw in the code itself.
Attackers obtain that control through stolen credentials, or by offering to help with an abandoned project and being granted publishing rights.
Requiring a second factor for publishing and signing releases raises the cost of this route considerably, which is why registries have moved to enforce it.
Build systems are a second entry point
Even where source code is clean, the machinery that compiles and packages it can be altered so the published artefact differs from what the repository contains.
Because most users install the artefact rather than building from source, such a change can persist without appearing in any code review.
Reproducible builds address this by letting independent parties compile the same source and confirm they get an identical result.
Inventory is the practical defence
An organisation that does not know which components it ships cannot answer whether it is affected when a compromise is announced.
Maintaining a dependency inventory turns that question from a multi-day investigation into a lookup, which matters when the window for response is short.
Pinning versions, reviewing what updates bring in and reducing the total number of dependencies all shrink the surface, though none removes it entirely.