"How many humans could screw up my dependency graph?"

This question, posed by Jordan Harband, provides a different perspective on open source security. In a recent episode of DevTools FM, Harband challenges the traditional metrics we use to evaluate open source security, suggesting that we've been looking at the wrong numbers all along.

We talk a lot about metrics, and what measures success in open source, but we often overlook the human element. Harband reminds us that behind every package, every line of code, there's a human being. When it comes to open source security, it's not about how many packages you're using—it's about how many people could potentially mess them up; it's about the "Human Dependency Graph."

The Problem with Counting Packages

Our fixation on easily quantifiable metrics like package counts mirrors a broader issue in open source: the tendency to prioritize speed over security. Sometimes we see a project with fewer dependencies and assume it's more secure. But that's not necessarily true. What if there's a high number of YOLO Coders pushing code directly to the main branch? What if the maintainers of those few packages are burnt out? What if those projects aren't following best practices?

Harband likens this obsession to outdated thinking from decades ago—"an absurd thing to care about." After all, what does the number of packages really tell you about the security of your project?

Harband's argument flips traditional understanding on its head. He argues that a company with 10,000 internal developers might actually be at greater risk than a project relying on 100 external open source maintainers. Why? Because each person with access to the code is a potential point of vulnerability, not because they're malicious, but simply because they're human and capable of making mistakes. Instead of simply counting packages or contributors, we need to evaluate the expertise, reliability, and interconnectedness of the human network behind our code.

However, we need to consider another factor here: the lottery factor. This concept suggests that a project becomes vulnerable if a small number of contributors (typically 2 or fewer) account for more than 50% of the contributions. So while having fewer maintainers might seem safer, it's not that simple. The ideal scenario balances a small group of supported and highly skilled maintainers to prevent over-reliance on any single individual. This view is at the heart of understanding the Human Dependency Graph.

The Real Threat: Focusing on the Wrong Metrics

Metrics like package size, issue count, and star rating, might seem to tell a clear story, but in reality can mislead us. Harband points out a startling possibility: "Somebody will make a package that's like 1K smaller solely so they can take over your supply chain."

In other words, if we remain laser-focused on reducing package size or maximizing star count, we could be opening ourselves up to security risks rather than mitigating them. The numbers we've been relying on don't just miss the point—they might be actively leading us astray.

A Call to Action: Focus on the Humans, Not the Packages

So, what can we do with this new understanding? Here are three key actions:

1. Map Your Human Dependency Graph: Start identifying who maintains the packages you rely on. Know the people behind the code—their track records, their reputations, and their patterns of contribution. (Check out our Repo Pages for your dependencies to identify maintainers.)
2. Build Relationships, Not Just Dependencies: Cultivate connections with the maintainers of your critical packages. Open source survives with community and trust, and being an engaged part of that community can help you reduce your security risks. (Learn how to make that process easier by creating a Workspace from SBOM.)
3. Shift Your Focus from Package to Publisher Count: Instead of worrying about how many packages you're using, think about how many maintainers have access to them. This shift in thinking helps you prioritize real risks and can make your projects more resilient in the face of threats.

The Big Picture: Evolving Our Thinking on Open Source Security

As the open source ecosystem has grown, the metrics that mattered years ago might no longer apply. Just as we've had to rethink what constitutes valuable contributions in the age of GitHub, we also need to rethink what constitutes security.

Jordan Harband's idea of the Human Dependency Graph challenges us to look beyond what's easy to measure and to think critically about what we should really care about. After all, in a world where a single human can introduce significant vulnerabilities into a project, the numbers that matter most aren't the ones you might think.