BekahHW
4 mins read
"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."
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.
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.
So, what can we do with this new understanding? Here are three key actions:
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.
Bekah graduated from a coding bootcamp in May of 2019 and since then has spent time as a frontend developer, started the Virtual Coffee tech community, spent time in DevRel and has continued to mom her four kids. She currently co-hosts the Compressed.fm and Virtual Coffee podcasts, lifts heavy things in her free time, & works as the Developer Experience Lead at OpenSauced.
Recent Posts
BekahHW
6 mins read
Understand the important role of transparency in open source through the PearAI and Continue.dev case study.
#pizza-cli
BekahHW
6 mins read
Discover the hidden costs of siloed knowledge in developer culture and how embracing shared ownership and tools like the CODEOWNERS file can enhance t...