Scan the default branch and every release branch you ship from, because they represent what runs in production. Scan pull request branches to catch new risk before merge. Skip stale feature branches, since they add noise and cost without telling you anything about what you deploy.
Match the branch to the question
| Branch type | Question it answers | Scan it? |
|---|---|---|
| Default branch | What is our current baseline? | Yes, on every merge and on a schedule |
| Release or maintenance branches | What did we ship, and what do we still support? | Yes, on a schedule, for as long as they are supported |
| Pull request branches | What does this change add? | Yes, only the difference where possible |
| Long lived feature branches | What might arrive later? | Optional, on a schedule |
| Stale or abandoned branches | Nothing useful | No |
Why not scan everything
Scanning every branch inflates your finding count. The same vulnerable package appears once per branch, and the same dependency problem is reported many times. That makes metrics worse and tickets noisier.
It also costs time. Scans that run on every push of every branch slow pipelines and use quota for little benefit.
Why not only the default branch
A default branch only scan finds problems after they merge. A pull request check finds them while the author still has the context. For release branches, a vulnerability disclosed next month matters just as much to the version customers run as to your newest code.
Deduplicate findings
Make sure your tool can group the same finding across branches and show which ones it affects. Track it as one issue with several affected branches, not several issues. If the tool cannot do that, restrict scanning to the branches that matter.
A practical setup
- Pull request check on the changed dependencies, report-only at first.
- Scan on merge to the default branch.
- Scheduled rescans of the default and each supported release branch, so new advisories are caught without a new commit.
- A monthly list of branches with no activity, and a decision to delete or ignore them.
- Tag each release with its stored inventory, so you can answer "did we ship it" later.
Edge cases
Hotfix branches and forks from outside contributors may need special treatment. For fork pull requests, avoid giving scan jobs access to secrets, and prefer a read-only scan that reports without elevated permissions.
A worked example: a team with three kinds of branches
A product team has a default branch, two supported release lines for enterprise customers, and about thirty feature branches at any time.
The team sets up four things. First, a pull request check on changed dependencies. Second, a scan on every merge to the default branch. Third, a nightly scheduled recheck of stored inventories for the default branch and both release lines. Fourth, a monthly review that lists feature branches with no commits in sixty days.
After a month, the findings list shows each vulnerable package once, with a note that it affects the default branch and one release line. Before the change, the same package had appeared on forty branches and inflated the count to a number nobody trusted.
Step by step: choose your branch scanning policy
- List the branches that build production artifacts. These must be scanned.
- List the branches that customers run, including old release lines. These must be rechecked on a schedule.
- Configure pull request scans to look at the diff in dependencies where your tool supports it.
- Decide a rule for long lived feature branches: scan on a schedule, or only at merge.
- Set a clean up rule for stale branches and stick to it.
- Configure deduplication, so one vulnerable package yields one issue with a list of affected branches.
- Store the inventory for each tagged release, so you can answer questions about past versions.
- Review the policy when your release process changes.
Cost and time considerations
Each scan uses CI minutes and the vendor's quotas. A diff based pull request scan is usually quick, while a full resolution of a large tree can take longer. Measure on your largest repository and set time budgets so scans do not slow merges beyond what developers will accept. If a scan is too slow, move it from blocking to advisory and run it in parallel.
Release branches and customer commitments
If you commit to supporting a release line, the vulnerabilities in it become part of that commitment. A scheduled recheck on those lines helps you notice when a patch release is needed. Keep a table of supported lines, their end dates, and who owns them, and drop a line from scanning only when support formally ends.
Forks and outside contributions
For pull requests from forks, give scan jobs no secrets and only read permissions. Report results as a comment or status rather than letting untrusted code reach credentials. This applies to dependency changes in outside contributions, which deserve a look because they can introduce new packages.
Monorepos
In a monorepo, branches apply to the whole repository, but dependency changes touch one or two packages. Scanning only the changed workspaces keeps pull request checks fast, while scheduled scans cover everything on the default branch.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice that the check focuses on what the pull request changes, which is the idea behind scanning the difference.
Quick check
Do I need to scan old release branches?
If customers still run them, yes. New advisories affect old versions too, and you may owe those customers an answer.
Will scanning more branches find more real problems?
Mostly it finds the same problems repeatedly. Prefer fewer, well chosen scans with deduplication.
How do I count a finding that appears on several branches?
Count it once as a single issue and list the affected branches. Counting per branch inflates metrics and creates duplicate tickets.
Last reviewed: 19 October 2026.
