In April 2024, a Microsoft engineer named Andres Freund noticed SSH logins on Debian testing were running 500 milliseconds slower than they should. That small anomaly led him to CVE-2024-3094 — a backdoor planted in xz-utils, a compression library that ships in nearly every Linux distribution on earth. The person who planted it had spent over two years building trust as a co-maintainer, because the sole maintainer, Lasse Collin, had been running the project alone, unpaid, while also dealing with mental health struggles he'd written about publicly. Xz-utils wasn't an obscure toy project. It was critical infrastructure, maintained on nights and weekends by one volunteer. That gap — between how critical a dependency is and how well its maintenance is resourced — is not an edge case. It's the default condition of open source. So what would it actually cost to close it? The numbers are more concrete, and more answerable, than most companies assume.
How much would it cost to properly fund the internet's most critical open source projects?
Somewhere in the tens of millions of dollars a year — which sounds enormous until you compare it to what a single breach costs. The Linux Foundation and Harvard's Laboratory for Innovation Science ran the "Census II" study in 2020, mapping the most depended-upon free and open source components in production software. It found that a relatively short list of packages — often maintained by one or two people — sit underneath a staggering share of commercial and government software. When OpenSSF launched the Alpha-Omega Project in February 2022 specifically to fund security work on the most critical open source projects, Microsoft and Google put up $5 million each to start — $10 million total, later joined by additional contributors. That's not hypothetical spend; it's what two companies decided the problem was worth on day one, and it was still described by the foundation as a down payment, not a solution.
What has it cost companies when they didn't fund maintenance?
Hundreds of millions of dollars, repeatedly, in incidents that were traceable directly to under-resourced maintainers. Before Heartbleed was disclosed in April 2014, OpenSSL — the encryption library securing a huge share of the world's HTTPS traffic — was, according to project lead Steve Marquess's own public account, running on donations of roughly $2,000 a year with essentially one full-time developer. Remediation estimates for Heartbleed across affected businesses ran into the hundreds of millions of dollars once you count patching, certificate reissuance, and incident response labor industry-wide. Within weeks, the Linux Foundation launched the Core Infrastructure Initiative, with companies including Microsoft, Google, IBM, Amazon, Cisco, and Intel each pledging around $100,000 a year for three years — roughly $3.9 million annually pooled from an industry that had, until the breach, let the project run on pocket change. Log4Shell followed the same script in December 2021: a handful of unpaid volunteers on the Apache Logging Services team maintained software embedded in an estimated hundreds of millions of Java applications, and organizations worldwide spent months on emergency patch cycles after CVE-2021-44228 went public. The pattern is consistent: the cost of not funding maintenance shows up later, larger, and split across every downstream user instead of the project itself.
How much is actually being spent on open source maintenance today?
Real money, but a small fraction of what's needed relative to how much software depends on it. Germany's Sovereign Tech Fund, launched in 2022 as a government-backed initiative, committed roughly €14 million in its first phase and has since funded work across more than 60 open source projects and infrastructure components, including support for maintainers of foundational tools most developers have never heard of. Tidelift, a company built specifically around paying maintainers to do security and maintenance work, has distributed millions of dollars to maintainers since its 2017 founding through its subscription model, where companies pay for verified, maintained versions of the open source they already use. GitHub Sponsors and Open Collective add smaller, more fragmented streams — often a few hundred to a few thousand dollars a month per project, nowhere near enough to replace a maintainer's day job. Compare that total pool, likely in the tens of millions of dollars annually across all these programs combined, against the fact that a 2022 Tidelift and Linux Foundation survey of open source maintainers found roughly 60% of them were entirely unpaid for their maintenance work. The spending exists. It's just not remotely proportional to the dependency graph it's supposed to protect.
Why hasn't a decade of high-profile incidents closed the funding gap?
Because funding open source maintenance is a collective action problem, and no single company captures enough of the benefit to justify paying for it alone. Every company using curl, OpenSSL, xz-utils, or Log4j benefits identically whether they pay $0 or $50,000 toward its upkeep, so the rational move for any one company is to wait and hope someone else funds it — which is exactly why curl maintainer Daniel Stenberg has said for years that a library running on billions of devices worldwide survives on a sponsorship budget that wouldn't cover a single mid-level engineer's salary. The 2014 Core Infrastructure Initiative pledges largely lapsed after three years. Alpha-Omega's initial funding, while real, covers a defined set of priority projects, not the long tail of dependencies most companies actually pull into their builds. Even after Log4Shell in 2021 and the xz-utils backdoor in 2024 — two incidents three years apart that both traced back to the same root cause of unpaid, overextended maintainers — there is still no standard mechanism that reliably routes money from the companies benefiting from a dependency to the person keeping it secure. Awareness spikes after every incident. Funding commitments, historically, do not sustain at the same rate.
What would it cost an individual company to actually fix this for its own dependencies?
Far less than most security teams assume, because the fix isn't funding every open source project on earth — it's funding the small number your business actually, critically depends on. A mid-size company typically has a small set of dependencies — often under 20 — that would cause a genuine production or security incident if compromised or abandoned, out of the hundreds or thousands in a typical dependency tree. Tidelift's subscription pricing and direct maintainer sponsorships through GitHub Sponsors or Open Collective for that priority list can run from a few hundred to a few thousand dollars a year per critical dependency — a rounding error next to the cost of a single incident response engagement, which routinely runs into six figures once forensics, legal, customer notification, and patching labor are included. The barrier isn't the dollar amount. It's that most organizations have never inventoried which of their dependencies are maintained by one person, funded by nobody, and sitting underneath a production system that would hurt to lose.
How Safeguard Helps
Safeguard exists to answer the question every company skips before it becomes an incident: which of your dependencies are actually critical, and which of those are running on no funding and one maintainer. Safeguard's software supply chain platform builds a live inventory and SBOM of everything in your dependency graph, then layers in maintainer and project health signals — commit activity, bus-factor, funding status, and known incident history — so security and engineering teams can see, in one view, which packages carry both high blast-radius and low maintenance investment. Instead of reacting to the next xz-utils or Log4Shell after the fact, teams using Safeguard can flag single-maintainer, unfunded dependencies before they ship, prioritize which projects are worth a direct sponsorship or Tidelift subscription, and feed that risk data into existing vulnerability management and procurement workflows. Funding critical open source dependencies is a solvable cost problem once you know exactly which dependencies deserve the money — Safeguard is built to make that list visible, current, and actionable, so the decision to fund maintenance happens on your timeline instead of after a breach.