Spring Framework / Spring BootThe CVE conversation before the auditor starts it
Spring Framework 5.3 and Spring Boot 2.7 are past open source end of life, and many applications still run on them. This is the CVE-risk conversation to have before an auditor or a scanner report starts it for you.
Challenge
Open source support for Spring Boot 2.7, the last 2.x line, ended on 30 June 2023, and the final community release, 2.7.18, shipped in November 2023. Spring Framework 5.3 followed on 31 August 2024 with 5.3.39. Later fixes on both lines ship only in Broadcom's commercial builds: 5.3.45, which fixes CVE-2025-41249, goes to subscribers only.
The exposure is wider than Spring's own code. Spring Boot's value is a curated dependency set, and on 2.7 that curation has stopped, so transitive CVEs in Jackson, Logback, Netty and embedded Tomcat are no longer resolved for you. Spring Expression Language has a history of remote code execution advisories, and fixes in that class are no longer published upstream for the 5.3 branch.
The fix everyone agrees on, moving to Spring 6 and Boot 3, needs Java 17 and the javax to jakarta namespace change at the same time, plus a Spring Security rewrite in most applications. Estates still on Java 8 have to do all of it in one programme.
Environment
Applications on Spring Framework 5.3 or Spring Boot 2.6 and 2.7, often on Java 8 or 11, built with Maven or Gradle against an internal repository manager.
Scanners already flag the transitive dependencies, and the findings arrive faster than the Spring 6 migration can absorb them.
Options
Upgrade to Spring Framework 6.2 or 7.0 and Spring Boot 3.5 or 4.x. The right destination. List which Spring projects are in scope before estimating, because Spring Security is usually the longest single task.
Buy commercial Spring support from Broadcom. Its paid support covers Spring Framework 5.3 and Spring Boot 2.7 until 30 June 2029, now inside the TrueSource and Spring Enterprise packaging. It fits estates large enough to justify the subscription minimums.
Stay unpatched and accept the findings. Spring CVEs tend to be remotely reachable and scanners flag them reliably, so this is hard to defend in an audit.
Take third-party extended support: backported fixes to 5.3 and 2.7, and to the managed dependency set, while the migration runs on its own timeline.
Approach
OSSeva ships patched Spring Framework 5.2.x and 5.3.x and Spring Boot 2.6.x and 2.7.x, backporting CVE fixes to the dependency set the 2.7 BOM manages as well as to Spring itself. Builds are signed Maven artifacts delivered through your repository manager. Switching is a change of coordinates and version, for example 2.7.18-osseva-2, with application dependencies unchanged.
The agreement names the Spring modules and transitive dependencies it covers rather than promising Spring support in general, so there is no argument later about what is inside it. If a module is outside what can be patched safely, OSSeva says so before you sign.
OSSeva Assure adds per-CVE remediation narratives, patch attestation letters citing SOC 2 CC7.1, PCI DSS 6.3.3, HIPAA section 164.308 and ISO 27001 A.12.6.1, a pen-test validation summary and a Spring Boot 3 migration readiness assessment. OSSeva Operate adds migration execution support: namespace migration, dependency compatibility, Spring Security reconfiguration and JDK upgrade sequencing.
What this delivers
CVE findings on Spring 5.3 and Boot 2.7 closed with patched builds, documentation the auditor can check, and a Spring 6 migration that runs on an engineering timeline instead of the next scanner report. Continuation engagements run for as long as the migration needs. Spring Boot support is priced per application, not per developer seat; book a discovery call for a quote.
Spring Framework supportWhen did Spring Framework 5.3 and Spring Boot 2.7 reach end of life?
Open source support for Spring Boot 2.7 ended on 30 June 2023, with 2.7.18 as the last community release. Spring Framework 5.3 ended on 31 August 2024 at 5.3.39. Later fixes ship only to Broadcom's commercial subscribers.
Why do Spring Boot 2.7 applications show so many CVEs?
Mostly through transitive dependencies such as Jackson, Logback, Netty and embedded Tomcat. Spring Boot curates those versions through its BOM, and on 2.7 nobody is updating that curation upstream.
Does OSSeva patch the dependencies Spring Boot manages?
Yes. OSSeva backports CVE fixes to Spring Boot 2.7 and to the dependency set the 2.7 BOM manages, and the agreement names which modules and dependencies are covered.
How long can we stay on Spring Boot 2.7?
As long as the business needs, with continuation engagements that run while the Spring Boot 3 migration is planned and run. OSSeva Assure includes a migration readiness assessment.
Do we have to change our build to use OSSeva builds?
Only the coordinates and version. You point the build at the OSSeva registry or your repository manager and use the patched version, such as 2.7.18-osseva-2. Application dependencies stay the same.