Static Application Security Testing (SAST)

Introduced in GitLab Enterprise Edition Ultimate 10.3.


If you are using GitLab CI/CD, you can analyze your source code for known vulnerabilities using Static Application Security Testing (SAST), either by including the CI job in your existing .gitlab-ci.yml file or by implicitly using Auto SAST that is provided by Auto DevOps.

Going a step further, GitLab can show the vulnerability list right in the merge request widget area:

SAST Widget

Use cases

  • Your application is using an external (open source) library, locked to a specific version (e.g., via Gemfile.lock) and the version is known to be vulnerable.
  • Your code has a potentially dangerous attribute in a class, or unsafe code that can lead to unintended code execution.

How it works

In order for the report to show in the merge request, you need to specify a sast job (exact name) that will analyze the code and upload the resulting gl-sast-report.json file as an artifact. GitLab will then check this file and show the information inside the merge request.

This JSON file needs to be the only artifact file for the job. If you try to also include other files, it will break the vulnerability display in the merge request.

For more information on how the sast job should look like, check the example on analyzing a project's code for vulnerabilities.