The hidden iceberg of software dependencies

You know your app's direct dependencies. The ones listed in your package.json, requirements.txt, or Cargo.toml. But what about the packages those dependencies depend on? And their dependencies? It's dependencies all the way down.

A new project called Binary Dependencies aims to expose this hidden layer. It scans millions of open-source repositories and identifies the most common transitive dependencies—the ones that almost no developer explicitly chooses, but nearly every project relies on.

What the data shows

Binary Dependencies analyzed over 10 million GitHub repositories. The results are sobering. A handful of packages appear in more than half of all projects. Things like lodash, chalk, ansi-styles, and supports-color are everywhere. They're so ubiquitous that developers rarely think about them.

But here's the kicker: many of these packages are maintained by a single person or a tiny team. A single maintainer burnout or security vulnerability in one of these could ripple across the entire ecosystem. Remember the left-pad incident? That was just one package. Imagine if lodash went rogue.

Why this matters

For security teams, this is a goldmine. You can't patch what you don't know you have. Binary Dependencies gives you a map of your true attack surface. For developers, it's a humbling reminder that your "custom" application is 90% someone else's code.

"It's like discovering your house is built on a foundation of borrowed bricks," says one developer who tested the tool. "And you have no idea who made those bricks or if they're structurally sound."

How it works

The tool works by analyzing binary packages—the compiled versions distributed via npm, PyPI, and other registries. It doesn't just look at source code; it inspects the actual bytes that get installed. This catches dependencies that might be dynamically loaded or injected at build time.

It creates a dependency graph that shows not just direct relationships, but the weight of each dependency across the entire ecosystem. You can see which packages are the most "central"—the ones that, if removed, would break the most projects.

The cynical developer take

Of course, some developers are skeptical. "Great, another tool that tells me what I already know," one commenter on Hacker News wrote. "My project has 1,200 dependencies. What am I supposed to do about it? Rewrite everything from scratch?"

It's a fair point. The reality is that modern software development relies on this vast, invisible network. We can't unring that bell. But we can be more aware of the risks. Binary Dependencies doesn't claim to solve the problem—it just shows you the problem more clearly.

What you can do

If you want to check your own projects, the tool is open-source and available on GitHub. You can run it against your package-lock.json or yarn.lock to see your hidden dependency tree. It'll show you the packages you never knew you had.

Some practical steps:

  • Pin your dependencies to specific versions. Don't let transitive deps float.
  • Use tools like Dependabot or Snyk to monitor for vulnerabilities in transitive deps.
  • Consider whether you really need that 10KB utility library. Sometimes a built-in function does the job.

The bigger picture

Binary Dependencies is part of a growing movement toward supply chain security. After the SolarWinds attack and countless npm incidents, the industry is waking up. We can't keep pretending that our apps are self-contained.

The project's creator sums it up: "We built this because we wanted to know what we're actually running in production. The answer was scary. Now we're sharing that fear."

Is it perfect? No. Does it cover every language? Not yet. But it's a start. And for a developer community that's been flying blind, any visibility is welcome.