Choose the patched version in the release series you already run, because it changes the least. Move to a newer series only if you have planned and tested that larger upgrade. An advisory that lists several fixed versions is offering one fix per supported line.
Why there are several
Projects that support more than one release series backport fixes to each. Django's policy says it provides security support for several versions at a time: the main branch, the two most recent release series, and long-term support releases for a specified period. Go says security fixes are backported to scheduled minor releases. When a flaw is fixed, each supported line gets its own patched release.
GitHub describes an advisory as having affected versions and patched versions, so a single record can list a fix per line.
Reading it
Suppose a record shows affected ranges and fixed versions for three lines. Find the line that matches your current version, then take the fixed version for that line.
| You run | Pick | Why |
|---|---|---|
| A version on line A | The patched release on line A | Smallest change, usually no new features |
| A version on a line with no patch listed | A supported line with a patch | Your line may be unsupported |
| An older line plus a planned major upgrade | The target line's patched version | Skip the intermediate step if the plan is tested |
The middle row links to our post on advisories that list only supported versions.
Steps
- Note the version you run, from the lockfile, not the manifest.
- Open the advisory and find the patched version on your line.
- Check release notes between your version and the patched one for deprecations and removals.
- Upgrade in a branch, run tests, and rescan.
- Record the version you landed on.
Why the smallest jump is usually right
A patch release on your own line is the most conservative change the project offers. Semantic versioning, where used, signals that patch releases are compatible. Moving to a newer minor or major series adds behaviour changes that you would need to test, and a security deadline is a poor moment to absorb them. Our post on security fixes and semver breaking changes explains the exceptions.
When the same line has no fix
If your line is unsupported, you must change lines. Treat it as a planned upgrade and set a deadline. While you work, apply any documented workaround and limit exposure.
Checking the result
After the upgrade, check that your lockfile resolves to the patched version and that no other path still pulls the old one. A transitive copy can hide. Rescan the whole repository, not just the direct dependency.
Where Safeguard fits
Safeguard's dependency scanning shows the resolved version in each repository and links findings to fixed versions, and fix pull requests are available when you opt in to autonomous remediation. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and compare the fixed version it offers with the one you run.
Quick check
Can I just take the highest patched version?
You can, but it may bring larger changes. The patched release on your own line is usually the smaller step.
What if my version appears in no line?
Your line may be unsupported. Plan an upgrade to a supported line and treat the exposure as unknown until then.
Sources
Last reviewed: 19 October 2026.
