Stay on a supported Spring Boot line, let the Boot BOM manage versions, override only with a recorded reason, inventory what your JAR ships, and gate known vulnerable versions in CI. Review it on a schedule, not only when an advisory makes the news.
Checklist
1. Stay on a supported line. The Spring Boot support policy says major versions are supported for at least 3 years from release, and minor versions for at least 12 months, with commercial support offering an extended period. It also says you must run a supported minor version. Check the current support dates on the Spring site before you decide an upgrade can wait.
2. Let the BOM manage versions. Spring Boot publishes the spring-boot-dependencies BOM, so you normally declare no version for managed libraries. Upgrading Boot moves the managed set together.
3. Do not override the Spring Framework version. The documentation highly recommends that you do not specify it, since each Boot release has a base version.
4. Override other versions only for a reason. Use the version property from the appendix, for example log4j2.version, add a comment naming the advisory, and remove it once a Boot upgrade makes it redundant. Steps: override a managed version.
5. Use official starters. Official starters follow the spring-boot-starter naming pattern. Third-party starters should not start with spring-boot, which is reserved. Treat a starter whose name breaks that rule with extra care.
6. Lock down Actuator. Know which endpoints are exposed. See Spring Boot Actuator exposure.
7. Inventory the archive. List BOOT-INF/lib on every release and store it. See what is inside a Spring Boot JAR.
8. Run a scanner and a gate. Scan every pull request, and block merges that add a known vulnerable version. Keep an exception process with expiry dates.
9. Check the tree, not just the POM. Use the build tool's tree output, see why is this dependency on my classpath.
10. Keep the base image and JDK current. Library hygiene does not cover the runtime underneath it. Track the JDK and container base image as separate assets.
How often
| Task | Suggested rhythm |
|---|---|
| Scan on pull request | Every change |
| Review overrides | Monthly |
| Upgrade Boot patch version | Regularly, with tests |
| Check support dates | Each quarter |
| Full inventory export | Each release |
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how new advisories are matched against a project that has already been scanned. That is the monitoring step in the checklist.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis, and policies and gates for pull requests. Autonomous remediation can open fix pull requests, and it is off by default. Try the free scan.
Quick check
How long is a Spring Boot minor version supported?
The project's policy says at least 12 months, and you must run a supported minor version. Confirm current dates on the Spring site.
Should I pin every transitive library myself?
No. Let the BOM manage them, and override only the ones you have a documented reason to change.
Sources
Last reviewed: 19 October 2026.
