AppSecNews
SAST Open source Established

GitLab SAST

by GitLab

Pipeline-native static analysis for GitLab that runs containerized analyzers per language and reports findings on merge requests.

Visit docs.gitlab.com (leaves AppSecNews, opens in a new tab) Leaves AppSecNews for the vendor's own site.

No endorsements yet

Run GitLab SAST in production? A named recommendation helps the next team shortlisting it.

Recommend this tool

Endorsers verify their identity through LinkedIn. Titles and companies are self declared, shown as they were when each person signed, and reviewed by an editor before anything is published. Endorsements are never paid for.

What we still need to verify : 1 point in this profile is not yet confirmed against vendor documentation.
  • Which analyzers are current versus deprecated, and which features require a paid tier: confirm with vendor docs

Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.

What it does

GitLab SAST is a set of containerized analyzers invoked by a CI template you include in your pipeline. The job inspects the repository, detects which languages are present, and runs the matching analyzer images. Historically this meant a mix of open-source engines wrapped for GitLab plus GitLab's own Semgrep-based analyzer, which has progressively consolidated coverage for the major languages into one rule engine while language-specific analyzers remain for cases the general engine does not handle well.

Each analyzer emits a normalized JSON report that GitLab ingests. The platform then does the part that makes it useful: it deduplicates findings, tracks their state across pipelines, and on a merge request shows only what is new relative to the target branch. Security policies can require approval before merging when a new finding above a chosen severity appears, and a vulnerability report at the project and group level holds triage state, dismissal reasons and links to issues. Because everything is expressed in the pipeline configuration, the security jobs are reviewed like any other change.

Where it fits

This runs entirely inside GitLab CI, on merge requests and on the default branch. Developers see findings in the merge request widget; security teams work from the group-level vulnerability report and set the merge request approval policies. The prerequisite is simply that you are on GitLab and running pipelines. The free tier produces job artifacts, while the merge request widget, vulnerability management and policy enforcement belong to higher tiers, which shapes how much of the workflow you actually get.

Strengths

  • Zero integration work: include a template and scanning happens, with language detection handled automatically.
  • Merge request diffing means developers see only findings their change introduced, which is the difference between adoption and abandonment.
  • Vulnerability state, dismissals and approvals live in the same system as code review and issues, so there is no separate tool to reconcile.
  • Analyzers are containerized and pinnable, so scans are reproducible and can run in air-gapped installations with a local registry.

Limitations

  • Detection depth is bounded by the underlying analyzers, mostly pattern and light flow analysis, so complex cross-file taint flows are often missed.
  • The valuable parts of the workflow, notably the merge request widget and vulnerability management, sit behind higher product tiers.
  • It only makes sense if GitLab is your platform. There is no meaningful story for repositories hosted elsewhere.

Who it suits

The obvious default for teams already standardized on GitLab who want a baseline security gate without buying and operating another product. Teams with high assurance requirements, or with code outside GitLab, should expect to supplement it with a deeper dedicated scanner.

Used GitLab SAST? Recommend it under your own name and title.

Recommend this tool