GitLab SAST is static application security testing that runs in your CI pipeline and scans source code for vulnerabilities before release. It uses open-source based analyzers on every tier, and an additional Advanced SAST analyzer on Ultimate. Language support is broad but not universal, and some results depend on your tier.
What SAST means here
Static analysis reads code without running it. It looks for patterns that tend to cause injection, unsafe deserialization, weak crypto use and similar flaws. It does not know how your application behaves in production, so it cannot tell you whether a flagged path is reachable by an attacker.
In GitLab, SAST is a CI job. You add the SAST template or component to your pipeline file, and the job runs in the test stage. By default it runs in branch pipelines. Merge request pipelines need extra configuration, which surprises teams that expect findings on every pull request.
Languages and analyzers
According to the GitLab documentation we reviewed, the standard analyzers include a Semgrep-based analyzer with GitLab-managed rules, plus others such as SpotBugs with find-sec-bugs, PMD-Apex, Sobelow and clangsa. Kubesec for Kubernetes manifests and Helm charts is off by default.
| Group | Languages listed |
|---|---|
| Advanced SAST and standard analyzers | C, C++, C#, Go, Java, JavaScript, Objective-C, PHP, Python, Ruby, Swift, TypeScript, limited YAML |
| Standard analyzers only | Apex, Elixir, Groovy, Kotlin, Scala |
| Advanced SAST only (beta) | Dart, Rust |
Check the current page before you commit to a plan, because these lists change between releases.
What changes by tier
Free and Premium tiers get basic scanning and a downloadable JSON report. Ultimate adds Advanced SAST, new findings shown in the merge request report and changes view, vulnerability management, UI based scanner configuration, ruleset customization and advanced vulnerability tracking. If your developers expect inline annotations on changed lines, confirm that your tier includes them.
Limits worth knowing
- Binary files are not scanned, and the Semgrep analyzer has a default maximum file size of 1,000,000 bytes.
- The Semgrep analyzer does not respect
.gitignore. - If another job in the pipeline fails to finish, the security dashboard does not show SAST output.
- Runners must be Linux with the Docker or Kubernetes executor. Windows runners and non AMD64 architectures are unsupported.
- Findings appear on feature branches and become vulnerabilities only after merge to the default branch.
A short setup path
- Confirm you have a Linux runner and a test stage in the pipeline.
- Add the SAST template or component to your CI file, or use the UI on Ultimate.
- Run it on a branch and open the pipeline Security tab.
- Decide whether to enable merge request pipelines so findings arrive before merge.
- Write down which languages in your repos are not covered, so the gap is a known decision and not a surprise.
Where a dedicated scanner fits
Built-in SAST covers many teams well. A separate scanner is worth a look if you need the same checks across several source hosts, or want reachability analysis to separate flagged code from code your app actually calls. Safeguard offers dependency scanning with reachability analysis and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through a code scan and look at how a finding points to a file and line, which is the same shape you will triage in a CI report.
Quick check
Does GitLab SAST run on every merge request by default?
No. The documentation says it runs in branch pipelines by default, and merge request pipelines need additional configuration.
Is SAST the same as dependency scanning?
No. SAST reads your own source code. Dependency scanning checks the third party packages you pull in.
Sources
Last reviewed: 19 October 2026.
