Two branches can each pass a security scan and still fail once combined, because the target branch moved or the changes interact. Scanning the merged result, with a merge queue or a merged results pipeline, catches what a branch-only scan cannot.
The gap
A normal pull request scan checks the branch as the author left it. Meanwhile, the main branch keeps moving. By the time you merge, the code that lands is the combination of your branch and whatever has changed since you branched.
For security checks, the interaction can matter. Examples:
- Your branch adds a package, and another merged change adds a different version of the same package.
- Someone removes a version pin on main while your branch relies on it.
- A policy file changes on main, and your branch now violates it.
Each branch looked fine alone. The merge produces something neither scan saw.
Two mechanisms
GitLab documents merged results pipelines, which run a pipeline that tests the result of merging the source and target branches together. GitHub lists a merge queue among its branch protection settings, and its workflow trigger list includes a merge_group event, which lets checks run for queued changes.
Both aim at the same goal: test what will actually land.
| Approach | What it checks | Cost |
|---|---|---|
| Branch-only pull request scan | The author's branch | Lowest |
| Merged result scan | Branch combined with target | Higher, more runs |
| Scan on the default branch after merge | The shipped state | Finds problems late, no block |
When it is worth the cost
Merged result scanning adds pipeline runs, which matters on busy repositories. Use it where the risk justifies it:
- Repositories that many people change daily.
- Services where a bad dependency state reaches production fast.
- Repositories with generated files or lockfiles that conflict often.
For low-activity repositories, a branch scan plus a default branch scan is usually enough.
Steps to adopt it
- Pick one busy, important repository as a pilot.
- Enable your platform's merged result or merge queue option.
- Make sure the scan job is configured to run for those events. Check the trigger names in the platform documentation, because a job that only listens to the plain pull request event will not run in the queue.
- Compare results for a few weeks, counting how often the merged scan failed when the branch scan passed.
- Expand if the number justifies the cost.
Keep the default branch scan anyway
Even with merged result checks, scan the default branch after each merge. It records the shipped state and feeds scheduled rescans, and it catches anything that slipped past through an admin bypass.
Where Safeguard fits
Safeguard's dependency scanning and policy gates can run wherever you place the job, including on the events your platform uses for merge queues. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Is a merge queue the same as a merged results pipeline?
They share the aim of testing the combined result, but they are platform features with different mechanics. Check your platform documentation.
Does this slow merges?
It can add time per merge. Use it on busy, important repositories and keep fast checks first.
Sources
- GitLab Docs, Merge request pipelines
- GitHub Docs, About protected branches
- GitHub Docs, Events that trigger workflows
Last reviewed: 19 October 2026.
