When a security fix exists only in a new major version, check three things first: whether the vulnerable code is reachable in your app, whether your current line is still supported, and how big the migration is. Jump if the line is unsupported, backport or mitigate if you need time and the risk is real.
Why this happens
Projects often fix security issues on the supported lines. Support policies say which those are. Spring Boot's page says it supports major versions for at least three years if you run a supported minor. Rails says security fixes cover two years per minor series. Go supports its two newest majors. If your line is outside those windows, a fix may exist only in a newer release.
The decision
| Question | If yes | If no |
|---|---|---|
| Is your current line still supported? | Wait for a fix on your line, or ask the maintainers | A jump is the default |
| Is the vulnerable code reachable? | Treat as urgent | Schedule normally, document |
| Is a compatible patch release available? | Take it | Consider options below |
| Is the migration small? | Jump | Consider interim controls |
| Is there a safe mitigation? | Apply it while migrating | Escalate the migration |
Reachability changes everything. A critical advisory in a function your code never calls is a different problem from one in your request parser.
Options in order of preference
- Take a patch or minor release on your line. Check the supported versions page first. Many projects do backport.
- Jump to the fixed major. Plan it as a proper upgrade with gates, not an emergency edit. If you are several majors behind and the tool supports it, go one major at a time.
- Backport the fix yourself. Only with a clear patch from the maintainers and a person who understands the code. You then own that fork, and every future fix.
- Mitigate. Disable the feature, add a validation layer, restrict network access, or set a configuration flag the advisory describes. Record the mitigation and an expiry.
- Accept the risk temporarily. Write down the owner, the reason and a review date.
Backporting has hidden costs
A private backport must be rebuilt, tested and maintained. You also lose the ability to take the project's later patches cleanly. Many teams underestimate that and end up on a fork that is worse than the original problem. Use it as a bridge with a date, not a destination.
Record the decision
For each case, store: advisory ID, affected component, reachability result, chosen option, owner, date and next review. If you issue VEX statements, a not affected or fixed status should match the evidence you have. This is also what an auditor or a customer asks for later.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how reachability separates findings you must act on from ones you can schedule.
Quick check
Should I always jump to the fixed major?
Not always. If the code is unreachable and your line is supported, scheduling the move can be reasonable. If your line is unsupported, jumping is the default.
Is a private backport a good long-term plan?
No. It makes you the maintainer. Use it as a short bridge with an end date.
Safeguard's reachability analysis shows whether a vulnerable function is called in your code, and its fix pull requests, which are off by default, can propose the upgrade for review. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
