What Is Open Source Supply Chain Risk? AI Startups Explained

What is open source supply chain risk?

Open source software supply chain risk is the danger that a company, or an entire industry, depends on code maintained by too few people with too little money, so that one burnout, one bad actor, or one unpaid bill can break production systems nobody thought were fragile. That risk just got a very expensive spotlight.

Why is an $870M round sitting on code nobody is paying for?

In October 2026, TypeSafe AI raised roughly $870 million led by Andreessen Horowitz at a $7.5 billion valuation, months after launching its "Jev" model and only weeks after its initial public debut. The company was founded in 2024 by Diogo Almeida, a former OpenAI researcher who co-invented the RLHF techniques behind ChatGPT, along with Erik Gafni and Sasha Sheng, and had previously closed a $40 million seed round led by DCVC.

That is a lot of capital moving fast. It is also beside the point. TypeSafe AI, like essentially every AI company raising money right now, runs on a stack of inference engines, compression libraries, and JavaScript tooling that it did not build and does not fund. Pull back far enough and almost all of modern software, AI or otherwise, rests on the same foundation: open source projects that are free to use and often maintained by one or two people in their spare time. The $870 million did not go to them.

What does "open source supply chain risk" actually mean?

The term sounds abstract until you break it into three plain ideas:

• Dependencies. Almost no modern application is written from scratch. It imports libraries, which import other libraries, forming a dependency tree that can run hundreds or thousands of packages deep.
• Maintainers. Each of those packages has to be maintained by somebody: patched for bugs, updated for compatibility, reviewed for security. Many of the most-used ones are maintained by volunteers, not employees.
• Bus factor. This is the number of people who would need to quit, burn out, or disappear before a project stalls. A low bus factor means the whole dependency, and everything built on it, hinges on very few individuals.

When the bus factor is low on a widely used package, that single point of failure does not stay contained. It cascades outward into every company, product, and billion-dollar valuation sitting on top of it.

How big is the 2-person problem, by the numbers?

This is not a fringe scenario. It is close to the default condition of open source infrastructure.

Tidelift's 2024 maintainer survey found that 60% of open source maintainers describe themselves as unpaid hobbyists, with only 12% earning most or all of their income from the work. A separate analysis of that data found that unpaid maintainers are especially likely to be working alone, with 61% maintaining their projects entirely by themselves.

That solitude shows up structurally, too. Researchers who computed the "truck factor" of 133 popular GitHub projects found that 46% had a truck factor of exactly 1 and another 28% had a truck factor of 2, meaning roughly three-quarters of well-known open source systems depend on the continued availability of one or two people.

Put those numbers together and the picture is stark: most of the free software your company's AI stack runs on is maintained by someone who is not being paid for it, working alone, and one life event away from stopping.

What happens when it breaks, from xz to left-pad to Shai-Hulud?

This isn't hypothetical. It has already happened, repeatedly.

The clearest case is the xz-utils backdoor, tracked as CVE-2024-3094 and discovered in March 2024. XZ Utils is a compression library present on the vast majority of Linux servers worldwide, and for most of its life it had exactly one maintainer, Lasse Collin. Beginning around 2021, an attacker using the persona "Jia Tan" spent roughly two years building trust with Collin, eventually gaining commit access and making at least 450 commits to the project before quietly inserting a backdoor into SSH authentication. It was caught before wide deployment, but only by chance, when a Microsoft engineer noticed unusual CPU usage.

The pattern is older than that. In 2016, a developer unpublished left-pad, an 11-line npm package, after a naming dispute. Its removal instantly broke builds across thousands of JavaScript projects, including tooling used by Babel and React, within hours. Eleven lines of code breaking that much of the modern web was the first widely visible proof of how deep and brittle the dependency graph of modern software had already become, nearly a decade before anyone was talking about AI supply chains.

