Binary Dependencies: Identifying the Hidden Packages We All Depend On

Binary Dependencies: Identifying the Hidden Packages We All Depend On

On 31 Jan 2026, I gave a talk at FOSDEM 2026 on phantom binary dependencies — packages that we depend on in binary form, even though these dependency relationships are invisible to us. If we cannot reliably identify these phantom dependencies, the sustainability and security of our tech infrastructure will be at risk, which threatens critical services such as hospitals, transportation and the internet.

You can watch my talk on this page, and I’ve included more details below, as well as a list of resources for those who want to learn more about this topic.

Abstract

When you create a software package, your work might depend on other packages. Usually, you will depend on the source code of these other packages. However, sometimes, you will depend on precompiled binaries of your dependencies. This frequently happens when calling compiled code, like C code, from other programming languages, such as Python.

In almost all ecosystems, it is difficult to keep track of binary dependencies. When you depend on a package’s source code, this is normally recorded in your manifest file — pyproject.toml, package.json and so on. However, when you depend on a package’s precompiled binaries, this information is usually not recorded anywhere. This means that the binary dependency relationship between your project and whatever you’re depending on is hidden — so we can say that you have a phantom binary dependency.

Why are phantom binary dependencies important? For at least two reasons:

Sustainability. Keystone maintainers struggle to get paid because of the Open Source sustainability crisis, which makes them more vulnerable to burnout. Projects like the Open Source Pledge, the Open Source Endowment, and thanks.dev help maintainers get paid. But we have to know which maintainers we depend on to be able to pay them. If we cannot identify our binary dependencies, we cannot identify which maintainers we should support, which puts the sustainability of the Open Source ecosystem at risk, threating our global tech infrastructure.

Security. If your project depends on a library, any security issues in that library will leave your project vulnerable. If you don’t have a clear picture of which libraries you depend on, you won’t have a clear picture of security vulnerabilities that might affect you, which puts your project at risk. For software that supports critical infrastructure like hospitals, transportation systems, and the internet, this vulnerability puts the public at risk of harm.

There are tools we can build, and systemic changes we can make to our package management ecosystems, that will correct these issues, though this will be a lot of work. In my talk, I sketch the beginnings of a solution.

I believe we should start by creating tools that can identify and record binary dependencies for a wide variety of packages, giving maintainers, security researchers, and other parties the information they need to figure out more robust solutions.

Once we have this information, we can work on other aspects of the problem. How can we made sure that binary dependencies are always sourced from the appropriate package managers, instead of being merely vendored, so that they can be kept up to date with security patches? How can we make sure that language package managers and system package managers interoperate to warn developers of security issues across the entire dependency graph?

I’m actively involved in this work, and there are many conversations happening around these questions. If you’re interested, here are some resources to help you learn more and/or get involved!

Other Resources

• The bindep repository is where I keep my work-in-progress code and notes.
• The Open Source Pledge is an initiative aiming to get companies to pay the Open Source maintainers whose work they depend on.
• The C-Shaped Hole in Package Management by Andrew Nesbitt.
• Dependency Resolution in Python: Beware The Phantom Dependency by Anand Sawant.
• auditwheel, a widely-used Python package that can identify a wheel’s required dynamic libraries.
• elfdeps, a lesser-known Python package that can identify a wheel’s required dynamic libraries and has a public API.
• PEP 770, PEP 725, and PEP 804, which specify ways to record and map binary dependencies.
• ESSTRA, a tool developed at Sony that aims to improve supply chain transparency.
• Fromager, a tool that aims to provide a way for Python packages to be built completely from source.