5 ways to fix misleading vulnerability severities with policy (opens in new tab)

CVSS scores describe a vulnerability’s general characteristics, not its actual risk in a specific environment. GitLab severity override policies let teams automatically adjust findings based on CVE, CWE, file path, or directory, reducing manual triage. The result is a vulnerability report that better reflects deployment context, exploitability, and organizational priorities.

How Severity Override Policies Work

• Policies run automatically on every default-branch pipeline.
• Rules match findings by:
  • CVE identifier
  • CWE identifier
  • File path
  • Directory
• Available actions:
  • Set Severity to informational, low, medium, high, or critical
  • Increase Severity by one level
  • Decrease Severity by one level
• Manual overrides by authorized users take precedence.
• GitLab records automated changes in vulnerability history and audit events.

Downgrading Low-Risk CVEs in Internal Services

• Internal tools and services may have substantially lower exposure than public-facing applications.
• A policy can reduce the severity of selected CVEs found under paths such as internal/**/*.
• The decrease operation lowers severity by one level—for example, Critical to High or High to Medium.
• Teams should replace the example CVEs with vulnerabilities they have assessed as less risky in internal deployments.

Upgrading Injection Vulnerabilities in Production Code

• XSS (CWE-79) and SQL injection (CWE-89) are frequently exploited vulnerability classes.
• Findings involving these CWEs under src/**/* can be forced to Critical.
• Combining this override with a merge request approval policy can require security-team review before affected code reaches production.

Normalizing Severity Across Scanners

• SAST, dependency, and container scanners may assign different severities to the same CVE.
• A policy can set specific vulnerabilities—such as Log4Shell-related CVEs—to a consistent baseline, such as High.
• This produces more predictable triage and approval thresholds across scanning tools.

Incorporating Exploitation Intelligence

• CVSS is largely static and does not reflect changes in real-world exploitation.
• EPSS and CISA’s Known Exploited Vulnerabilities catalog provide signals about exploitation likelihood and active attacks.
• Teams can explicitly upgrade CVEs identified as actively exploited or highly likely to be exploited, treating them as Critical regardless of their original scanner rating.

GitLab severity overrides are most useful when they encode a documented risk model: deployment exposure, vulnerability type, scanner consistency, and current threat intelligence. They should complement—not replace—manual review, auditability, and merge request approval controls.