Essay · 2 min read
Your dependency tree is your real attack surface
You reviewed the code you wrote. The code you didn't write is most of what you ship.
By Kyeson Blake Utley ·
Pick any modern web project and count what it actually runs. The code the team wrote is usually a small fraction. Underneath sit hundreds of open-source packages, most of them pulled in as dependencies of dependencies that nobody on the team chose directly.
Every one of those packages runs with the same privileges as your own code. If one is compromised, so are you.
How the attacks actually arrive
Supply-chain compromises rarely look like a dramatic breach. They arrive as routine maintenance: a version bump, a new transitive dependency, or a maintainer account that changed hands. The patterns repeat:
Account takeover. An attacker phishes or buys a maintainer's credentials and publishes a malicious version of a popular package. Every project with a loose version range pulls it in on the next install.
Typosquatting. A package with a name one keystroke away from a popular one waits for someone to mistype an install command.
Install scripts. Many package managers run scripts at install time, so the malicious code executes on developer machines and build servers before the application ever starts. That's where the cloud credentials and signing keys live.
Every package runs with the same privileges as your own code. If one is compromised, so are you.
What actually reduces the risk
Pin and lock. Commit lockfiles and install from them in CI. A lockfile turns "whatever is newest" into "exactly what we reviewed."
Make updates deliberate. Automated update pull requests are good. Merging them unread is not. Look at what changed, especially new install scripts or new network calls.
Shrink the tree. Every dependency you remove is one you never have to trust again. A twenty-line utility rarely justifies a package with its own dependency chain.
Isolate the build. Build systems shouldn't hold long-lived production secrets. Use short-lived credentials so a poisoned install can't walk away with the keys.
Keep an inventory. A software bill of materials tells you, within minutes of the next big advisory, whether you're affected. Without one, you find out by grepping under pressure.
When I audit a codebase, the dependency review often finds more risk than the application code. That's not a failure of the team. It's where the risk has moved.
