Find the risk hiding in your project's dependencies

When you run npm install or pip install, you are pulling in code other people wrote and running it as part of your project. Each package you ask for is a dependency. But almost none of them stand alone: the package you wanted has its own dependencies, and those have theirs, down several layers. Those deeper ones, the packages you never named but that got installed anyway because something you did name needs them, are your transitive dependencies. A small project that lists three packages can easily end up with a hundred on disk.

That is the whole point of a package ecosystem, and also its risk. You did not write any of that code, you rarely read it, and yet it runs with the same access your own code has. If one package in that tree has a security flaw, or is replaced by a hostile version, the weakness is now yours, whether or not you ever knew the package was there. This is supply-chain security: the chain of trust that runs from your project through every package it depends on, direct or transitive, and every author and build server behind them.

The flaws come in two shapes, and this mission covers both. The first is a known vulnerability: a published, catalogued flaw in a specific version of a real, legitimate package, the kind an audit tool can look up. Each one usually has a CVE id (Common Vulnerabilities and Exposures, a global free catalogue, with ids like CVE-2023-32681) and often an ecosystem-specific advisory id too: a GHSA id for the GitHub advisory, or a PYSEC id for the Python one. An audit tool reads the exact versions you have installed and tells you which carry a known advisory and which version fixes it.

The second shape is a malicious package: code that is harmful on purpose. The most common delivery is a typosquat, a package with a name one keystroke away from a popular one, hoping you mistype or copy a bad instruction. A related trick is dependency confusion, where an attacker publishes a public package with the same name as one of your company's private internal packages, betting your installer will prefer the public one. Step 5 and step 6 are about spotting both before anything runs.

There is one more fact worth knowing up front, because it is why a bad package is so dangerous: installing a package can run code. npm packages may define postinstall and similar scripts that execute automatically the moment you install them, before you have run a single line of your own code. So "I only installed it, I never used it" is not the safety people assume. Step 6 shows how to turn that off.