Open Source as Critical Infrastructure: How Should Governments Spend Their Money Effectively?

A Consensus Repeated Endlessly Yet Never Truly Implemented

In recent years, governments around the world have frequently called open source software "critical infrastructure"—it has become a standard phrase in policy circles. The EU's newly released AI Cybersecurity Plan continues this logic once again, featuring a dedicated action initiative aimed at "protecting critical open source software."

In terms of problem classification, this indeed points in the right direction. Open source software underpins almost everything—from operating systems and cryptographic libraries to cloud infrastructure. Two landmark incidents have laid this risk bare: Log4Shell (CVE-2021-44228), which erupted in late 2021, exploited a remote code execution vulnerability in the Apache Log4j logging library—a library depended upon by billions of Java applications. The 2024 xz-utils backdoor incident was even more insidious: an unidentified contributor spent two years gradually earning the community's trust through social engineering, ultimately planting a backdoor in a release version of the compression tool, targeting the SSH daemon. The common thread in both incidents: extremely broad dependency, coupled with extremely limited maintenance manpower—a single exhausted, solitary maintainer can be a systemic point of risk for an entire digital society.

But the real test lies not in whether governments shout this slogan, but in whether they are willing to pay for the "boring day-to-day maintenance."

"Protecting Open Source" Shouldn't Become Yet Another Audit Show

There's a recurring trap in the field of open source security governance: the goal of "protecting open source" can easily degenerate into round after round of security audits—audits that create more work for maintainers without paying them anything to do that work.

"Many critical projects don't first need another dashboard. What they need is paid time."

This statement captures the core paradox of current open source security governance. Policymakers naturally favor "visible outputs": a vulnerability report, a security scorecard dashboard, an audit press conference. These things are easy to show off externally and easy to quantify as political achievements.

But for the vast majority of critical open source projects, what's truly in short supply has never been "finding problems"—it's having someone with the time, the energy, and the payment to fix those problems. An audit report finds a pile of CVEs, and then what? Without a corresponding fix budget, these reports simply become yet another list of unpaid labor piled onto maintainers.

Where Open Source Security Funding Should Go: The "Unsexy" Places

A truly effective public funding program should cover the following categories of often-overlooked spending:

1. Multi-Year Maintainer Contracts, Not One-Off Bonuses

Open source maintenance is a long-term commitment; one-off "bonuses" or "bounties" cannot give people the security to invest continuously. Only stable, multi-year contracts allow core maintainers to treat the project as sustainable work, rather than a labor-of-love side gig.

2. Reproducible Builds and Signed Release Infrastructure

The lessons of supply chain attacks (such as the xz incident) show that the build process itself is an attack surface. Reproducible Builds is an engineering practice aimed at ensuring that the same source code compiles into byte-for-byte identical binary output in any environment, thereby allowing third parties to independently verify that release packages have not been tampered with. Projects like Debian and the Tor Project have advanced this practice for years, but most open source projects have been unable to follow suit due to a lack of engineering resources. Signed release infrastructure is likewise key to defending against software supply chain poisoning, but such engineering investment is both tedious and chronically underfunded.

3. Coordinated Disclosure and Incident Response Capabilities

When a vulnerability appears, who coordinates? Who responds in the middle of the night? Most open source projects have no dedicated incident response team at all, relying entirely on maintainers to step up ad hoc—a state of affairs that is itself a risk.

4. Independent Audits + Matching Fix Budgets

Audits must be tied to fix budgets. Auditing without funding for fixes is like diagnosing without treating. This is the most common—and most fatal—gap in current funding models.

5. Avoid "Punishing" Widely-Depended-Upon Projects

Dependency mapping should not inversely "punish" projects that, precisely because they are widely used, expose more problems. The more depended-upon a critical open source component is, the more support it should receive—not more compliance burden.

6. Succession Plans for Single-Maintainer Projects

For projects down to a single active maintainer, succession and handover plans must be established to systematically eliminate the risk of a "Bus Factor of 1." Bus Factor is a metric measuring how concentrated a project's knowledge is: if a project only needs to lose N core contributors to fall into an unmaintained state, its Bus Factor is N. According to a 2015 large-scale study of GitHub, more than half of active open source projects have a Bus Factor of no more than 2—meaning that a single accident or a single case of burnout is enough to leave countless downstream systems without security guarantees.

What Metrics Should Measure the Effectiveness of Open Source Security Investment

Evaluating whether open source security funding is effective requires a fundamental shift in metrics:

"The metric that matters shouldn't be how many vulnerabilities a project announces, but how quickly funded projects can fix problems without burning out the people who understand the code."

Many security programs currently measure success by "how many vulnerabilities were found/disclosed," but this is essentially a vanity metric—it measures the number of problems, not the capacity to solve them.

More meaningful evaluation dimensions should focus on two points:

• Fix speed: How short is the time window from vulnerability discovery to completed fix;
• Sustainability: Whether core maintainers are working healthily, rather than continuously on the edge of burnout.

The latter deserves particular attention. The biggest hidden risk in the open source ecosystem is precisely those maintainers who silently support critical projects yet go unpaid and unrecognized for the long term. Their burnout or departure is often more destructive than any single vulnerability.

An Allocation Question Worth Taking Seriously

Suppose a government has €100 million for open source security. What proportion of it should go toward audits, maintainer time, build infrastructure, and incident response?

There is no one-size-fits-all answer to this question, but it forces us to confront the priorities of resource allocation. If most of the budget flows to audit firms and consulting reports, and only a tiny fraction actually reaches maintainers, then no matter how "compliant" the program is, it cannot touch the root of the problem.

A reasonable allocation direction should tilt heavily toward maintainer time and infrastructure—after all, the problems that audits uncover ultimately have to be fixed by these people.

Slogans Are Easy to Shout, Bills Are Hard to Pay

The recognition of open source software as critical infrastructure has become a consensus among governments across nations. But consensus itself solves nothing.

There is only one real test: when the bill lands on the table, whether governments are willing to pay for the day-to-day maintenance work that isn't camera-ready, doesn't produce reports, yet genuinely keeps the digital world running. This is the only litmus test that distinguishes "policy posturing" from "substantive investment."