26 June 2026 - FINOS announces the intent to form OSERA alongside Akrites. Read the OSERA announcement.

Secure open source. In production. At scale.

OSERA is the Open Source Enterprise Resiliency Alliance: a FINOS initiative helping regulated institutions close patch coverage gaps and operationalize remediation at scale. We help participants prioritize vulnerabilities, sponsor open back-patches, define shared consumption standards, and apply patches from upstream, vendors, and elsewhere - with greater consistency and evidence. Operational resilience, without the lock-in.

Get involved Read the Guiding Principles Explore Risk Navigator

Akrites coordinates upstream security response; OSERA helps regulated enterprises operationalize remediation downstream. Read the FINOS announcement.

Part of the collective Linux Foundation security response

Complementary to Akrites, by design

Akrites · Linux Foundation

The upstream security response layer: coordinated vulnerability disclosure, remediation and upstreaming so fixes can reach open source projects responsibly.

OSERA · FINOS

The downstream operationalization layer: prioritization, standards, validation, back-patch sponsorship, vendor alignment, and rollout patterns for regulated enterprises.

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. Incubated in financial services, where the regulatory bar is highest, the model is built to serve any regulated enterprise. Open collaboration is the neutral, sovereign way to provide the shared answer.

~80%

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

Sonatype · State of the Software Supply Chain

1 in 3

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

FINOS · State of OSS in Financial Services 2024

hours

is all automation now needs to weaponise a published CVE. The window to apply a known fix has collapsed.

Industry observation

How it works

Public by default — private only for the participant-ready build

We apply fixes for known CVEs to the exact projects and versions the sector still runs. The source stays open; only the built, participant-ready release sits behind formation participation.

Known CVE in a [package, version]

in software the sector still runs — often past upstream end-of-life

→

Fix produced & tested

under an alliance SLA · green CI on the upstream test suite

Upstream first

Public

Offered back to the original project wherever it is alive — free and public for the whole community.

Public fork

Public

The canonical maintained source, fully transparent and auditable — for the cases upstream can't take the fix.

Participant release

Participants

Built, signed artifacts participants consume through their existing proxy — the coordinates they already use, no CI change.

Source is public by default; only the built, participant-ready release artifacts sit behind formation participation. Releases are time-bound — a managed bridge to a current, supported version, not a licence to stay behind. Cryptographic signing, full SBOMs and VEX are planned (Workstream 1).

Available tooling

Prioritise open source remediation with Risk Navigator

Risk Navigator turns dependency and vulnerability data into a practical remediation view: what is exposed, which projects are affected, and where upgrades or backpatches should be prioritised.

From vulnerable libraries to action

Use the overview to inspect vulnerable packages, CVEs, affected projects, safe versions, and backpatch candidates before bringing work into the OSERA formation process.

Rank libraries by CVSS, KEV, EPSS, project footprint, and upgrade path.
See which applications are directly or transitively exposed.
Identify candidates for upgrade guidance, OpenRewrite recipes, or backpatch work.

Open Risk Navigator See related workstreams

Risk Navigator prioritization interface showing vulnerable libraries, CVEs, affected projects, and remediation details

An open, two-sided platform

End users and tech producers, in one neutral venue

Not a vendor and not a buyers' club — an open ecosystem. Institutions that run open source meet the technology firms with deep upstream expertise that maintain it. No single firm sits in the middle.

End users · demand

Everyone who runs the software

Banks, insurers & market infrastructure
Fintechs
Regulated enterprises beyond finance
Technology providers to the sector

Resilient, compliant OSS at a fraction of single-firm cost.

The open, governed platform

FINOS neutral governance · open standards · per-project funding pools

IP & antitrustConfidentialityOpen standardsUpstream-first

Tech producers · supply

Firms with upstream expertise

Upstream specialists
OSS maintainers
Security & remediation firms
SIs & consultancies

Reach the whole sector through one neutral channel — no lock-in.

Incubated in financial services — open to any regulated enterprise that runs the same software.

The value

What each actor gets

One effort, three constituencies — each with a clear reason to take part.

FSIs · end users

Pay a fraction of single-firm cost
A flexible funding model — pooled & per-project; pay for what you depend on
A venue you already trust: IP, antitrust, confidentiality
DORA / NIS2 / CRA readiness, with evidence built in
Remediation stays open & portable — no lock-in

OSS & tech vendors · producers

One neutral channel to the whole sector — no per-firm BD
Demand aggregated and funded through directed pools
Win on upstream expertise, not on lock-in
Reputation and contribution across the commons
Upstream-first — work that benefits everyone

Regulators

Shared, auditable remediation evidence
Reduces systemic third-party & open source risk
One point of engagement for the sector's OSS posture
Transparency — public forks, open standards
Aligned to DORA, NIS2 and the CRA

Why now

The fixes already exist — applying them is the hard part

AI hasn't changed which vulnerabilities exist; it has changed how fast known ones are weaponised. And regulation now makes timely remediation a duty, not a choice.

⏱

Exploitation has accelerated

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

DORA & NIS2 are in force

