Vulnerability management policy

Use a vulnerability management policy to automatically resolve vulnerabilities that are no longer detected or automatically dismiss vulnerabilities that match specific criteria. 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.

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.

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

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-*.

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 will not be updated.

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. On 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. On 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.