The Problem

The fixes often exist. Getting them into production is the hard part.

Regulated institutions share the same open source, often years behind, and each one pays alone to keep it safe. OSERA exists to mutualize that work without handing the fix to a single vendor or a single country.

The thesis

A network is only as safe as its weakest link

The sector runs strikingly similar software — the same core libraries, in the same versions — so a flaw in one is a flaw in all. J.P. Morgan's Patchmageddon report puts numbers on it: disclosures have outrun the sector's capacity to patch, and exploitation now starts the day a CVE goes public. The weakest links are rarely the largest firms. Systemic resilience only works if institutions of every size, in every country, can afford the same fix. Open collaboration is the neutral, sovereign way to provide that answer — no single vendor, and no single jurisdiction, controls it.

~80%

of open source dependencies sit unmanaged and outdated — resilience is a consumption problem, not just a patching one.

1 in 3

institutions are confident the components they consume are maintained and current. The rest are the weak links.

~78%

of exploitations now begin on or before the day the CVE is disclosed — up from 19% in 2018.

1 in 5

financial services firms report different teams independently maintaining forks of the same open source project — the fork tax, paid many times over.

What we are solving

Four growing pressures every enterprise faces

The cost of staying on what you run

Hardening and long-term support for the open source the sector still runs is paid many times over, firm by firm. The same CVE is forked, patched, or bought as a private support contract.

AI-speed threats, estate-speed consumption

Discovery and exploitation now move at machine speed. A known fix still has to cross change control, test evidence, and an audit trail across thousands of applications.

Sovereign, vendor-agnostic consumption

The dependency is global. The fix cannot depend on one supplier's roadmap, one country's export decision, or a contract that ends and takes the patch with it.

The risk of in-house forks

Separate teams inside one firm, and across the sector, maintain private forks of the same project. That operational risk is no longer tenable in the era of AI cyber-threats.

Why now

Patching is only half of the problem

AI has not changed which vulnerabilities exist. It has changed how fast known ones are weaponised. Regulation now makes timely remediation a duty, not a choice.

⏱

Exploitation has accelerated

Automation weaponises a published CVE in hours. The same fix is still re-created, forked, or bought firm by firm.

§

DORA and NIS2 are in force

Supervisors treat third-party and open source risk as systemic and auditable. A patch with no attestation is unfinished work.

★

The EU CRA clock is running

Vulnerability-reporting duties from Sep 2026; full vulnerability-handling obligations from Dec 2027.

For supervisors, the same work is shared, auditable remediation evidence: less systemic concentration, one place to see the sector's posture, and public forks with open standards.

See the solution