Security scanners are essential, but not every finding requires action. Test code, vendored dependencies, generated files, and known false positives create noise that buries the vulnerabilities that actually matter. Security teams waste hours manually dismissing the same irrelevant findings across projects and pipelines. They experience slower triage, alert fatigue, and developer friction that undermines adoption of security scanning itself.
GitLab's auto-dismiss vulnerability policies let you codify your triage decisions once and apply them automatically on every default-branch pipeline. Define criteria based on file path, directory, or vulnerability identifier (CVE, CWE), choose a dismissal reason, and let GitLab handle the rest.
Why auto-dismiss?
Auto-dismiss vulnerability policies enable security teams to:
- Eliminate triage noise: Automatically dismiss findings in test code, vendored dependencies, and generated files.
- Enforce decisions at scale: Apply policies centrally to dismiss known false positives across your entire organization.
- Maintain audit transparency: Every auto-dismissed finding includes a documented reason and links back to the policy that triggered it.
- Preserve the record: Unlike scanner exclusions, dismissed vulnerabilities remain in your report, so you can revisit decisions if conditions change.
How auto-dismiss policies work
- Define your policy in a vulnerability management policy YAML file. Specify match criteria (file path, directory, or identifier) and a dismissal reason.
- Merge and activate. Create the policy via Secure > Policies > New policy > Vulnerability management policy. Merge the MR to enable it.
- Run your pipeline. On every default-branch pipeline, matching vulnerabilities are automatically set to "Dismissed" with the specified reason. Up to 1,000 vulnerabilities are processed per run.
- Measure the impact. Filter your vulnerability report by status "Dismissed" to see exactly what was cleaned up and validate that the right findings are being handled.
Use cases with ready-to-use configurations
Each example below includes a policy configuration you can copy, customize, and apply immediately.
1. Dismiss test code vulnerabilities
SAST and dependency scanners flag hardcoded credentials, insecure fixtures, and dev-only dependencies in test directories. These are not production risks.
vulnerability_management_policy:
- name: "Dismiss test code vulnerabilities"
description: "Auto-dismiss findings in test directories"
enabled: true
rules:
- type: detected
criteria:
- type: file_path
value: "test/**/*"
- type: detected
criteria:
- type: file_path
value: "tests/**/*"
- type: detected
criteria:
- type: file_path
value: "spec/**/*"
- type: detected
criteria:
- type: directory
value: "__tests__/*"
actions:
- type: auto_dismiss
dismissal_reason: used_in_tests
2. Dismiss vendored and third-party code
Vulnerabilities in vendor/, third_party/, or checked-in node_modules are managed upstream and not actionable for your team.
vulnerability_management_policy:
- name: "Dismiss vendored dependency findings"
description: "Findings in vendored code are managed upstream"
enabled: true
rules:
- type: detected
criteria:
- type: directory
value: "vendor/*"
- type: detected
criteria:
- type: directory
value: "third_party/*"
- type: detected
criteria:
- type: directory
value: "vendored/*"
actions:
- type: auto_dismiss
dismissal_reason: not_applicable
3. Dismiss known false positive CVEs
Certain CVEs are repeatedly flagged but don't apply to your usage context. Teams dismiss these manually every time they appear. Replace the example CVEs below with your own.
vulnerability_management_policy:
- name: "Dismiss known false positive CVEs"
description: "CVEs confirmed as false positives for our environment"
enabled: true
rules:
- type: detected
criteria:
- type: identifier
value: "CVE-2023-44487"
- type: detected
criteria:
- type: identifier
value: "CVE-2024-29041"
- type: detected
criteria:
- type: identifier
value: "CVE-2023-26136"
actions:
- type: auto_dismiss
dismissal_reason: false_positive
4. Dismiss generated and auto-created code
Protobuf, gRPC, OpenAPI generators, and ORM scaffolding tools produce files with flagged patterns that cannot be patched by your team.
vulnerability_management_policy:
- name: "Dismiss generated code findings"
description: "Generated files are not authored by us"
enabled: true
rules:
- type: detected
criteria:
- type: directory
value: "generated/*"
- type: detected
criteria:
- type: file_path
value: "**/*.pb.go"
- type: detected
criteria:
- type: file_path
value: "**/*.generated.*"
actions:
- type: auto_dismiss
dismissal_reason: not_applicable
5. Dismiss infrastructure-mitigated vulnerabilities
Vulnerability classes like XSS (CWE-79) or SQL injection (CWE-89) that are already addressed by WAF rules or runtime protection. Only use this when mitigating controls are verified and consistently enforced.
vulnerability_management_policy:
- name: "Dismiss CWEs mitigated by WAF"
description: "XSS and SQLi mitigated by WAF rules"
enabled: true
rules:
- type: detected
criteria:
- type: identifier
value: "CWE-79"
- type: detected
criteria:
- type: identifier
value: "CWE-89"
actions:
- type: auto_dismiss
dismissal_reason: mitigating_control
6. Dismiss CVE families across your organization
A wave of related CVEs for a widely-used library your team has assessed? Apply at the group level to dismiss them across dozens of projects. The wildcard pattern (e.g., CVE-2021-44*) matches all CVEs with that prefix.
vulnerability_management_policy:
- name: "Accept risk for log4j CVE family"
description: "Log4j CVEs mitigated by version pinning and WAF"
enabled: true
rules:
- type: detected
criteria:
- type: identifier
value: "CVE-2021-44*"
actions:
- type: auto_dismiss
dismissal_reason: acceptable_risk
Quick reference
| Parameter | Details |
|---|---|
| Criteria types | file_path (glob patterns, e.g., test/**/*), directory (e.g., vendor/*), identifier (CVE/CWE with wildcards, e.g., CVE-2023-*) |
| Dismissal reasons | acceptable_risk, false_positive, mitigating_control, used_in_tests, not_applicable |
| Criteria logic | Multiple criteria within a rule = AND (must match all). Multiple rules within a policy = OR (match any). |
| Limits | 3 criteria per rule, 5 rules per policy, 5 policies per security policy project. Vulnerabilty management policy actions process 1000 vulnerabilities per pipeline run in the target project, until all matching vulnerabilities are processed. |
| Affected statuses | Needs triage, Confirmed |
| Scope | Project-level or group-level (group-level applies across all projects) |
Getting started
Here's how to get started with auto-dismiss policies:
- Identify the noise. Open your vulnerability report and sort by "Needs triage." Look for patterns: test files, vendored code, the same CVE across projects.
- Pick a scenario. Start with whichever use case above accounts for the most findings.
- Record your baseline. Note the number of "Needs triage" vulnerabilities before creating a policy.
- Create and enable. Navigate to Secure > Policies > New policy > Vulnerability management policy. Paste the configuration from the use case above, then merge the MR.
- Validate results. After the next default-branch pipeline, filter by status "Dismissed" to confirm the right findings were handled.
For full configuration details, see the vulnerability management policy documentation.
Ready to take control of vulnerability noise? Start a free GitLab Ultimate trial and configure your first auto-dismiss policy today.
