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.
Read original(opens in new tab)