Most of your software is code you didn't write — and that's the attack surface

You choose ten. You ship eighty.

On a typical npm project you pick around ten direct dependencies. Your build installs more than eighty — a transitive multiplier of roughly 7.5–10×, with dependency trees about 4.4 levels deep; web frameworks can push that to 50–100×. Python is leaner — around six direct, 15–20 installed, trees under two levels deep — but the shape is the same: the majority of the code you ship is code you never chose, and never read.

The surface scaled — and so did the threat

• 454,648 malicious npm packages were identified in 2025; over 99% of all open-source malware now targets npm.
• Supply-chain attack costs are projected to climb from roughly $60B to $138B between 2025 and 2031.
• At trillions of registry downloads a year, manually reviewing what enters a build simply doesn't scale.

Why the old defenses lag

Most controls were built for a different threat model. CVE databases catalogue yesterday's known-bad. Reputation and provenance assume an honest publisher. Lockfiles guarantee you install the same bytes — even when those bytes are malicious. None of them answer the question that actually matters at install time: what is this going to do?

Where the field is heading

Security research keeps converging on the same idea: complement static review with dynamic, behavioral analysis — watching what a package does when it runs — and use models to help reason about it. One honest caveat from that work is worth keeping: automated systems are strong at the high-level call (benign vs malicious) and weaker at pinpointing the exact malicious indicator, so the quality of the verdict and its explanation matters as much as the detection itself.

Securing a dependency tree means watching behavior, not just vetting names.

That's the bet depgaze is built on.