Getting a handle on Spring Boot versions is fundamental to keeping your application secure, supported, and ready for regulations like the EU’s Cyber Resilience Act (CRA). Each version family, whether it’s 2.x or 3.x, comes with a specific support lifecycle. If you’re running an outdated version, you’re exposing your product to known, unpatched security vulnerabilities.
Navigating the Spring Boot Version Landscape
For any organisation building with Java, managing Spring Boot versions isn’t just a technical chore—it’s a critical business function. Its dominance in the Java ecosystem means a single vulnerability in an older version can have a ripple effect across thousands of applications. In fact, recent Snyk data shows that 60% of Java developers now rely on the Spring Framework for their primary applications, making version awareness a core part of any compliance and security programme.
The timeline below maps out the release history for Spring Boot’s major versions, showing the journey from version 1.0 to the current 3.x generation.
This progression also highlights a growing emphasis on platform security, especially with the release of version 3.0, which brought significant foundational upgrades.
To help you quickly assess your current standing, this table summarises the support status for each major release. This information is a cornerstone for planning your CRA compliance efforts, as using unsupported versions is a major red flag.
Spring Boot Major Version Support Status
| Major Version | Initial Release | End of OSS Support | Current Status |
|---|---|---|---|
| 3.x | November 2022 | November 2024 | Supported |
| 2.x | March 2018 | November 2023 | EOL |
| 1.x | April 2014 | August 2019 | EOL |
As you can see, any application still on Spring Boot 1.x or 2.x is officially past its End-of-Life (EOL) date for open-source support. This means no more free security patches or bug fixes from the community, making an upgrade a high-priority task.
Understanding Version Structure
Spring Boot uses a standard MAJOR.MINOR.PATCH versioning format. For CRA documentation and risk assessment, the MAJOR and MINOR numbers are the most important because they signal the support window and potential for breaking changes.
Here’s what each number tells you:
- MAJOR (e.g., 3.x.x): This signals big, often breaking, changes. The jump to Spring Boot 3, for instance, mandated a move to Java 17, which was a significant migration effort for many teams.
- MINOR (e.g., 3.2.x): These releases bring new features and dependency upgrades but are designed to be backward-compatible within the same major version line. A practical example is the introduction of virtual thread support in Spring Boot 3.2.
- PATCH (e.g., 3.2.5): These are all about bug fixes and security patches. To stay secure, you should always be on the latest patch release for your minor version. For instance,
3.2.5contains security fixes not present in3.2.4.
Let’s say your team’s code scan flags version 2.7.5. You immediately know it’s part of the 2.x line, which is no longer receiving open-source support. This is a crucial piece of information for your risk register. Finding this version string is simple whether your project uses Maven or Gradle, and our guide comparing Maven vs Gradle can help you navigate your project’s build files.
Why Tracking Spring Boot Versions Is Critical for CRA Compliance
For any organisation placing products with digital elements on the EU market, tracking Spring Boot versions has moved from a technical best practice to a legal imperative. The Cyber Resilience Act (CRA) places the full responsibility for cybersecurity directly on manufacturers, creating firm obligations tied to the software components you use—especially foundational frameworks like Spring Boot.
The CRA demands that manufacturers manage vulnerabilities throughout a product’s entire lifecycle. This isn’t a suggestion; it’s a legal duty to provide security updates for at least five years or the product’s expected lifetime. Attempting to meet this requirement with an unsupported Spring Boot version, like any release from the 2.x line which hit its open-source end-of-life in November 2023, is practically impossible.
The Role of SBOMs and Post-Market Surveillance
Regulators will be looking closely at your Software Bill of Materials (SBOM) to check for compliance. If your SBOM reveals an outdated Spring Boot version without a commercial support plan for security patches, it’s an immediate red flag and a major compliance gap. This is exactly where post-market surveillance becomes so important.
The CRA requires manufacturers to continuously monitor for vulnerabilities in their products’ components. Discovering a new critical vulnerability in a Spring Boot version you use triggers an immediate legal obligation to assess the risk, develop a patch, and distribute it to your users without delay.
Let’s say your product uses Spring Boot 2.7.10. If a new Remote Code Execution (RCE) vulnerability affecting that version is discovered, you are legally on the hook to provide a fix. Since the open-source community no longer patches the 2.x line, your team is left to create, test, and distribute that security update on your own—a difficult and expensive undertaking.
This entire process must be documented and ready for an audit. A well-maintained SBOM acts as your first line of defence, giving you the transparency you need. To dig deeper into this essential documentation, have a look at our detailed guide on CRA SBOM requirements. It’s also helpful to frame these regulatory demands within broader methodologies like Governance, Risk, and Compliance software, which provides a structured approach to managing these software lifecycle challenges.
How to Detect Your Spring Boot Version
Knowing your exact Spring Boot version is the first step in any credible vulnerability management or CRA compliance effort. For engineering and security teams, this isn’t just about a quick check—it’s about getting an accurate, provable inventory of what’s running in your software.
Fortunately, there are a few straightforward methods to pinpoint the version, whether you’re digging into a Maven or a Gradle project.
Check Your Maven Project Object Model (POM)
In any Maven-based project, the pom.xml file is your primary source of truth. The Spring Boot version is usually defined in one of two main places.
The
<parent>Tag: Most projects inherit their core dependencies and build configurations directly from thespring-boot-starter-parent. The version is stated explicitly right there.<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.7.18</version> <!-- This is the Spring Boot version -->
<relativePath/> <!-- lookup parent from repository -->
</parent>The
<properties>Tag: In some setups, the version might be centralised in the<properties>section and then referenced by other dependencies. You’ll want to look for a property named something likespring-boot.version.<properties>
<java.version>17</java.version>
<spring-boot.version>3.2.5</spring-boot.version> <!-- The version is defined here -->
</properties>
Find the Version in a Gradle Build
For projects built with Gradle, your investigation will focus on the build.gradle (for Groovy) or build.gradle.kts (for Kotlin) file. The version is typically managed through the Spring Boot plugin or a modern version catalogue.
Plugin Declaration: Often, the simplest case is finding the version declared directly in the
pluginsblock where the Spring Boot plugin is applied.plugins {
id 'org.springframework.boot' version '3.2.5' // This line specifies the version
id 'io.spring.dependency-management' version '1.1.4'
id 'java'
}Version Catalogue (
libs.versions.toml): In modern Gradle projects that centralise dependency management, you’ll need to look in thegradle/libs.versions.tomlfile. Check for an entry likespringBoot.[versions]
springBoot = "3.2.5"
Use Build Tool Commands for a Deeper Look
Sometimes, the declared version in your build file is just the start of the story. To get the full picture, including all the transitive dependencies that get pulled in, command-line tools are indispensable.
For Maven users, running mvn dependency:tree is essential. It prints a complete hierarchy of every project dependency, making it easy to spot the exact spring-boot JARs being used in the final build. A practical example of the output might look like this:
[INFO] --- maven-dependency-plugin:3.1.2:tree (default-cli) @ my-app ---
[INFO] com.example:my-app:jar:0.0.1-SNAPSHOT
[INFO] - org.springframework.boot:spring-boot-starter-web:jar:3.2.5:compile
[INFO] +- org.springframework.boot:spring-boot-starter:jar:3.2.5:compile
[INFO] | - org.springframework.boot:spring-boot:jar:3.2.5:compile
[INFO] | - org.springframework:spring-context:jar:6.1.6:compile
This output clearly shows spring-boot-starter-web at version 3.2.5.
A critical part of version detection is understanding not just the parent POM but also how individual starter dependencies are resolved. Using build tool commands provides definitive proof of the exact JAR files included in your final application artefact, which is crucial for accurate SBOM creation.
The most scalable way to handle this is with a Software Composition Analysis (SCA) tool. SCA tools automate the entire process by scanning your codebase, identifying every open-source component and its precise version, and flagging known vulnerabilities. This is fundamental for streamlining your CRA compliance efforts.
For more on managing your application’s components at runtime, you might find our guide on the Spring Boot Actuator useful, as it offers valuable runtime information about your application.
Spring Boot 3.x Versions Explained
The Spring Boot 3.x release line is a huge leap forward for the framework. For teams preparing documentation for regulations like the EU’s Cyber Resilience Act, understanding this generation is non-negotiable, as it sets the current baseline for modern and secure applications.
The single biggest change was making Java 17 the mandatory minimum. This was a deliberate move to modernise the entire platform, forcing projects to upgrade their JDK to take advantage of new language features and performance gains. It was a clear signal: the old ways were no longer enough.
Alongside the Java bump, Spring Boot 3.0 finalised the move away from Java EE to Jakarta EE 9+. This was a major breaking change, introducing a complete namespace shift from javax.* to jakarta.* across the board. You can’t just drop in the new version and expect it to work.
A simple, practical example is how you define a JPA entity. In older versions, you used javax.persistence.Entity. With any 3.x release, that must be updated to jakarta.persistence.Entity.
// Spring Boot 2.x
import javax.persistence.Entity;
import javax.persistence.Id;
@Entity
public class User {
@Id
private Long id;
// ...
}
// Spring Boot 3.x
import jakarta.persistence.Entity;
import jakarta.persistence.Id;
@Entity
public class User {
@Id
private Long id;
// ...
}
This isn’t a minor tweak. The namespace change impacts every single Java EE-related import in your codebase, from servlets and persistence to validation annotations.
Key Releases in the 3.x Line
Each new minor release in the 3.x family isn’t just about bells and whistles; it’s about critical dependency upgrades and security fixes. Knowing the lifecycle of these Spring Boot versions is fundamental to maintaining a strong security posture.
- Spring Boot 3.0 (November 2022): The groundbreaking release. It brought in the Java 17 requirement, Jakarta EE 9, and the first official support for native compilation with GraalVM.
- Spring Boot 3.1 (May 2023): Built on the foundation by expanding GraalVM native image support and adding official support for Docker Compose, which made local development setups much simpler.
- Spring Boot 3.2 (November 2023): A big one for performance. This version introduced support for virtual threads from Java 21’s Project Loom and a totally re-architected
RestTemplateclient. - Spring Boot 3.3 (May 2024): Continued to polish Project Loom support and rolled out a host of dependency upgrades to harden security and boost performance.
Staying on the latest minor version isn’t just about getting new features; it is a direct security measure. Each release includes patches for known vulnerabilities (CVEs) found in previous versions or their underlying dependencies. For example, Spring Boot
3.2.4addressed CVE-2024-22243, a denial-of-service vulnerability inspring-webmvc. Failing to upgrade from an earlier3.2.xrelease leaves your application exposed to this specific risk.
The rapid adoption of newer Spring Boot versions is a trend that aligns perfectly with the post-market surveillance duties required by the CRA for European manufacturers. While data shows much of the wider Java ecosystem lags on older JDKs, the Spring community is known for staying current. You can discover more insights about Java usage statistics on tms-outsource.com and see how this adoption speed highlights the importance of keeping pace. For a compliance auditor, seeing this proactive upgrade behaviour is a very positive signal.
End of Support and Upgrade Planning
The open-source support window for any Spring Boot minor version is typically 12 months from its release date. This is a critical deadline. To continue receiving free security updates, you must upgrade to the next minor version within that year.
For instance, open-source support for the entire Spring Boot 3.2.x line is scheduled to end in November 2024. If your organisation is still running it after that date, you’ll either need a commercial support plan or you must upgrade to 3.3.x to remain secure and compliant.
Navigating Java and JDK Compatibility
The connection between your Spring Boot version and its Java Development Kit (JDK) is more than just a technical detail—it’s a cornerstone of your security and compliance strategy. The two are tightly coupled. Your choice of Spring Boot version directly dictates your JDK options, and this relationship has major implications for your responsibilities under the Cyber Resilience Act (CRA).
A perfect example is the huge shift that came with Spring Boot 3.x. It mandated Java 17 or higher as its baseline, a deliberate move to modernise the framework and take advantage of new platform features. This stands in sharp contrast to the older Spring Boot 2.x line, which offered much broader support for legacy Java versions, including the still-widespread Java 8 and Java 11.
The Importance of Long-Term Support (LTS)
For any product you place on the EU market, using a Java version with Long-Term Support (LTS) is non-negotiable for meeting your CRA obligations. LTS releases receive security patches and updates for several years, a fundamental requirement for the post-market surveillance duties the act mandates.
Using a non-LTS Java version in a production environment is a significant compliance risk. Recent data confirms that less than 2% of applications use non-LTS versions, meaning production-grade Spring Boot applications almost exclusively rely on stable, supported Java releases.
The compatibility matrix below provides a clear, at-a-glance mapping of major Spring Boot versions to their corresponding Java LTS requirements. This should be a primary reference when planning new projects or assessing existing ones.
Spring Boot and Java LTS Version Compatibility Matrix
This table maps Spring Boot major versions to their required and supported Java Long-Term Support (LTS) versions.
| Spring Boot Version | Minimum Java Version | Maximum Supported Java Version | Recommended Java LTS |
|---|---|---|---|
| Spring Boot 3.x | Java 17 | Java 21+ | Java 17, Java 21 |
| Spring Boot 2.x | Java 8 | Java 17 | Java 8, Java 11 |
As the matrix shows, if your product uses any Spring Boot 3.x version, your absolute minimum is Java 17. Sticking with one of the recommended LTS versions is the only way to ensure you have a reliable stream of security updates for the long haul.
Choosing Your JDK Distribution
But the Java version isn’t the whole story. Your choice of JDK distribution—like Eclipse Adoptium, Amazon Corretto, or Oracle JDK—is just as important. Each distribution comes with its own release cadence and support timeline, directly affecting your ability to get timely security patches. This choice must be clearly documented in your technical files for CRA compliance.
Take a Spring Boot 3.2 application. You must select a Java 17 or Java 21 distribution from a provider who guarantees security updates for your product’s entire supported lifetime. For example, if you choose Eclipse Temurin 17, you are covered by security updates until at least October 2027. We’ve seen a major market shift here, with many developers moving away from Oracle JDK. In fact, 36% of developers switched to alternative OpenJDK distributions last year, and Eclipse Adoptium saw a 50% year-over-year growth in adoption. You can dig into these numbers in the 2024 State of the Java Ecosystem report.
This trend highlights just how important it is to select a JDK provider that aligns with your long-term security and compliance strategy, not just your immediate technical needs.
Your Upgrade and Remediation Playbook
To manage outdated Spring Boot versions and prepare for regulations like the Cyber Resilience Act, you need a clear, actionable plan. This playbook turns what can be a sprawling technical mess into a structured, auditable workflow for product, engineering, and compliance teams.
The main goal is to get your applications off unsupported releases—especially the widely-used but now EOL Spring Boot 2.7.x line—and onto a current, supported version in the 3.x family. A Spring Boot upgrade isn’t just about changing a version number in your build file; it’s a strategic project that needs proper planning, especially if you’re incorporating broader Legacy System Modernization Strategies for long-term health.
Step 1: Assess and Plan
Don’t even think about writing code yet. The first step is always a thorough assessment. Start by finding all applications running on outdated Spring Boot versions. You can get a complete picture of all dependencies, including the transitive ones, by running mvn dependency:tree. If you need a refresher on that, we have a guide on how to use the Maven dependency tree.
Next, you need to document every breaking change between your current version and the target. The biggest hurdle for most teams is the mandatory javax to jakarta namespace migration required for Spring Boot 3.
The switch from
javax.persistencetojakarta.persistenceis a classic example of a high-impact breaking change. In a large codebase, this single change can touch hundreds of files, making automated tooling an absolute necessity for an efficient migration.
With this assessment in hand, build a detailed project plan that outlines your timelines, resources, and testing strategy. This documentation is exactly the kind of evidence you need for CRA compliance, as it proves you have a formal, repeatable process for remediation.
Step 2: Migrate and Verify
Now you can get your hands dirty. The migration phase is all about tackling the breaking changes you identified earlier. For the javax to jakarta migration, Spring offers an official migration tool that automates a huge chunk of the refactoring work.
Practical Example: Using the Spring Boot Migrator
The spring-boot-migrator is a command-line tool that rewrites your source code for you.
# Example command to run the migrator on your project
$ java -jar spring-boot-migrator-0.1.0-SNAPSHOT.jar
-r `javax-to-jakarta`
-p /path/to/your/project
Running this command transforms all the relevant imports and dependencies across your project, saving an enormous amount of manual effort. After the automated steps are complete, go into your pom.xml or build.gradle and update it to your target Spring Boot version, like 3.3.1.
Once the code is updated, it’s time to verify everything still works. Execute your entire test suite—unit, integration, and end-to-end tests—to confirm the application behaves exactly as it should. Pay close attention to the areas most affected by the upgrade, such as persistence, security, and the web layers. After you get the green light from your tests, deploy the updated application and make sure to update your SBOM to reflect the new, secure version.
Frequently Asked Questions About Spring Boot Versions
When you’re staring down a regulatory deadline like the EU’s Cyber Resilience Act (CRA), a lot of questions about your tech stack come into sharp focus. For product managers, security teams, and compliance officers, understanding your Spring Boot versions is non-negotiable.
Here are direct answers to the most common questions we see, written to give you the clarity needed to build your compliance case.
Can I Use Spring Boot 2.x in a Product Sold in the EU After the CRA Deadline?
This is a high-risk strategy that almost certainly leads to non-compliance. The entire Spring Boot 2.x line reached its official end-of-life in November 2023. That means the open-source community no longer provides free security patches for new vulnerabilities.
The CRA demands that manufacturers actively manage vulnerabilities and deliver security updates. If you’re relying on unsupported Open Source Software (OSS), you have no credible way to meet that obligation.
Your only realistic path forward with an EOL version is to purchase a commercial support contract from a provider like VMware. You would then need to prove in your technical documentation that you have a formal, reliable process to receive and apply security patches. Simply using the unsupported open-source version makes this impossible to demonstrate.
What Is the Most Important Action for CRA Compliance with Spring Boot?
Your single most critical action is to generate and maintain an accurate Software Bill of Materials (SBOM) for every product. Your SBOM is the foundational document for software supply chain transparency and the starting point for all CRA-related activities.
The SBOM must list the exact Spring Boot version you are using. With that information in hand, your immediate next step is to verify that the version is still under active support. Ideally, you should be on the latest stable release of the current 3.x line to get the most comprehensive security coverage.
If your SBOM uncovers an outdated or unsupported version, you must create a documented, time-bound plan to upgrade it. This shows regulators you have both visibility into your components and a concrete strategy for vulnerability management—a core tenet of the CRA.
How Does My Choice of Java JDK Affect Spring Boot Compliance?
Your choice of Java Development Kit (JDK) is every bit as critical as your Spring Boot version. The two are tightly coupled. For instance, the entire Spring Boot 3.x line requires Java 17 or later, making an older JDK a complete non-starter.
More importantly, you have to use a JDK distribution that is itself receiving timely security updates. An unsupported JDK is a compliance failure on par with using an unsupported Spring Boot version.
Your compliance documentation needs to be precise. It isn’t enough to say you use “Java 17”. You must specify the exact distribution (e.g., Eclipse Adoptium, Amazon Corretto) and confirm its support lifecycle aligns with your product’s obligations in the EU. Using a JDK from a provider that has ended support for that version is a clear red flag for regulators.
What Should I Do When a CVE Is Announced for My Spring Boot Version?
The CRA mandates a formal, documented vulnerability handling process. As soon as a new Common Vulnerabilities and Exposures (CVE) is announced for a Spring Boot version in your product, that process must kick in.
- Assess: First, you have to determine if your specific configuration and usage make you vulnerable. Not all CVEs affect all applications.
- Prioritise: If you are affected, you must evaluate the CVE’s severity. Under the CRA, critical vulnerabilities demand a rapid response.
- Remediate: The primary and expected remediation path is to upgrade to a patched version of Spring Boot as quickly as your development and testing processes allow.
Practical Example of Remediation
Let’s say your product uses Spring Boot 3.3.0, and a critical CVE is announced with a fix in version 3.3.1. Your documented process should trigger your team to:
- Immediately start testing the
3.3.1update in a staging environment. - Deploy the patched version to all affected products on the market in a timely manner.
- Document the entire response—from discovery and assessment to final deployment—as evidence for your technical file.
A structured response like this is exactly what auditors look for to confirm you are meeting your post-market surveillance and security duties.
Understanding and managing your obligations under the Cyber Resilience Act can be complex. Regulus provides a clear, step-by-step platform to assess CRA applicability, generate a tailored requirements matrix, and build your technical documentation with confidence. Gain clarity and reduce compliance costs by visiting https://goregulus.com.
