HeroDevs Never-Ending Support (NES) for Spring Boot Managed Dependencies

What a Spring Boot managed dependency actually is

Every Spring Boot application sits on three different layers of code. There is the code your team writes. There are the libraries you declare in your build, plus the ones those declarations quietly pull in on their own (indirect or transitive dependencies). And underneath both of those, there is the set of versions that Spring Boot pins for you through its dependency management, specifically the spring-boot-dependencies Bill of Materials (BOM).

That pinned set is what a managed dependency in Spring is. When you adopt a Spring Boot version, you inherit Spring's chosen version of every library in that BOM, whether or not you ever name it in your own pom.xml or build.gradle. It is a fixed list of independently maintained open source projects, most of them owned by their own communities rather than by Spring, version-locked so they work together. Spring Boot 2.7 alone pins the versions of more than a thousand such artifacts, many of which you would recognize: the embedded servlet container, the JSON library, the persistence layer, the networking stack.

Managed is not the same as indirect, though a single library is usually both. Indirect (transitive) is about how a library got into your app: something you declared pulled it in. Managed is about who set its version: for anything in the BOM, that is Spring. Add spring-boot-starter-web to stand up a REST API, for example, and it quietly pulls in Jackson, the JSON library, and pins the version for you. You never wrote "Jackson" in your build, and you never chose the version, yet it is in production and Spring decided which one you got. That is what makes remediation different: you cannot fix a version Spring controls the way you fix a library whose version you set yourself.

And many of those pinned versions are not safe to sit on. In both Spring Boot 2.7 and Spring Boot 3.5, dozens of managed projects ship with a known CVE at the version the BOM pins, and many no longer receive upstream security fixes, so no fixed version exists to upgrade to. (HeroDevs analysis of the Spring Boot 2.7 and 3.5 dependency BOMs, October 2026: 200+ known CVE findings across the 2.7 managed dependencies and ~67 across 3.5, at the pinned versions.)

Why a CVE in an unsupported managed dependency has no clean fix

For as long as a managed project is actively maintained, this system is a gift. Spring does the compatibility work and you get a coherent, tested set of versions. The problem starts when your Spring Boot line no longer receives updates and a project in its BOM no longer receives security fixes either.

Here is how it surfaces in practice. Someone discloses a CVE against that library's version. Your security scanner (a software composition analysis, or SCA tool) walks your dependency tree, matches the version Spring pinned against the public CVE databases, and flags it. The finding is more than a line in a scanner report: the vulnerable library version is running in your production application, and your team is on the hook to remediate the finding. Three things collide at that point. The project has no upstream security fix, because it is end-of-life. Your Spring Boot BOM still pins the vulnerable version. And bumping that single library on your own fights the BOM and steps outside the version set Spring tested, which is the kind of change that breaks in ways that are hard to trace. 

The clean answer would be to upgrade Spring Boot itself, but that is frequently a major migration, including the javax to jakarta namespace change when moving off the 2.x line. So the finding sits there, quarter after quarter, with no free path to close it. New findings add to the list, because each CVE disclosed against that library version arrives with no upstream fix.

Spring Boot 2.7 and 3.5 are both in this position now. Teams still running either line are carrying managed-dependency CVEs in production with no upstream fix.

What HeroDevs now covers

If a managed dependency in your Spring Boot application is past end-of-life and has a known CVE, NES covers it. You get a remediated version at the same Maven coordinates you already use, so the finding clears without upgrading Spring Boot or overriding the versions it pins.

If a dependency is still maintained upstream, you do not need us; the fix is a normal upgrade. NES is for the dependencies that have run out of that option. Coverage is rolling out across both the Spring Boot 2.7 and 3.5 lines.

How to find out if your library is covered

The fastest way to see where you stand is to run your project through EOL Dataset, HeroDevs' free end-of-life scanner. Point it at your pom.xml or build.gradle and it returns every end-of-life dependency in your stack, the CVEs against them, and the remediation path. Anything it flags as end-of-life with a known CVE is a candidate for NES. To confirm coverage for a specific dependency, search the HeroDevs Vulnerability Directory for the CVE, or talk to us and we'll check it against the version your BOM pins.

How the fix is delivered

Coverage arrives as a drop-in replacement at the original Maven coordinates, designed to require minimal or no code changes in most environments. You do not change your Spring Boot version and you do not restructure your build. As new CVEs are disclosed against a covered  dependency, remediated versions follow on a regular release cadence.

Who this is for

If you are an engineer resolving CVEs in Spring Boot 2.7 or 3.5 applications, or a security analyst keeping those applications compliant, NES coverage for managed dependencies is for you. Your scanner is flagging CVEs in libraries Spring Boot pins for you, and some of those libraries no longer receive security fixes. The clean fix is a Spring Boot upgrade, and a major-version migration will not finish on your auditor's timeline.

Each CVE in an unsupported managed dependency is vulnerable code running in your production application. The CVE is also an audit finding. Under frameworks like SOC 2 CC7.1 and PCI DSS Requirement 6, you have to remediate the finding or formally accept the risk, and "the library is end-of-life" is not an answer those frameworks accept.

Spring NES is HeroDevs' support for unmaintained, end-of-life Spring and Spring Boot. If you already rely on it, managed-dependency coverage builds on a relationship you already have. If you are new to NES, it is one more part of the end-of-life Spring problem that now has a clear path forward. Which dependencies are in scope depends on what you run, so the best next step is to tell us about your stack.

Taking action

If your Spring Boot findings include CVEs in managed dependencies and upgrading Boot is not on this quarter's plan, there is now a way to close them without leaving your current version. See NES for Spring for how coverage and the drop-in model work, and check the HeroDevs Vulnerability Directory for the specific CVE in front of you.

• Understanding our Coverage? NES for Spring
• Self Service? Use HeroDevs Vulnerability Directory
• Need More Help? Talk to a Hero

FAQ

• What is a Spring Boot managed dependency? It is a library whose version Spring Boot pins for you through its dependency BOM. You inherit that version when you adopt a Spring Boot release, even if you never declare the library yourself.
• Is a managed dependency the same as an indirect (transitive) dependency? Not quite, and they can overlap. Indirect (transitive) describes how a library got in: your own libraries pulled it in. Managed describes who set its version: Spring did, through the BOM. A library can be both at the same time. Both can carry CVEs, but the one whose version Spring controls is the harder one to fix.
• Do I have to upgrade Spring Boot to fix a managed-dependency CVE? Without NES, usually yes. . Once the library stops receiving upstream fixes, upgrading Spring Boot to a newer line is the only path that stays inside a Spring-tested version set. With NES, no: NES delivers a remediated package at the original coordinates, so you can close the finding while staying on your current Spring Boot version.‍
• Which Spring Boot versions does this cover? Spring Boot 2.7 now, and Spring Boot 3.5 next. Both lines are past open source end of life.‍
• How do I know if my specific library is covered? A managed dependency is eligible when it passes license review, is end-of-life upstream, and has at least one CVE. Search the vulnerability directory for your CVE, or contact us with your Boot version and the flagged artifact for a direct answer.‍
• How is the fix delivered? As a drop-in replacement at the original Maven coordinates, designed for minimal or no code changes in most environments.

‍