GitLab ships several scanners that each answer a different question. SAST reads your code, secret detection looks for credentials, dependency scanning checks packages, container scanning checks images, IaC scanning checks infrastructure files, and DAST tests the running app. Together they run in CI and report into merge requests.
The map
| Scanner | Question it answers | Looks at | Tier notes from the docs |
|---|---|---|---|
| SAST | Is our own code flawed? | Source code | Basic on all tiers, Advanced SAST on Ultimate |
| Secret detection | Did a credential get committed or pasted? | Commits, pipelines, issue and merge request text | Free, Premium, Ultimate |
| Dependency scanning | Do our packages have known flaws? | SBOM of dependencies | Ultimate |
| Container scanning | Does the image carry known flaws? | OS packages, optional language packages | Core scanning on all tiers, more on Ultimate |
| IaC scanning | Are our infrastructure files misconfigured? | Terraform, Kubernetes and others | Scanning on all tiers, merge request views on Ultimate |
| DAST | Can the running app be attacked? | A deployed web app or API | Ultimate |
Always confirm tiers on the live pages, because they change.
How results are shown
GitLab says scans run automatically in CI/CD pipelines on commits or merge request creation, and can be run on demand or on a schedule. Findings appear in merge requests, the pipeline Security tab and, after merging to the default branch, the vulnerability report.
Controls around the scanners
Scan execution policies make sure scans run. Merge request approval policies require sign-off when findings match a rule. Both are Ultimate features. Without them, a project owner can quietly drop a scanner from a pipeline.
What the map does not include
- Reachability. The dependency scanning page we reviewed does not mention it.
- Runtime protection. These scanners run before or beside deployment, not inside production.
- Cross-host views. They cover projects in GitLab.
How to pick a first three
For most teams the sequence is secret detection first, since a leaked key is urgent and cheap to find. Dependency scanning second, since most code you ship is not yours. SAST third, since it needs tuning to be useful. Add container, IaC and DAST as your delivery pipeline matures.
A one-week pilot
- Enable secret detection and dependency scanning on one project.
- Read the results with a developer present.
- Add SAST and review noise.
- Write down which findings you would fix this week and which you accept.
- Decide what to enforce with a policy.
Where a dedicated scanner fits
A separate platform helps when you want these answers across several hosts in one place. Safeguard offers SBOM and dependency scanning, reachability analysis, DAST and API scanning, and policies, plus a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
See how findings from different scanner types land in one triage queue.
Quick check
Which scanner should I turn on first?
Many teams start with secret detection, then dependency scanning, because leaked credentials and vulnerable packages are common and quick to act on.
Do all these scanners need Ultimate?
No. Some scanning is available on lower tiers, while merge request views, policies and several others need Ultimate.
Sources
- GitLab Docs: Application security
- GitLab Docs: SAST
- GitLab Docs: Secret detection
- GitLab Docs: Dependency scanning
- GitLab Docs: Container scanning
- GitLab Docs: IaC scanning
- GitLab Docs: DAST
- GitLab Docs: Policies
Last reviewed: 19 October 2026.
