How to Keep the Spring Framework and Spring Boot Secure from CVEs

HeroDevs loves open source Spring. Spring is the most popular framework in the Java ecosystem by some distance. Many of our engineers have made their careers working on Spring and we want to share what it means to keep Spring secure.

First and foremost, it’s important to understand that Spring is a portfolio of different projects. Projects in the Spring portfolio depend on other Spring projects. In effect, it becomes a tree structure with many Spring projects being pulled together. Spring Framework exists at the bottom of the tree and is used by all other Spring projects. Spring Boot exists at the top of the tree and ensures that all of Spring projects pulled in will work together seamlessly. If you want to learn more about the Spring portfolio, check out What Is Spring by HeroDevs’ Engineering Director at SpringOne from his time on the OSS Spring team.

‍

CVEs in Spring

Because Spring is a portfolio of projects, a security vulnerability (CVE) can be reported in any of the projects. At the most granular level, a single artifact has a vulnerability that needs to be remediated. Given the nature of Spring nesting upon itself, securing the entire Spring portfolio is not as simple as updating a single artifact.

Let’s take a look at an example of a CVE in OSS Spring and what it means to be secure. Consider CVE-2023-20861 which was published March 20, 2023 against Spring Framework. This CVE was patched by the OSS team in the 5.3.26 release. If you were using Spring Boot at this time, the latest Spring Boot version was Boot 2.7.9. According to the managed dependency documentation (search for ‘spring-expression’) for Spring Boot 2.7.9, this version of Spring Boot pulls in Framework 5.3.25 (which has the vulnerability). So while Spring Framework updated their version and patched the vulnerability on March 20, you won’t get that fixed version if you are using Spring Boot 2.7.9. On March 23, Spring Boot 2.7.10 was released and brings in the new Spring Framework version.

‍

Opting In

Note the very short lag between when the CVE was patched in Spring Framework and when the change was pulled into Spring Boot. During this time customers can manually opt in to the Spring Framework version even if they are using an older version of Boot.

Spring Boot releasing 3 days later means that if you choose to do this work it will soon be irrelevant and should be discarded. If you are using Spring Boot to manage your dependencies, simply upgrade the Spring Boot version as it is available and you will not need to worry about version overrides.

‍

HeroDevs Follows OSS Best Practices

HeroDevs takes the same approach as OSS Spring. We do not consider a CVE fully remediated until we provide our customers with secure artifacts at every level. Our NES for Spring product always pulls in other NES for Spring products as dependencies. With this replicated tree structure, we know that no matter what artifact our customers consume Spring at, they will get a fully secure version.

Consider CVE-2025-41242 to see how HeroDevs replicates the best practices established by the OSS Spring team. HeroDevs remediated this CVE in our release 5.3.47 on Aug 15 (3 days before it was published on security databases). At this point, we could technically consider this security issue resolved, but that is not what the OSS Spring team would do, and it is not what Spring customers expect. HeroDevs released all Spring artifacts that depended on this newly published dependency. This particular CVE was at the base of the Spring stack, so we essentially re-released our entire Spring portfolio, across multiple versions, just to remediate a single CVE. Consider NES for Spring Boot version 2.7.28 and many other projects released on Aug 25 to see how this CVE remediation is pulled in no matter how you consume Spring.

This is routine practice for HeroDevs. A single CVE often triggers the need to release thousands of artifacts. That’s where HeroDevs' release automation ensures that our Spring customers get the same high level of quality that is expected from OSS Spring at HeroDevs.

This level of commitment to upholding the same high standards set by the OSS Spring team comes at a cost. It’s something that HeroDevs fully commits to. Over half of our Java engineering team worked on open source Spring at VMware / Broadcom. We’ve taken the high standards that the community expects and we bring the same best practices to HeroDevs.

Summary

At HeroDevs, we don’t consider a CVE fully remediated until we release every Spring artifact in the dependency tree. This is a lot of work, but we think it’s the right thing to do for our customers. We can provide a fully secure, drop-in replacement for OSS Spring no matter what package you pull into your build.

‍