This keeps happening, not as an isolated event but as a pattern. In September 2025, CISA issued a nationwide alert over "Shai-Hulud," a self-replicating worm that compromised more than 500 npm packages by harvesting developer credentials and automatically publishing malicious versions of trusted libraries. The same month, a separate attack hit 18 extremely popular npm packages, including chalk and debug, which collectively see more than 2 billion downloads per week, inserting code designed to intercept cryptocurrency transactions in victims' browsers. Any company that treats open source like a licensed vendor relationship instead of something it owns and audits is one hijacked account or one bad update away from the same exposure. It's the exposure platform-dependent businesses face when an API partner changes the rules without warning, as detailed in the C&D epidemic hitting companies built on borrowed platform access.

How did the AI boom make it worse, not better?

AI did not create this fragility. It is straining it from two directions at once.

The first is volume. Daniel Stenberg, the founder and lead maintainer of curl, shut down the project's long-running bug bounty program after AI-generated "slop" vulnerability reports overwhelmed the volunteer-run security review process. curl had paid out more than $100,000 across 87 confirmed vulnerabilities before the program became unsustainable to run. Stenberg put it bluntly: "A threshold has been reached. We are effectively being DDoSed. If we could, we would charge them for this waste of our time." The same AI tools that help companies ship faster are flooding the maintainers underneath them with noise.

The second is money chasing infrastructure that was never built to hold it. vLLM, the open source inference engine that much of the AI industry relies on for cost-efficient model serving, was reportedly in talks in December 2025 to raise at least $160 million at around a $1 billion valuation, despite having banked only about $300,000 to date and having no business model beyond donations. Readers who have already weighed the enterprise case for running inference locally instead of renting it will recognize the irony: the infrastructure making self-hosting viable is itself under-capitalized.

Meanwhile, Peter Steinberger, creator of the viral open source AI agent project OpenClaw, which drew 201,000 GitHub stars in weeks, personally absorbed between $10,000 and $20,000 a month in AI API costs just to keep his "free" project running. His infrastructure bill was trivial. The API spend was not. Even wildly successful open source AI tools can bankrupt their creators while generating enormous value for everyone downstream.

Why is nobody capitalizing the $8.8 trillion asset?

There is a reason venture capital keeps circling this terrain. A Linux Foundation and Harvard study estimated that widely used open source software carries a "demand-side" value, meaning what it would cost companies to rebuild it themselves, of $8.8 trillion. The cost to actually create that software in the first place was only about $4.15 billion. The same research found that 96% of that enormous demand-side value is generated by just 5% of contributors.

That is the economic absurdity underneath TypeSafe AI's $870 million round, vLLM's reported $1 billion talks, and every other AI valuation built on top of libraries maintained for free. The value is trillions. The people producing it capture almost none of it. Venture capital has started racing to formalize ownership of the upside while the underlying labor stays uncapitalized.

What should organizations do about open source supply chain risk?

Treating open source as free, as in cost, rather than free, as in freedom, is how companies end up exposed. A more honest posture looks like this:

1. Audit the bus factor of critical dependencies. Know which libraries in your stack have one or two maintainers, not just which ones have the most stars.
2. Fund maintainers directly. Tidelift, GitHub Sponsors, and the Open Source Security Foundation all give companies a way to pay for the infrastructure they already depend on, rather than extracting it for free.
3. Treat SBOMs as mandatory, not optional. A software bill of materials is the only reliable way to know what you are actually running when an incident like the xz backdoor or the Shai-Hulud worm surfaces.
4. Build in redundancy where you can. The same logic that pushes enterprises toward owning their AI models instead of renting an API, as the local-first case against renting your stack lays out, applies to critical open source infrastructure: know what you would do if a key dependency went dark tomorrow.
5. Stop pretending the state has no role here. Germany's Sovereign Tech Fund is already putting public money into unglamorous Linux plumbing like package managers, treating it as a security strategy rather than charity, a model more enterprise IT budgets are starting to copy.

TypeSafe AI's $870 million says the market believes AI infrastructure is worth building fast and funding heavily. The maintainers underneath it, working alone, unpaid, fending off AI slop and backdoor attempts, are the reminder that nobody has figured out how to fund the right layer yet.