GitLab security results go missing for a few documented reasons: the scan only runs in branch pipelines, another job in the pipeline failed, findings have not merged to the default branch yet, the runner is unsupported, or the file type is skipped. Work through the checklist below in order.
Check 1: did the scan run on this pipeline?
The SAST documentation says it runs in branch pipelines by default, and merge request pipelines need additional configuration. If you look for findings in a merge request and see nothing, the job may simply not have run in that pipeline type.
Check 2: did another job fail?
The SAST and DAST pages both state that if any other job in the pipeline fails to finish, the security dashboard does not show that scanner output. A failing unit test stage can therefore hide a clean scan. Fix or isolate the failing job, then rerun.
Check 3: has the code reached the default branch?
Findings appear on feature branches and become vulnerabilities in the report only after the code merges to the default branch. The vulnerability report shows cumulative results from successful scan jobs on that branch.
Check 4: is the runner supported?
SAST needs a Linux runner with the Docker or Kubernetes executor. Windows runners and architectures other than AMD64 are unsupported. IaC scanning also lists a minimum of 4 GB of RAM.
Check 5: is the content in scope?
| Scanner | Skipped or conditional |
|---|---|
| SAST | Binary files; Semgrep default max file size 1,000,000 bytes; ignores .gitignore |
| IaC scanning | Terraform modules from custom registries; Bicep until converted |
| Container scanning | Language packages unless enabled; OCI tarballs |
| Any | Languages the analyzer does not list |
Check 6: does your tier include the view?
Some results views are Ultimate only, such as new findings in the merge request report and downloadable results. Free and Premium tiers can still produce a JSON report artifact, so check the job artifacts before assuming nothing ran.
Check 7: is a policy interfering?
Merge request approval policies treat missing reports as a reason to require approval. If merges are blocked with no visible finding, check whether a required scanner produced a report on both source and target branches.
Prevent the next surprise
Add one known weak sample file to a test repository and keep it as a canary. If the canary stops producing a finding, your pipeline wiring changed. That is cheaper than discovering a gap at audit time.
Where a dedicated scanner fits
A separate scanner that reads the repository directly does not depend on your CI stages passing. Safeguard offers SBOM and dependency scanning, and a free scan at gold.safeguard.sh/scan lets you compare results against what your pipeline reports.
Quick check
Can a failed test job hide security results?
Per the GitLab SAST and DAST documentation, yes. If another job in the pipeline fails to finish, the security dashboard does not show that scanner output.
Where do I look if the Security tab is empty?
Check the scan job's artifacts. Even without the full view, the job produces a JSON report.
Sources
- GitLab Docs: SAST
- GitLab Docs: DAST
- GitLab Docs: IaC scanning
- GitLab Docs: Container scanning
- GitLab Docs: Merge request approval policies
Last reviewed: 19 October 2026.
