Most of the code shipping in a modern application was written by people the team will never meet, arriving through a dependency tree several levels deep. That is a reasonable trade and it is rarely made deliberately. Managing open-source dependency vulnerabilities starts by acknowledging that you own the security and the maintenance of everything you ship, regardless of who wrote it, and that the transitive dependencies nobody chose are the bulk of it.
Know what is actually in the build. A dependency file lists what you asked for; a lockfile records what you got, including everything pulled in indirectly, and it is the only accurate answer to what is deployed. Generating a bill of materials during the build and keeping it with the artefact turns 'are we affected by this advisory' from an afternoon of investigation into a query. Teams that cannot answer quickly end up patching speculatively every time a vulnerability makes the news.
Pin versions and update on a schedule. Floating version ranges mean the build is not reproducible and that a compromised release can arrive with no change on your side. Pinning with a lockfile, combined with a regular cadence of small updates, is more work per week and much less work per year than the alternative - a system frozen for two years, then an urgent security fix requiring several major version jumps at once, under pressure, with no time to test.
Judge advisories in your own context, because most of them do not apply to you. A vulnerability in a code path your application never calls, or one requiring an attacker to control input you never pass, is not the same risk as one sitting in your request-handling path. Scanners cannot make that distinction and report everything at the severity the publisher assigned. Treating all of it as urgent is what trains engineers to close the tab, and after that the genuine finding gets missed too.
Evaluate a dependency before adopting it rather than after an incident. The questions are unglamorous: is it maintained, how many people can publish a release, how quickly have security issues been handled before, how large is its own dependency tree, and how hard would it be to remove later. A small package doing something you could write in an afternoon, while pulling in twenty transitive dependencies, is a poor trade however convenient its interface.
The supply chain includes the build, not only the libraries. Continuous integration systems execute code from dependencies with credentials attached, and an install-time script is code running inside your pipeline. Restricting what runs at install time where the ecosystem permits it, limiting the permissions available to build jobs, and keeping publishing credentials out of ordinary build environments closes the path that matters most - and receives far less attention than library versions do.
The position worth stating plainly is that dependency management is maintenance which never finishes and never produces a visible feature, so it loses every prioritisation argument unless somebody protects time for it. A standing allocation, with an owner, costs less than the emergency it prevents. Teams that update only when an auditor or an incident forces them are choosing to do the same work later, worse, and on somebody else's schedule.
