Patch every release line your support policy says is supported, and the current line first. Map the first and last affected versions during validation, backport the smallest safe change, and state in the advisory which versions are fixed and which are not. Say plainly if an old line will not get a patch.
Start with the version map
During validation, find the first release that contains the flaw and the last that does. Check by testing, not by reading the changelog. If the code was refactored, the flaw may have appeared in a later release than you think, or existed in a different form earlier.
| Release line | Affected? | Supported? | Decision |
|---|---|---|---|
| 5.x (current) | Yes | Yes | Patch |
| 4.x | Yes | Yes, security fixes | Backport |
| 3.x | Yes | No | Advise upgrade |
| 2.x | Not tested | No | Test or state unknown |
Decide using your support policy
If you have a written support policy, apply it without exceptions you would not explain publicly. If you do not have one, this is a good moment to write it: which lines get security fixes, and for how long. Customers on an unsupported line deserve clear advice, not silence.
Backport carefully
- Keep each backport to the minimum change.
- Test on the older line with its own dependencies, not just on the current one.
- Resist adding features to a security release.
- Use the same advisory for all lines, listing each fixed version.
If you use GitHub security advisories, the documentation says to add a fix version before publishing. Without it, Dependabot alerts users without suggesting a safe version. It also notes that if no fix is planned, the advisory should say so and ideally include mitigation steps.
State the facts in the advisory
List:
- Affected version ranges.
- Fixed versions for each supported line.
- That unsupported lines are affected and not patched, if true.
- Any workaround for people who cannot upgrade.
Do not write "all versions" unless you tested them. Do not write "no impact on older versions" unless you checked.
Limits and risks
Backporting costs time and creates its own risk, since each line has a different codebase. For a small team that is a reason to keep supported lines few. It is also a reason to make upgrading easy, so that customers are on the current line.
Try it yourself
The fix available now demo shows how a fixed version becomes visible to people who consume your software. Click through it to see why the version fields in your advisory matter to them.
Click through it at your own pace, or open it full screen.
Quick check
What if a customer is stuck on an unsupported line?
Tell them clearly that no patch is planned and give any mitigation. Be honest about the limits of what you can offer.
Do we need separate advisories per line?
Usually one advisory with several fixed versions is clearer.
Safeguard's SBOM and dependency scanning help your customers and you see which version of a component is deployed where. The free scan is at gold.safeguard.sh/scan.
Sources
- GitHub Docs, about repository security advisories
- GitHub Docs, publishing a repository security advisory
Last reviewed: 19 October 2026.