Supervisors increasingly treat third-party and open source risk as systemic and auditable.

★

The EU CRA clock is running

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

Potential workstreams

What the platform could deliver

Indicative only — workstreams and deliverables are to be agreed by participants during formation.

WS1 · potential

Backpatching governance

What to maintain, who produces it, under what SLA — openly governed, upstream-first.

Risk-based prioritisation & intake
SLA tiers, SOW & producer selection
Artifact-naming & release spec
Per-project funding pools
Signing, full SBOM & VEX — planned

WS2 · potential

Regulated consumption standards & tools

Consuming fixes in time across a regulated estate — and proving it. Risk Navigator is an early reference tool for prioritisation and remediation planning, alongside FINOS CALM and the Open SDLC Controls Framework.

Consumption evidence pack
Mapped to DORA, NIS2 & CRA
Blast-radius modelling via CALM
CRA-readiness self-assessment

WS3 · potential

Regulatory-compliant remediation standards

One open standard so a fix from any producer is portable, verifiable and lock-in-free.

Potentially joint with OpenSSF + Akrites

Open production standard (SLSA · SBOM · VEX)
Disclosure / VEX interop with Akrites
"Portable patch" conformance
Maps to CRA handling & reporting

Available now

Maintained backpatch lines — already piloted in bank environments

Proof, not slideware. The formation pilot already maintains these critical Java lines, validated end-to-end by participating banks through existing proxies with the coordinates they already use.

Apache Camel

2.25.4+backpatch.001

Java · integration

Bouncy Castle

1.47+backpatch.001

Java · cryptography

Netty

3.10.6.Final+backpatch.001

Java · networking

Spring Framework

5.3.39+backpatch.001

Java · app framework

+Propose a projectAdd one we should maintain

Explore projects →

Participants resolve them through their existing corporate proxy with the coordinates they already use — no code or CI changes. Each line is time-bound. Signing, full SBOM and VEX are on the roadmap (WS1).

Why join now

The window is open — and the clock is regulatory

For end users

Stop paying for the same fix many times over.

Shape the first projects and SLAs while founding terms are set
Get ahead of the EU CRA (reporting 2026, full handling 2027)
Replace a recurring single-firm "fork tax" with one shared programme

For tech producers

One open channel to the whole sector.

Reach every institution through a neutral venue — no per-firm BD
Win on upstream expertise, not on lock-in
Help set the open production standard you'll be measured against

Get involved

Propose a project — or offer to maintain one

Open to institutions of every size and to technology firms with upstream expertise, anywhere in the world.

Get involved

Use the form below to propose a project for the alliance to consider maintaining, offer your firm as a tech producer, or share your interest in joining the effort. The FINOS team will follow up with next steps.

Just want to back it?

Join the funding effort and back the projects you depend on — pooled, per-project, pay for what you use.

Not a FINOS member? - membership@finos.org Already a member? - membersuccess@finos.org

Form submissions route to membership@finos.org. Prefer to talk first? Join the weekly Supply Chain Resiliency formation call.

A short history

How we got here

Early 2026

FINOS institutions recognise they each pay, independently, to keep the same open source dependencies alive — forking, patching or buying support for identical CVEs.

Q2 2026

Spearheaded by Moderne, the effort is brought to the FINOS community — in the open, not as a product — and a formation group convenes to design a mutualised, openly-governed model.

May–June 2026

A working pipeline ships: critical Java lines maintained as backpatch releases and validated end-to-end by participating banks.

June 2026

The Linux Foundation launches Akrites - the upstream security response and maintenance layer for critical open source. Read the Linux Foundation announcement.

26 June 2026

FINOS announces the intent to form OSERA with support from Deutsche Bank, Goldman Sachs, Moderne, Morgan Stanley, RBC, Sonatype, and TD Bank Group. Read the OSERA announcement.

Stand with us.

Keep remediation open, verifiable, portable, and consumable at scale. Propose a project, offer to maintain, or add your institution to the effort.

Get involved Open Risk Navigator Read the Guiding Principles Press

Secure open source. In production. At scale.

Akrites · Linux Foundation

OSERA · FINOS

Upstream first

Public fork

Participant release

From vulnerable libraries to action

Everyone who runs the software

The open, governed platform

Firms with upstream expertise

Exploitation has accelerated

DORA & NIS2 are in force

The EU CRA clock is running

Backpatching governance

Regulated consumption standards & tools

Regulatory-compliant remediation standards

For end users

For tech producers

Get involved

FINOS Announces Intent to Form OSERA, a Global Financial Services-Led Alliance for Open Source Supply-Chain Resiliency

FINOS Announces Intent to Form OSERA for Open Source Supply-Chain Resiliency in the Era of AI

Global banks back project to strengthen open source resilience

Global Banking Giants Launch Project OSERA to Secure Open Source Supply Chains Against AI Threats

Six global banks complete open source security pilot as FINOS announces Project OSERA

FINOS announces plan to launch open source resiliency alliance

Linux 基金會旗下 FINOS 規畫成立開源企業韌性聯盟 OSERA，協助金融業修補開源套件

Stand with us.