Open-Source Sovereignty Paradox: Forks, Strain, Bank-Funded Fixes

Open-Source Sovereignty Paradox: Forks, Strain, Bank-Funded Fixes

Key Takeaways

Digital sovereignty is pushing European organizations toward open source and, in many cases, toward private forks. The Linux Foundation’s 2026 State of Open Source in Europe report finds that 48% of respondents maintain private forks, spending an average of 311 hours per release cycle patching 9.5 forks, and that 28% cannot track those costs [1]. Sovereignty through forking can raise the security burden it was meant to reduce: a fork gives control over the code, but the organization that holds it also takes over backporting, testing, and disclosure handling that upstream would otherwise share.

At the same time, maintainers are absorbing more vulnerability traffic. The report’s foreword, written by kernel maintainer Greg Kroah-Hartman, states that Linux CVEs rose from an average of 55 to 230 per week [2]. The Open Source Enterprise Resiliency Alliance (OSERA), announced on October 7, 2026, is an industry-wide effort by financial institutions, as its backers describe it, to pool the cost of patching older open source versions they run [3][4]. One program participant quoted by diginomica described OSERA as “an off-ramp” that buys “twelve, eighteen months” of time [5].

Security teams should inventory forks and pinned end-of-life dependencies now, treat any shared patch exchange as a supply chain component that needs its own verification, and plan for upstream-first remediation as the EU Cyber Resilience Act’s obligations take effect.

Background

Two announcements made at Open Source Summit Europe in Prague on October 7, 2026 describe the same problem from different angles. The Linux Foundation, LF Europe, LF Research, and NeoNephos released the fifth annual State of Open Source in Europe report, which finds that 94% of surveyed organizations consider digital sovereignty important to their technology strategy and 61% consider it very important [1]. The same report finds that 31% of organizations lack a formal open source governance framework [1]. The figures here come from the Linux Foundation’s announcement rather than the full report, and the summary material we reviewed does not state a respondent count, so the percentages should be read as survey results of unstated sample size.

On the same day, the Fintech Open Source Foundation (FINOS) announced OSERA, funded initially by Premier members. The announcements refer to six Premier members but publicly name five: Deutsche Bank, Goldman Sachs, Morgan Stanley, NatWest, and RBC [3][4]. OSERA gives banks a shared way to identify, fix, and verify vulnerabilities in open source software, so that each institution does not patch the same dependency independently [3]. Reporting on the launch describes a “fork tax,” meaning the duplicated effort when several institutions maintain separate teams that fix identical vulnerabilities in the same library [5].

The two announcements connect through a structural tension that we refer to here as the open-source sovereignty paradox. Open source licenses permit an organization to take a copy, keep it inside its own boundary, and modify it, which is attractive when regulators and boards ask who controls the software stack. The same freedom moves responsibility for security maintenance from a shared upstream community to the individual organization. Sovereignty over the code therefore does not carry sovereignty over the vulnerability backlog, and the report’s fork-maintenance figures indicate that many organizations carry this cost without measuring it [1][6].

This pressure arrives while the volume of vulnerability findings is increasing. CSA’s analysis of Project Glasswing reports that AI-driven discovery identified vulnerabilities far faster than open source projects could patch them, with only 97 of the reported critical findings confirmed patched at the time of that analysis [7]. That finding concerned upstream projects, which are largely staffed by volunteers. The situation OSERA addresses is the downstream counterpart: organizations running older versions that upstream no longer supports.

Security Analysis

The analysis below moves from the cost of private forks, through the strain on upstream maintainers, to the OSERA exchange and the risks it introduces. Figures are attributed to their sources throughout, and we mark where a statement is our own inference rather than a reported result.

Private forks as an unmeasured liability

The fork figures in the LF Europe report deserve attention because they quantify a cost that security programs rarely track. Assuming the 311 hours is a total across all forks maintained by the average respondent, an average of 311 hours per release cycle across 9.5 forks works out to roughly 33 hours per fork per cycle, a figure we derived from the report’s averages rather than one the report states directly [1]. That time covers merging upstream changes, backporting security fixes, and regression testing. Because 28% of fork-maintaining organizations cannot track the cost, the true figure for the population could differ from the reported average in either direction; the data do not allow us to say which [1][6].

In our assessment, a private fork can introduce three failure modes that the report’s data do not measure directly. First, the fork can drift from upstream, so that advisories published against upstream versions no longer map cleanly onto the forked code, and scanners may report false negatives or false positives. Second, backports depend on in-house expertise in the specific component, which is the scarce skill the HostingJournalist coverage identifies when it notes that sovereignty claims centered on infrastructure location may obscure reliance on expertise that is hard to replace [6]. Third, a fork that no longer receives upstream fixes becomes a long-lived exposure, and its risk may grow as AI-assisted discovery finds more flaws in the shared code that the fork inherits [7]. The first and third modes are our inference from general practice; the Glasswing analysis concerns upstream projects rather than forks.

