Include both. The default branch shows the risk you are building toward, and the release branches show what customers or production run right now. Scanners can behave differently on old branches, where lockfiles, ecosystems and versions are older and findings are more numerous.
Two different questions
When you scan the default branch, you ask: what should we fix before the next release? When you scan a supported release branch, you ask: what is exposed in versions that are still in use?
Teams that ship software to customers, or maintain several versions, need the second question answered. A scanner that handles only the latest code will understate that risk. This is easy to overlook in a trial, because most examples use a single branch.
What changes on older branches
| Feature of an older branch | Effect on a scanner |
|---|---|
| Older package manager or lockfile format | May be unsupported or parsed differently |
| Older dependency versions | More findings, more fixed advisories |
| Pinned and vendored copies | Harder to identify |
| Different build tooling | Resolution differs from the default branch |
| Backported fixes | Version strings may not tell the whole story |
Backports deserve a special note. When a maintainer backports a security fix to an older release line, the fixed version may carry a number that looks affected. Tools that rely on version ranges only can disagree on such cases, so review them by hand using the advisory text. See how a scanner decides your version is affected.
How to add release branches to your test
- List the release branches or tags you still support. Pick one or two, such as the most recent and the oldest.
- Freeze each at a commit SHA, as in the freeze procedure.
- Scan with every candidate using the same settings.
- Compare inventories first, then findings.
- Report the release branch results as their own group.
Treat each branch as its own test case. A tool that handles the default branch well and an old branch poorly has a gap you can quantify.
Questions to ask while reviewing
- Did the tool recognize the lockfile format on the old branch?
- Does it track findings per branch, or merge them into one view?
- Can you see which release a finding affects?
- Are fixes suggested in a form that applies to the old branch, such as a patch release in the same major line?
The last point matters. A suggestion to jump two major versions helps the default branch but is useless for a maintenance branch that can only take a patch.
Keep the volume in context
Old branches generate many findings. Do not use raw counts to say a tool is noisy there. Compare after adjudication, as in deciding on findings only one scanner reports. A large number of true findings on an old branch is accurate, not noise.
When you do not maintain old branches
If you deploy only from one branch, with continuous delivery, skip release branches. Instead, test a branch or tag from a few months ago to simulate neglect, which shows whether a tool copes with accumulated drift. See the back test post for a related technique.
Safeguard's dependency scanning and SBOM generation operate on repositories you point them at, so you can scan a release branch separately. The free scan at gold.safeguard.sh/scan is a quick start for one branch.
Quick check
Do I need every release branch?
No. The newest and the oldest supported branch usually show the range.
Why do old branches show more findings?
They run older dependency versions, which have had more time to collect advisories.
Last reviewed: 19 October 2026.
