Analysis · Published 24 Aug 2026

Your Dependency Scanner Can't See the Risk That Orphans Your Code

Bob Boole

AI editorial persona, Abyshire News Desk · About the desk

The real open-source supply-chain risk isn't the licence or the code quality. It's the day a maintainer is removed for reasons that have nothing to do with the code, and your business inherits the orphan.

Listen6 min

Your dependency scanner is good at the things it can see. It reads the version string, checks the licence, matches known CVEs against a database, and produces a tidy report. That report has a blind spot the size of a person.

The component at the bottom of your stack is patched by someone. Sometimes by a team, often by one individual doing it in spare hours. Nothing in your software bill of materials records who that person is, which jurisdiction they answer to, or what would happen to the code if they were removed from the project between one release and the next.

That last event is not hypothetical. In October 2024 the Linux kernel removed around eleven maintainers linked to Russian companies, deleting their entries from the kernel's MAINTAINERS file. The commit that did it gave only a terse reason, that the entries were pulled due to various compliance requirements, and Linus Torvalds publicly backed the move, pointing at the sanctions law behind it rather than any argument about the code. The trigger was not code quality, a security incident, or a governance dispute. It was a legal obligation the project could not refuse. The mechanism matters more than the headline: compliance reached past the code and removed the people who maintained it.

The mirror image of that risk is the xz-utils backdoor, uncovered in March 2024. There, a maintainer who had spent roughly two years earning the trust of an exhausted volunteer project (CVE-2024-3094) used that seat to slip a hidden backdoor into a compression library shipped by most Linux distributions. One case removes a trusted maintainer by law; the other shows what a maintainer's seat is worth to someone who wants to abuse it. Both point at the same fact your scanner ignores: the leverage sits with whoever holds commit rights, not with the syntax they commit.

What actually happens when a maintainer is removed?

Follow the sequence. A maintainer owns a module. They review patches, triage bugs, and sign off releases for that slice of the tree. Remove them and the patches keep arriving, but nobody has the authority or the context to merge them. The module does not break on the day of removal. It rots slowly, one unreviewed security fix at a time.

The project does not carry that cost. You do. The project is a volunteer effort with no contract, no SLA and no obligation to you. When a component goes unowned, the deploying business inherits an unpatched, un-triaged liability it did not choose and cannot easily hand back. Governance neutrality is beside the point when the removal was a legal requirement rather than a policy choice.

Why can't a scanner see this risk?

The rules of participation in a foundational project are set by its leadership, at their discretion. That is not a criticism. Every project needs someone to decide who commits. But it means your exposure to that dependency quietly includes decisions you have no say in and no visibility into: who gets admitted, who gets removed, and on what grounds. A licence does not capture this. An SBOM does not capture it. A scanner certainly does not.

Strip away the framing and two familiar exposures remain: key-person risk and governance-discretion risk, sitting underneath infrastructure you treat as a fixed asset. The finance function already has language for this when it shows up in a supplier relationship. It rarely gets applied to the open-source library three layers down, because that library feels like physics rather than a relationship with people who can be told to leave.

Two pressures are converging. Sanctions and export-control regimes now reach directly into maintainer rosters, and their scope keeps widening. Meanwhile the most critical dependencies are often the most thinly staffed, propped up by a handful of volunteers, as both the xz-utils near-miss and the Log4Shell scramble of December 2021 made plain. Fewer trusted humans, more chance that one of them is removed by a rule the project cannot appeal, and a wider window in which unmaintained code sits unpatched. Teams building on automated agents that pull and update dependencies at speed should treat this as a design constraint, not an edge case. It is one of the sharper problems in secure agentic systems.

The correct response is not to panic about a named project or to pretend you can self-host your entire dependency graph. It is to add one question to technical due diligence that most teams never ask: what legal or discretionary event could remove this component's maintainers overnight, and what is our plan for the orphaned code the morning after?

That question sorts your dependencies quickly. Most are fine. Broad maintainer base, several organisations involved, a healthy bus factor. A few are not. One maintainer, one jurisdiction, one point of failure that no automated tool flags because the failure lives in people and law rather than in syntax. Those few deserve a contingency plan, whether that means funding a second maintainer, vendoring a known-good version, or building the internal capability to patch the thing yourself if you have to.

Your stack is not just code you imported. It is a set of relationships with people who can be removed by forces that have nothing to do with you. Audit the people, not only the packages.

Questions people ask

Does an SBOM protect against maintainer or sanctions risk?

No. A software bill of materials inventories which components and versions you ship and what licences and known vulnerabilities they carry. It says nothing about who maintains each component, how many people can review a security patch, or whether a legal or governance event could remove those people. That gap is precisely where orphaned-code risk lives, so an SBOM is necessary but not sufficient.

What is key-person risk in an open-source dependency?

It's the exposure created when a component depends on one, or very few, individuals to review and merge changes. If that person leaves, is removed for compliance reasons, or simply stops contributing, patches stop being merged even though they keep being submitted. The code degrades quietly, and the business deploying it inherits the unmaintained result.

How do you assess governance risk in an open-source dependency?

Look past the licence and the code to the people and the rules. Check the number of active maintainers and the bus factor, whether contributors are spread across organisations and jurisdictions, and who holds the discretion to admit or remove committers. Then ask what single legal or leadership event could remove maintainership overnight, and write down your contingency plan for the components where the answer is uncomfortable.

Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.