Maintainer strain from rising volume and unvetted reports

The foreword to the LF Europe report ties the increase in Linux CVEs, from an average of 55 to 230 per week, to the pressure AI is placing on maintainers [2]. Kroah-Hartman states that the burden of validation should lie with the submitter rather than the recipient, and the same coverage cites testing by VU University Amsterdam students that found nearly half of the changes generated by large language models were incorrect [2]. We report these as statements by the foreword’s author and a secondary account of that testing, not as results we have independently verified. They are consistent, however, with the volume dynamics described in CSA’s Glasswing analysis, in which discovery capacity has outrun remediation capacity [7]. The increase may also partly reflect changes in how CVEs are assigned, and the foreword does not separate these effects.

The LF Europe report also finds that 94% of respondents use or pilot generative AI coding tools and that 48% reported increasing their open source investment as a result of those tools [1]. Taken together, these figures suggest a compounding effect: more AI-assisted consumption of open source raises dependency count, while AI-assisted vulnerability research raises the number of findings against those dependencies. Neither figure measures maintainer workload directly, so the link to maintainer strain remains an inference from the combination.

OSERA as a downstream remediation exchange

OSERA operates on a pooled-demand model. Member banks submit lists of specific packages and versions they need fixed, FINOS identifies the overlap, and commercial maintainers produce patches under service-level agreements [3][5]. The announcement names Moderne as the primary vendor maintainer and ControlPlane as the builder of the exchange platform, with HeroDevs, RapidFort, Sonatype, and Scott Logic contributing to the standard [3]. These vendors are commercial parties that benefit from the program, which readers should bear in mind when weighing the descriptions in [3] and [4]. Patches pass through a gated pipeline that, according to diginomica’s description, enforces signatures, source verification, and VEX statements before release, and banks consume the results through existing corporate proxies [5].

The Linux Foundation announcement reports patches for more than 50 projects in the Spring and Java ecosystems and an initial patching and attestation standard at version 0.1, released within three weeks of operation [3]. The same announcement states that OSERA welcomed its six Premier members within 100 days; that figure describes member onboarding rather than the pace of patching [3]. Diginomica reports a target of more than 80 patches per month by the end of 2026 and an expansion to JavaScript and Python in the first quarter of 2027 [5]. These are stated goals from the program, not delivered results.

The program’s own commentary is candid about its limits. Diginomica quotes one program participant describing it as “an off-ramp” that buys “twelve, eighteen months” of time [5]. It addresses older versions that banks run downstream; it does not replace upstream security work. It also relies, according to the same account, on the EU Cyber Resilience Act eventually making upstream-first patching an obligation, which is that participant’s expectation rather than a regulatory fact [5].

Risks introduced by the exchange itself

A shared patch exchange concentrates trust. Every participating bank consumes artifacts from one pipeline, so a compromise of the exchange, a vendor maintainer, or the signing process would reach all members at once. Diginomica reports that the ledger design deliberately limits visibility into which bank requested or pulled a given patch, and reports a participant acknowledging that the platform is “a beautiful point of attack” [5]. Limiting that visibility is a reasonable design goal, but it is a design acknowledgment, not an assurance. Recent supply chain incidents in package ecosystems, including the Miasma npm worm CSA analyzed in 2026, show how a trusted distribution path can propagate malicious code at scale [8].

A second risk is divergence. Patches produced by a vendor maintainer against an older line become, in effect, another fork, maintained commercially and shared across institutions. If those fixes are not contributed upstream where upstream still exists, the ecosystem has moved the fork tax from many banks to one pool without reducing the total number of divergent code lines. The OSERA materials describe hardened project lines published on GitHub, but we did not find a stated policy on upstream contribution [3].

Regulatory context

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is the relevant regulatory driver. Article 13 requires manufacturers that discover a vulnerability in a component, including an open source component, to report it to the party maintaining that component and to address it, including by sharing the fix where applicable [9]. The LF Europe report finds that 63% of respondents increased investment in open source dependency management because of regulatory pressure, a self-reported attribution [1]. Together with CSA’s analysis of the EU’s sovereignty package, which describes a compliance cascade across NIS2, DORA, the Data Act, and the AI Act, this indicates that regulated entities face concurrent expectations to control their stack, secure it, and demonstrate that they did [10].

Recommendations

The recommendations follow the same sequence as the analysis: first establish what the organization actually runs, then decide how to remediate it, and finally address the longer-term economics of sovereignty.

Immediate Actions

Organizations should build a register of every private fork and every pinned dependency on a version that upstream no longer supports. For each entry, record the owner, the upstream version it derives from, the last date upstream fixes were merged, and the estimated hours per release cycle. The LF Europe finding that 28% of fork maintainers cannot track these costs suggests many organizations will find this register does not yet exist [1]. Because the register is the input to any pooled remediation program, it also determines how much of a program like OSERA an organization could use.

