A security scan job runs in a GitLab merge request pipeline only if its rules match the merge request event. A scan that runs on branch pushes will not necessarily run on the merge request. Define the rules directly in the CI file, and consider merged results pipelines to test the combined code.
The basic requirement
GitLab's documentation says merge request pipelines need job rules or workflow rules in the CI configuration that match the pipeline source equal to merge_request_event. It also says the rules must be defined directly in the project's CI file. Rules defined in included files do not satisfy the requirement, for example those coming from a component.
That last detail catches teams who centralize their scan template. The template can supply the job, but the project file must still carry matching rules or workflow rules.
What changes for a scan job
Without merge request rules, a job runs on pushes to a branch. That feels equivalent until you notice the differences:
- A push pipeline has no merge request context, so a scan cannot easily compare to the target branch.
- A merge request pipeline ties results to the review, so they appear where reviewers look.
- Duplicate pipelines can appear if both push and merge request rules match. Use workflow rules to choose one.
Merged results
GitLab also offers merged results pipelines, which test the result of merging the source and target branches together. For a security scan, this closes a gap: two branches can each be clean and still combine into a vulnerable state, such as one adding a dependency and the other removing a pin.
If scanning the combined state matters to you, use merged results for the scan job and keep the cheaper checks on the plain merge request pipeline.
A setup checklist
- Add workflow rules that run pipelines for merge request events and for the default branch, and avoid running both for the same commit.
- Add rules to the scan job that match the merge request event.
- Confirm that included templates do not carry the only copy of the rules.
- Check the required roles. The documentation says you need the Developer, Maintainer, or Owner role on the source project to run a merge request pipeline, which affects first-time contributors.
- Open a test merge request and verify the scan job appears.
- Decide whether the scan job is allowed to fail or must pass, and set merge requirements to match.
When the scan should run on the default branch too
Keep a scan on the default branch. It records the state of what shipped and gives the scheduled rescan something to compare to. The merge request scan is about preventing; the default branch scan is about keeping a record.
Where Safeguard fits
Safeguard's CLI (1.4.0 on the download page, installed with a curl or PowerShell script) can run in any CI job, including GitLab, and policies and gates decide pass or fail. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Why does my scan not appear on the merge request?
Most often the job has no rule matching the merge request event, or the only matching rule sits in an included file. Define the rule directly in the project CI file.
What is a merged results pipeline?
It is a pipeline that tests the result of merging the source and target branches together, instead of the source branch alone.
Sources
Last reviewed: 19 October 2026.
