By default update bots work on the default branch only. GitHub states that Dependabot security updates always use the repository's default branch, even if you set a target branch for version updates. So a vulnerable dependency on a supported release branch needs a deliberate backport plan, not a hope.
What the documentation says
GitHub's Dependabot options reference explains the target-branch setting. By default Dependabot uses the repository's default branch. When you define a target branch, only manifest files on that branch are checked for version updates, and all version update PRs target it. The reference then adds that options defined for the package ecosystem no longer apply to security updates, because security updates always use the default branch.
Read that twice. Setting a branch for version updates does not give you security PRs on that branch. Other tools have their own branch settings, and you should read the documentation for yours rather than assuming it matches.
Why release branches matter
If you support more than one version of a product, a vulnerability in a shared dependency affects each supported line. The fix on main helps only people who upgrade to main. Customers on a maintained older line need the fix on that line.
A four step plan
- List the supported branches. Write down which branches you promise to patch, and for how long.
- Scan each of them. A scan of main tells you nothing about a release branch with a different lockfile. Scan every supported line on a schedule.
- Decide per branch how fixes arrive. Options: a second bot configuration with a target branch for version updates, a manual backport of the main branch fix, or a scripted cherry pick that opens a PR for review.
- Review like any other PR. A backport changes an older code base. Run that branch's tests, not main's.
Options compared
| Approach | Good for | Watch out for |
|---|---|---|
| Bot configured for the release branch | Routine version updates on a stable line | Does not cover security updates in Dependabot, per the docs |
| Manual backport of the main fix | Rare, high value fixes | Relies on people remembering |
| Scripted cherry pick with a PR | Several supported lines | Conflicts need a human |
| Upgrade customers instead | Lines at end of life | Needs a communication plan |
Cherry picks and provenance
When you backport by cherry pick, keep a record of where the change came from. See cherry pick with x: record where a backported patch came from and cherry pick conflict when backporting a security fix. To judge whether a distribution's backport really fixes the issue, see fixed version or backported fix: how to judge a patch.
Say what you support
Publish a support policy so users know which branches get fixes and for how long. Without it, every vulnerability becomes a debate about which lines count. An honest end date is better than an unclear promise.
Try it yourself
Open the demo and look at how findings are tracked per project. Imagine one project entry per supported release branch.
Click through it at your own pace, or open it full screen.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Can I point Dependabot security updates at a release branch?
GitHub's documentation says security updates always use the default branch, so plan a backport instead.
Is scanning main enough for a product with several supported lines?
No. Each line has its own dependency versions, so scan each supported branch.
Sources
Last reviewed: 19 October 2026.
