Skip to content

GitLab Secure (ULTIMATE)

Check your application for security vulnerabilities that may lead to unauthorized access, data leaks, and denial of services.

GitLab will perform static and dynamic tests on the code of your application, looking for known flaws and report them in the merge request so you can fix them before merging.

Security teams can use dashboards to get a high-level view on projects and groups, and start remediation processes when needed.

For an overview of application security with GitLab, see Security Deep Dive.

Security scanning tools

GitLab can scan and report any vulnerabilities found in your project.

Secure scanning tool Description
Container Scanning (ULTIMATE) Scan Docker containers for known vulnerabilities.
Dependency List (ULTIMATE) View your project's dependencies and their known vulnerabilities.
Dependency Scanning (ULTIMATE) Analyze your dependencies for known vulnerabilities.
Dynamic Application Security Testing (DAST) (ULTIMATE) Analyze running web applications for known vulnerabilities.
License Compliance (ULTIMATE) Search your project's dependencies for their licenses.
Security Dashboard (ULTIMATE) View vulnerabilities in all your projects and groups.
Static Application Security Testing (SAST) (ULTIMATE) Analyze source code for known vulnerabilities.

Maintenance and update of the vulnerabilities database

The various scanning tools and the vulnerabilities database are updated regularly.

Secure scanning tool Vulnerabilities database updates
Container Scanning Uses clair underneath and the latest clair-db version is used for each job run by running the latest docker image tag. The clair-db database is updated daily according to the author.
Dependency Scanning Relies on bundler-audit (for Rubygems), retire.js (for NPM packages) and gemnasium (GitLab's own tool for all libraries). bundler-audit and retire.js both fetch their vulnerabilities data from GitHub repositories, so vulnerabilities added to ruby-advisory-db and retire.js are immediately available. The tools themselves are updated once per month if there's a new version. The Gemnasium DB is updated at least once a week.
Dynamic Application Security Testing (DAST) Updated weekly on Sundays. The underlying tool, zaproxy, downloads fresh rules at startup.
Static Application Security Testing (SAST) Relies exclusively on the tools GitLab is wrapping. The underlying analyzers are updated at least once per month if a relevant update is available. The vulnerabilities database is updated by the upstream tools.

You don't have to update GitLab to benefit from the latest vulnerabilities definitions, but you may have to in the future.

The security tools are released as Docker images, and the vendored job definitions to enable them are using the x-y-stable image tags that get overridden each time a new release of the tools is pushed. The Docker images are updated to match the previous GitLab releases, so they automatically get the latest versions of the scanning tools without the user having to do anything.

This workflow comes with some drawbacks and there's a plan to change this.

Interacting with the vulnerabilities

Introduced in GitLab Ultimate 10.8.

CAUTION: Warning: This feature is currently Alpha and while you can start using it, it may receive important changes in the future.

Each security vulnerability in the merge request report or the Security Dashboard is actionable. Clicking on an entry, a detailed information will pop up with different possible options:

  • Dismiss vulnerability: Dismissing a vulnerability will place a strikethrough styling on it.
  • Create issue: The new issue will have the title and description pre-populated with the information from the vulnerability report and will be created as confidential by default.
  • Solution: For some vulnerabilities, a solution is provided for how to fix the vulnerability.

Interacting with security reports

Dismissing a vulnerability

You can dismiss vulnerabilities by clicking the Dismiss vulnerability button. This will dismiss the vulnerability and re-render it to reflect its dismissed state. If you wish to undo this dismissal, you can click the Undo dismiss button.

Adding a dismissal reason

Introduced in GitLab Ultimate 12.0.

When dismissing a vulnerability, it's often helpful to provide a reason for doing so. If you press the comment button next to Dismiss vulnerability in the modal, a text box will appear, allowing you to add a comment with your dismissal. Once added, you can edit it or delete it. This allows you to add and update context for a vulnerability as you learn more over time.

Dismissed vulnerability comment

Creating an issue for a vulnerability

You can create an issue for a vulnerability by selecting the Create issue button from within the vulnerability modal or using the action buttons to the right of a vulnerability row when in the group security dashboard.

This will create a confidential issue on the project this vulnerability came from and pre-fill it with some useful information taken from the vulnerability report. Once the issue is created, you will be redirected to it so you can edit, assign, or comment on it.

Upon returning to the group security dashboard, you'll see that the vulnerability will now have an associated issue next to the name.

Linked issue in the group security dashboard

Solutions for vulnerabilities (auto-remediation)

Introduced in GitLab Ultimate 11.7.

Some vulnerabilities can be fixed by applying the solution that GitLab automatically generates. The following scanners are supported:

  • Dependency Scanning: Automatic Patch creation is only available for Node.JS projects managed with yarn.

Manually applying the suggested patch

Some vulnerabilities can be fixed by applying a patch that is automatically generated by GitLab. To apply the fix:

  1. Click on the vulnerability.
  2. Download and review the patch file remediation.patch.
  3. Ensure your local project has the same commit checked out that was used to generate the patch.
  4. Run git apply remediation.patch.
  5. Verify and commit the changes to your branch.

Apply patch for dependency scanning

Creating a merge request from a vulnerability

Introduced in GitLab Ultimate 11.9.

In certain cases, GitLab will allow you to create a merge request that will automatically remediate the vulnerability. Any vulnerability that has a solution can have a merge request created to automatically solve the issue.

If this action is available there will be a Create merge request button in the vulnerability modal. Clicking on this button will create a merge request to apply the solution onto the source branch.

Create merge request from vulnerability

Security approvals in merge requests (ULTIMATE)

Introduced in GitLab Ultimate 12.2.

Merge Request Approvals can be configured to require approval from a member of your security team when a vulnerability, or a software license compliance violation would be introduced by a merge request.

This threshold is defined as high, critical, or unknown severity. When any vulnerabilities are present within a merge request, an approval will be required from the Vulnerability-Check approver group.

Enabling Security Approvals within a project

To enable Security Approvals, a project approval rule must be created with the case-sensitive name Vulnerability-Check. This approval group must be set with an "Approvals required" count greater than zero.

Once this group has been added to your project, the approval rule will be enabled for all Merge Requests.

Any code changes made will cause the count of approvals required to reset.

An approval will be required when a security report:

  • Contains a new vulnerability of high, critical, or unknown severity.
  • Is not generated during pipeline execution.

An approval will be optional when a security report:

  • Contains no new vulnerabilities.
  • Contains only new vulnerabilities of low or medium severity.

Enabling License Approvals within a project

To enable License Approvals, a project approval rule must be created with the case-sensitive name License-Check. This approval group must be set with an "Approvals required" count greater than zero.

Once this group has been added to your project, the approval rule will be enabled for all Merge Requests. To configure how this rule behaves, you can choose which licenses to approve or blacklist in the project policies for License Compliance section.

Any code changes made will cause the count of approvals required to reset.

An approval will be required when a license report:

  • Contains a dependency that includes a software license that is blacklisted.
  • Is not generated during pipeline execution.

An approval will be optional when a license report:

  • Contains no software license violations.
  • Contains only new licenses that are approved or unknown.

Troubleshooting

Getting error message sast job: stage parameter should be [some stage name here]

When including a security job template like SAST, the following error can be raised, depending on your GitLab CI/CD configuration:

Found errors in your .gitlab-ci.yml:

* sast job: stage parameter should be unit-tests

This error appears when the stage (nammed test) of the included job isn't declared in .gitlab-ci.yml. To fix this issue, you can either:

  • Add a test stage in your .gitlab-ci.yml.

  • Change the default stage of the included security jobs. For example, with SAST:

    include:
  template: SAST.gitlab-ci.yml

sast:
  stage: unit-tests

Learn more on overriding the SAST template. All the security scanning tools define their stage, so this error can occur with all of them.