Manage vulnerability noise at scale with auto-dismiss policies

GitLab’s auto-dismiss vulnerability policies reduce scanner noise by automatically dismissing findings that teams have already determined are irrelevant, non-actionable, or mitigated. Policies match vulnerabilities by file path, directory, or identifier such as a CVE or CWE, while preserving dismissed findings and their audit history. This lets security teams focus on genuine risks without repeatedly performing the same manual triage.

Why Auto-Dismiss Policies Matter

• Security scanners often flag:
  • Test code and fixtures
  • Vendored or third-party dependencies
  • Generated files
  • Known false positives
  • Vulnerabilities addressed by existing controls
• Manual dismissal creates:
  • Slower triage
  • Alert fatigue
  • Developer friction
  • Repeated work across projects and pipelines
• Auto-dismiss policies allow teams to:
  • Apply triage decisions consistently at scale
  • Record a specific dismissal reason
  • Link findings back to the policy that dismissed them
  • Keep dismissed vulnerabilities visible for future review

How Policies Work

• Policies are defined in a vulnerability management policy YAML file.
• Rules can match:
  • File paths
  • Directories
  • Vulnerability identifiers, including CVEs and CWEs
• Teams create the policy through Secure > Policies > New policy > Vulnerability management policy.
• After the merge request is merged, matching findings on default-branch pipelines are automatically marked Dismissed.
• GitLab processes up to 1,000 vulnerabilities per pipeline run.
• Teams can filter reports by Dismissed to evaluate policy impact and verify that the correct findings were handled.

Dismissing Test Code Findings

Test directories commonly contain intentionally insecure credentials, fixtures, or development-only dependencies that do not represent production risk.

• Policies can target paths such as:
  • test/**/*
  • tests/**/*
  • spec/**/*
  • __tests__/*
• The recommended dismissal reason is used_in_tests.

Dismissing Vendored Dependencies

Code in vendor/, third_party/, vendored/, or checked-in node_modules is often maintained upstream rather than by the application team.

• Directory-based rules can identify these locations.
• The example policy uses the not_applicable dismissal reason.
• Teams should customize the directory patterns to match their repository structure.

Dismissing Known False-Positive CVEs

Repeatedly flagged CVEs that have been confirmed not to apply to an organization’s environment can be dismissed centrally.

• Rules match specific identifiers, such as:
  • CVE-2023-44487
  • CVE-2024-29041
  • CVE-2023-26136
• The sample policy uses false_positive.
• The listed CVEs are examples and should be replaced with identifiers validated by the organization.

Dismissing Generated Code

Generated files from Protobuf, gRPC, OpenAPI, ORM, and similar tools may contain patterns scanners flag even though developers do not author or directly patch them.

• Example matches include:
  • generated/*
  • **/*.pb.go
  • **/*.generated.*
• The suggested dismissal reason is not_applicable.

Dismissing Infrastructure-Mitigated Vulnerabilities

Some vulnerabilities may be addressed by enforced runtime controls, such as WAF rules.

• The example targets:
  • CWE-79 for cross-site scripting
  • CWE-89 for SQL injection
• It uses the mitigating_control dismissal reason.
• This approach should only be used when the mitigation is verified, consistently deployed, and reliably protects all affected paths.

Practical Recommendation

Use auto-dismiss policies for well-understood, documented cases—not as a substitute for vulnerability investigation. Start with narrowly scoped path or identifier rules, review the dismissed results regularly, and ensure every dismissal reason reflects a decision that remains valid.