Static Application Security Testing with GitLab CI/CD

This example shows how to run Static Application Security Testing (SAST) on your project's source code by using GitLab CI/CD.

First, you need GitLab Runner with docker-in-docker executor. You can then add a new job to .gitlab-ci.yml, called sast:

  image: docker:stable
    DOCKER_DRIVER: overlay2
  allow_failure: true
    - docker:stable-dind
    - export SP_VERSION=$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')
    - docker run
        --volume "$PWD:/code"
        --volume /var/run/docker.sock:/var/run/docker.sock
        "$SP_VERSION" /app/bin/run /code
    paths: [gl-sast-report.json]

The above example will create a sast job in the test stage and will create the required report artifact. Check the Auto-DevOps template for a full reference.

The results are sorted by the priority of the vulnerability:

  1. High
  2. Medium
  3. Low
  4. Unknown
  5. Everything else

Behind the scenes, the GitLab SAST Docker image is used to detect the languages/frameworks and in turn runs the matching scan tools.

Some security scanners require to send a list of project dependencies to GitLab central servers to check for vulnerabilities. To learn more about this or to disable it, check the GitLab SAST tool documentation.

Tip: Starting with GitLab Ultimate 10.3, this information will be automatically extracted and shown right in the merge request widget. To do so, the CI job must be named sast and the artifact path must be gl-sast-report.json. Make sure your pipeline has a stage nammed test, or specify another existing stage inside the sast job. Learn more on application security testing results shown in merge requests.

Supported languages and frameworks

See the full list of supported languages and frameworks.