Teams should also confirm that scanners and advisory feeds map correctly onto forked code. A forked component can report a version string that matches no upstream release, so vulnerability tooling can silently miss it. Matching by source provenance or by software bill of materials, rather than by version number alone, reduces this gap.

Short-Term Mitigations

Organizations that run end-of-life Java or Spring lines, and financial institutions in particular, should evaluate whether a pooled remediation service fits their risk profile. The evaluation should treat the exchange as a third-party supply chain component. Questions to ask include how signing keys are protected, how a compromised vendor maintainer would be detected and revoked, whether VEX statements are independently verifiable, and what the program’s policy is for upstreaming fixes [3][5].

Where an organization consumes patched artifacts from any shared exchange, it should keep its existing controls in place. Quarantine, internal repository scanning, and reproducibility checks should remain enabled even where the exchange advertises that no pipeline changes are required, because the exchange’s own gates are not a substitute for the consumer’s. Security teams that run open source programs or contribute to upstream projects should also apply the validation principle in the report’s foreword to their own outbound reports, submitting reproducible findings with a proposed patch where possible and avoiding forwarding unvetted AI-generated output to maintainers [2].

Strategic Considerations

Organizations pursuing sovereignty goals should account for maintenance cost when choosing between forking, contributing upstream, and buying commercial support. A fork is a sovereignty decision that carries a recurring security cost, and that cost should appear in the business case. In most cases, the preferred position is to contribute fixes upstream and keep local patches small, since each retained patch adds to the ongoing hours reported in the LF Europe data [1]; the right balance depends on cost and on how receptive the upstream project is.

Funding upstream maintainer capacity is the complement to funding downstream patches. One OSERA participant describes the program as an off-ramp of limited duration, and the problem it addresses will recur unless upstream projects have the capacity to maintain supported versions longer [5][7]. Financial institutions and other large consumers might consider directing part of their remediation spending to upstream maintenance, and CSA members could raise this in sector forums.

Finally, organizations should plan for the Cyber Resilience Act’s component-reporting and fix-sharing expectations as part of vendor management and open source governance, checking the regulation’s application dates for each obligation [9]. The 31% of European organizations without a formal open source governance framework may be among the most exposed to this change [1][9].

CSA Resource Alignment

CSA’s analysis of Project Glasswing, Project Glasswing: AI Discovery Outpaces Open Source Patching Capacity, is the most directly relevant prior work [7]. It documents the upstream side of the problem, in which machine-speed discovery meets human-speed patching, and its recommendation to invest in maintainer ecosystem capacity corresponds to the strategic consideration above on funding upstream work. The OSERA program and the LF Europe fork data describe the downstream consequence of the same imbalance.

EU Tech Sovereignty: Cloud Concentration Risk and the Compliance Cascade addresses the regulatory environment that drives the sovereignty goals discussed here, including the interaction of NIS2, DORA, the Data Act, and the AI Act, and the Commission’s positioning of open source as a sovereignty-enhancing option [10]. Readers weighing forks against managed services should use it to frame the compliance obligations that accompany each choice. CSA’s Miasma: Red Hat npm Supply Chain Worm shows how trusted package distribution paths can become propagation channels, which is relevant to evaluating any shared patch exchange [8].

As a framework fallback for control mapping, the AI Controls Matrix (AICM) v1.1 supports this guidance through its Threat and Vulnerability Management and Application and Interface Security domains, which provide a basis for the fork register, scanner-mapping, and exchange-verification actions above [11].

References

[1] Linux Foundation. “Linux Foundation Europe Report Finds Digital Sovereignty Drives European Tech Strategy, but Governance and AI Strain Present Major Hurdles.” Linux Foundation, October 7, 2026.

[2] Techzine Global. “Europe falls short on open source governance.” Techzine, October 2026.

[3] Linux Foundation. “Major Banks Back OSERA to Deliver Industry Wide Remediation Standards and Fixes to Secure Open Source Software.” Linux Foundation, October 7, 2026.

[4] FINOS. “Major Banks Back OSERA to Deliver Industry Wide Remediation Standards and Fixes to Secure Open Source Software.” FINOS, October 2026.

[5] diginomica. “What is OSERA, and why are six global banks pooling the cost of patching open source software?” diginomica, October 2026.

[6] HostingJournalist. “Open Source Maintenance Complicates Europe’s Sovereign Cloud Plans.” HostingJournalist, October 8, 2026.

[7] Cloud Security Alliance. “Project Glasswing: AI Discovery Outpaces Open Source Patching Capacity.” CSA, 2026.

[8] Cloud Security Alliance. “Miasma: Red Hat npm Supply Chain Worm.” CSA Labs, June 2026.

[9] European Union. “Regulation (EU) 2024/2847 (Cyber Resilience Act).” Official Journal of the European Union, November 2024.

[10] Cloud Security Alliance. “EU Tech Sovereignty: Cloud Concentration Risk and the Compliance Cascade.” CSA Labs, 2026.

[11] Cloud Security Alliance. “AI Controls Matrix v1.1.” CSA, 2026.