[Proposal] CVE severity override for Dependency and Container Scanning - MVC

Problem to solve

With GitLab's broad customer base there are organizations that have varying level of complexity within their AppSec functions. Often times the severity that is assigned to a CVE does not adhere to internal threat models that are mandated by AppSec or Compliance teams.

Additionally, there are projects/applications that have differing levels of threat tolerance. In some cases, there are applications that are only used internally and not exposed to the wider internet that do not need to adhere to stringent security policies of remediating Critical and High severity vulnerabilities. Other times, an organization may operate in a highly regulated environment, where the given severity associated with a CVE is insufficient.

Intended users

  • Alex (Security Operations Engineer)
  • Amy (Application Security Engineer)
  • Delaney (Development Team Lead)
  • Sam (Security Analyst)
  • Sasha (Software Developer)

User experience goal

The user should be able to easily override a severity for a given vulnerability. Ease of access to data is important for this MVC because some organizations may want to apply many overrides. Performing this operation in bulk via the UI could prove to be a painful user experience for users.

Proposal

For an MVC we should focus on providing additional value by enabling the Override of a Severity for a user via the GraphQL API. Once a Dependency or Container scan has executed, the user may call the GraphQL API to establish the GUID attributed to the vulnerabilities identified during the scan. The user can POST the GUID value along with the desired Severity. This will override the GitLab provided Severity value.

There should be an indication in the database that a severity override was performed. This will prevent the ingestion mechanism from realigning the severity with the GitLab provided value upon the next ingest (e.g., scan). This would also have impact on MR policies.

Lastly, there should be an indicator in the GitLab that a vulnerability had a severity override applied.

Maybe in scope

After developer review of this issue, PM would like to get insight on whether or not this MVC could include an update to Severity value listed on the Vulnerability Details page (see screenshot below). This would be a read only value, that cannot be altered from the front-end.

image.png

Not in scope

  • Allowing a user to alter a severity value from the GitLab user interface [future iteration]
  • Providing a user a change log of the override history [future iteration]
    • This information should be captured in the database

Outstanding questions

  • The proposal listed above outlines affecting the severity for a vulnerability by the GUID. This will allow users to only focus on the scan results for Dependency/Container scanning and not globally affect the CVE severity. Should we allow the user to affect the severity at the global level?
  • If the severity is altered via API, will this also affect the CSV export / API response and any other areas where users access vulnerability information?
  • How might we track the severity overrides by users? This information should be captured.

Permissions and Security

Users who have access to this functionality should have the Maintainer and Owner roles.

Documentation

  • ADD documentation to Vulnerability Report area of the docs site
  • ADD new fields to the GraphQL API area of the docs site

Availability & Testing

Availability

For teams involved in this project this is not a concern. The team that owns the GraphQL API should have this handled.

Testing

Development teams should perform their normal testing processes.

Available Tier

GitLab Ultimate

Feature Usage Metrics

  • # of overrides
  • # of overrides changed

What does success look like, and how can we measure that?

Success looks like the feature being used by organizations who requested this functionality.

We should rely on the metrics outlined above to establish the success of this feature. Our most important metric will be the number of overrides applied.

Is this a cross-stage feature?

In some ways, yes. ~"group::threat insights" will display this information and expose it to users. groupcomposition analysis users will be directly affected by this functionality.

Notes from original body of issue

Add a mechanism to override severity values in the resulting output of dependency scanning. It would allow customers a way to customize results to be in alignment with corporate security policies or specific SDLC requirements (e.g. treating vulnerabilities differently when they are found in a dev environment vs prod).

Edited Jul 14, 2025 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading