Treat the forward port as part of the hotfix, not a chore for later. Open the main change at the same time, link both, add a regression test to main, and add a release check that fails if a known fix is missing from the branch you are about to ship.
How the bug comes back
The pattern is common. A fix goes onto a release branch under pressure. Main keeps moving. Weeks later main becomes the next release and the vulnerability is back, because nobody copied the change over. Customers who updated to the hotfix, then to the new release, find themselves exposed again.
The Linux stable documentation addresses a related risk. It requires that a fix be present in all newer stable trees still supported before it goes to an older one, to avoid regressions that users hit when updating. The idea generalizes: fixes should only move forward in time, never skip a line.
Steps
- Create a ticket for the forward port when you create the hotfix branch. The hotfix is not done until it closes.
- Cherry-pick the fix to main, or if main changed enough, rewrite it for main. Mention the original commit in the message.
- Add a regression test on main that fails without the fix. Even if the code looks different, the test keeps the behavior.
- Cross link: the hotfix change names the main change, and the main change names the hotfix.
- Add the fix to the changelog's next release section with the same wording.
- Before every release, run the release check described below.
A release check that catches omissions
| Check | How |
|---|---|
| Known fixes are present | Keep a short file of fix IDs or test names per advisory, and require the matching tests to exist and pass |
| Fixed version in the SBOM | Compare the release SBOM against the list of advisories you closed |
| Branch comparison | List commits on the hotfix branch not reachable from main and review each one |
git log --oneline main..release/2.4
Any security commit in that list that is not on main needs an explanation.
Make it a habit
Put the check in the release checklist, not in anyone's memory. A person who is rushing at the end of a release will not recall a hotfix from six weeks ago. A script will.
When main changed the code a lot
If the vulnerable code no longer exists on main, say so in writing. Link the commit that removed it, and still keep a test for the behavior. Without that, a future refactor could reintroduce the same class of bug.
Try it yourself
Click through it at your own pace, or open it full screen. Look at where a failing check stops a merge, the same mechanism that can stop a release missing a known fix.
Safeguard policies and gates can block a change that introduces a component with a known vulnerability, which helps catch a returning issue at the pull request. A free scan is at gold.safeguard.sh/scan.
Quick check
Who owns the forward port?
The person who owns the hotfix. Close the ticket only after the main change is merged.
What if the code on main is already different?
Document it, link the commit that removed the old code, and keep a behavior test so the issue cannot return.
Sources
Last reviewed: 19 October 2026.
