Projects · OSERA | Open Source Enterprise Resiliency Alliance

The lines the sector still runs.

OSERA is now maintaining hardened versions of over 50 libraries in Spring and its transitive closure, with remediations against public CVEs applied to the specific versions prioritized by OSERA Premier Members.

One Spring stack, maintained together

The first wave stays within the Spring lines institutions already have in production, including versions that are past upstream end of life. Fixes are applied directly to those lines — and to the libraries they manage — rather than requiring every firm to upgrade to a major new version before a known CVE is closed.

libraries prioritised by Premier members for the first wave of patches.

Spring lines carry that whole set: Boot, Framework, and Security.

Open

source in a public fork organisation. The inventory lives there, not on this page.

Spring Boot

2.7

The application line. Boot 2.7 manages the Framework and Security versions beside it, and the libraries a typical enterprise Boot application pulls in.

View the Spring Boot fork →

Spring Framework

5.3

The core framework line those applications run. Maintained as Spring Framework 5.3, on its own, alongside Boot.

View the Spring Framework fork →

Spring Security

5.7

The security line paired with Boot 2.7 and Framework 5.3, so authentication and access-control fixes land on the version still in production.

View the Spring Security fork →

The 58 libraries are not listed on this site. The set will keep growing, and the public fork organisation is the list — every maintained repository, in the open. Prioritisation of what to fix next happens in Risk Navigator, and a fix is accepted only through the Remediation Standards gate.

Public sources, FSI-grade member-only releases

We apply fixes for known CVEs to the exact projects and versions the sector still runs — prioritised across firms in Risk Navigator, and accepted into the repository only through the Remediation Standards gate. The source stays open and is offered upstream. The member-ready release sits behind membership.

Known CVE in a [package, version]

in software the sector still runs — surfaced and prioritised across firms in Risk Navigator

→

Fix produced & tested

under an alliance SLA · green CI on the upstream test suite · must clear the Remediation Standards acceptance gate

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, transparent source — fully auditable, for the cases upstream can't take the fix. Anyone can build from it.

Member release

Members

Fully packaged releases members consume through their existing proxy — the coordinates they already use, no CI change.

Non-members

Build from the public fork

The public fork is the canonical, maintained, transparent source code. If you are not a member, that source is yours to build from yourself.

Every maintained line is public, under the upstream project licence.
The same source the alliance maintains — nothing hidden, nothing private.
Where upstream is receptive, patches are offered back to the original project.

Build it yourself

OSERA members

Take the packaged release

Premier members also get the fully packaged releases, with attestations, SBOMs and an audit trail. General members receive those same member releases.

Built artifacts, ready to consume — not a source tree you have to assemble.
Attestations defined by the Remediation Standards: signing, SBOMs, VEX and test evidence.
An audit trail for the release, for the teams that have to show what they ran.

Not a member? Sign up.

No release enters the OSERA repository until it conforms to the Remediation Standards. Source stays public by default; only the built, attested release artifacts sit behind membership. Releases are time-bound — a managed bridge to a current, supported version, not a licence to stay behind. See The Solution for the wider model, and the membership tiers for who consumes the release.