ContextQMD
Back to Gitlabhq

Vulnerability management policy

doc/user/application_security/policies/vulnerability_management_policy.md

18.11.29.2 KB
Original Source

{{< details >}}

  • Tier: Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

{{< history >}}

  • Introduced support for enforcing policies on projects in GitLab 17.7 with a flag named vulnerability_management_policy_type. Enabled by default.
  • Introduced support for enforcing policies on groups in GitLab 17.8 for the group-level with a flag named vulnerability_management_policy_type_group. Enabled by default.
  • Generally available in GitLab 17.9. Feature flags vulnerability_management_policy_type and vulnerability_management_policy_type_group removed.

{{< /history >}}

Use a vulnerability management policy to automatically resolve vulnerabilities that are no longer detected, automatically dismiss vulnerabilities that match specific criteria, or override vulnerability severity levels. This can help reduce the workload of triaging vulnerabilities.

When a scanner detects a vulnerability on the default branch, the scanner creates a vulnerability record with the status Needs triage. After the vulnerability has been remediated and the next security scan runs, the scan adds No longer detected to the record's activity log but the record's status does not change. You can change the status to Resolved either manually or by using a vulnerability management policy.

Vulnerability management policies ensure that rules are applied consistently. For example, you can create policies that:

  • Automatically resolve vulnerabilities that meet all of the following criteria:
    • No longer detected on the default branch.
    • Found by a SAST scan.
    • Low risk.
  • Automatically dismiss vulnerabilities found in test files with the reason Used in tests.
  • Dismiss vulnerabilities with specific CVE identifiers with the reason False positive.
  • Override (or change) the severity to critical for vulnerabilities that match specific CVE patterns in production code.

A vulnerability management policy only affects vulnerabilities with the status Needs triage or Confirmed.

The vulnerability management policy is applied when a pipeline runs against the default branch or when vulnerabilities are detected by advisory scanning.

When policies use auto-resolve, for each vulnerability that is no longer detected by the same scanner and matches the policy's rules:

  • The GitLab Security Policy Bot user sets the vulnerability record's status to Resolved.
  • A note about the status change is added to the vulnerability's record.

When policies use auto-dismiss, for each vulnerability that matches the policy's criteria:

  • The GitLab Security Policy Bot user sets the vulnerability record's status to Dismissed.
  • The dismissal reason is set according to the policy configuration.
  • A note about the status change is added to the vulnerability's record.

Policies can identify vulnerabilities that match a set of criteria and override their severity:

  • The GitLab Security Policy Bot user sets, increases, or decreases the severity level, according to the policy configuration.
  • A note about the severity change is added to the vulnerability's record.

To limit the pipeline load and duration, a maximum of 1,000 vulnerabilities per pipeline are processed for auto-resolve or auto-dismiss actions. The auto-resolve or auto-dismiss actions resume in subsequent pipelines, up to the maximum, until all matching vulnerabilities are processed.

Restrictions

  • You can assign a maximum of five rules to each policy.
  • You can assign a maximum of five vulnerability management policies to each security policy project.
  • When a secret detection scan finds that a previously detected secret key is no longer detected, the vulnerability is not auto-resolved. Instead, it remains in Needs Triage because the removed secret key has already been exposed. The vulnerability status should be manually resolved only after the secret key is revoked or rotated.

Auto-dismiss policies

{{< history >}}

  • Introduced support for auto-dismiss policies for groups, and any projects in those groups, in GitLab 18.8 with a feature flag named auto_dismiss_vulnerability_policies. Enabled by default.
  • Generally available in GitLab 18.10. Feature flag auto_dismiss_vulnerability_policies removed.
  • Introduced support for identifier_type and values criteria fields in GitLab 18.10 with a feature flag named security_policies_severity_customize. Enabled by default.

{{< /history >}}

Auto-dismiss policies support the following criteria:

  • File path: Match vulnerabilities based on the file path where they were found. Supports glob patterns like test/**/*.
  • Directory: Match vulnerabilities found in specific directories. Supports glob patterns like vendor/*.
  • Identifier: Match vulnerabilities based on their identifiers (CVE, CWE, or scanner-specific IDs). Supports wildcard patterns like CVE-2023-*.

With the security_policies_severity_customize feature flag enabled, identifier criteria also support:

  • Specifying an identifier type (cve, cwe, or owasp) to match against specific identifier formats.
  • Using a values array to match multiple identifiers with OR logic.

You can combine multiple criteria using:

  • AND logic. To be dismissed, the vulnerability must match all of the criteria.
  • OR logic. To be dismissed, the vulnerability can match any of the rules.

The following dismissal reasons are supported:

  • Acceptable risk: The vulnerability is known and accepted as a business risk.
  • False positive: The vulnerability is incorrectly reported.
  • Mitigating control: Equivalent protection is provided by other controls.
  • Used in tests: The vulnerability is part of test code or test data.
  • Not applicable: The vulnerability is in code that is no longer updated.

Severity override policies

{{< history >}}

{{< /history >}}

[!flag] The availability of this feature is controlled by a feature flag. For more information, see the history.

Policies that override the severity of vulnerabilities use the same criteria as auto-dismiss policies:

  • File path: Match vulnerabilities based on the file path where they were found.
  • Directory: Match vulnerabilities found in specific directories.
  • Identifier: Match vulnerabilities based on their identifiers.

For identifier criteria, you can optionally specify an identifier type to match only specific identifier formats:

  • CVE ID: Match CVE identifiers like CVE-2021-44228 or patterns like CVE-2023-*.
  • CWE ID: Match CWE identifiers like CWE-79 or patterns like CWE-*.
  • OWASP: Match OWASP identifiers like A1 or A03:2021.

The following severity operations are supported:

  • Set: Sets the severity to a specific level (info, low, medium, high, or critical).
  • Increase: Increases the severity by one level.
  • Decrease: Decreases the severity by one level.

Create a vulnerability management policy

Create a vulnerability management policy to automatically resolve or dismiss vulnerabilities matching specific criteria.

Prerequisites:

  • By default, only group, subgroup, or project Owners have the permissions required to create or assign a security policy project. This can be changed using custom roles.

To create a vulnerability management policy:

  1. In the top bar, select Search or go to and find your project.
  2. Go to Secure > Policies.
  3. Select New policy.
  4. In Vulnerability management policy, select Select policy.
  5. Complete the fields and set the policy's status to Enabled.
  6. Select Create policy.
  7. Review and merge the merge request.

After the vulnerability management policy has been created, the policy rules are applied to pipelines on the default branch.

Edit a vulnerability management policy

Edit a vulnerability management policy to change its rules.

  1. In the top bar, select Search or go to and find your project.
  2. Go to Secure > Policies.
  3. In the policy's row, select Edit.
  4. Edit the policy's details.
  5. Select Save changes.
  6. Review and merge the merge request.

The vulnerability management policy has been updated. When a pipeline next runs against the default branch, the policy's rules are applied.

Schema

When a vulnerability management policy is created or edited, it's checked against the vulnerability management policy schema to confirm it's valid.