A typical enterprise vulnerability report surfaces hundreds of findings per scan cycle, all ranked by the Common Vulnerability Scoring System (CVSS). The problem: CVSS describes the theoretical characteristics of a Common Vulnerabilities and Exposures (CVE), not whether it matters in your environment. A Critical vulnerability in an internal-only utility library is not the same risk as a Medium vulnerability in a public-facing authentication service, but they're treated identically until someone manually triages each one. That triage work doesn't scale.GitLab vulnerability management policies can now automatically override those default CVSS severity levels based on conditions you define, so your vulnerability report reflects your actual risk model instead of a generic one.How severity override policies workA severity override policy is a type of vulnerability management policy that adjusts vulnerability severity levels automatically on every default-branch pipeline. You define rules with match criteria (CVE ID, CWE ID, file path, or directory) and an override action. When a vulnerability matches, GitLab's Security Policy Bot updates its severity immediately.Three override operations are available:Set Severity: Forces the severity to a specific level (info, low, medium, high, or critical).Increase Severity: Bumps the severity up one level.Decrease Severity: Drops the severity down one level.Manual overrides by authorized users always take precedence over policy overrides. Every automated change is logged in the vulnerability's history and audit events, so you maintain a complete record of what changed and why.Use cases with ready-to-use configurationsEach example below includes a policy configuration you can copy, customize, and apply immediately.1. Downgrade low-risk CVEs in internal servicesSecurity scanners don't know which projects are internal tools, test utilities, or production services. They rate every CVE the same regardless of deployment context. For teams running internal admin dashboards, developer tooling, or batch processing jobs that never face external traffic, a Critical-rated dependency vulnerability often doesn't warrant the same response as one in a customer-facing API.This policy decreases the severity of specific CVEs found in internal service directories: vulnerability_management_policy: