Dependency Scanning with GitLab CI/CD

This example shows how to run Dependency Scanning on your project's dependencies 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 dependency_scanning:

  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" /code
    paths: [gl-dependency-scanning-report.json]

The above example will create a dependency_scanning 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 Dependency Scanning Docker image is used to detect the languages/package managers 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 Dependency Scanning documentation.

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

Supported languages and package managers

See the full list of supported languages and package managers.