[[_TOC_]] ### Problem to solve Customers may not agree with the [severity levels assigned to vulnerabilities](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/severities.html) for many reasons. Aside from CVE + CVSS, there are no industry standards for vulnerability severity. To enable more efficient triage and remediation, customers would like to be able to customize severity levels. ### Proposal Create a rules-based method of automatically adjusting severity for vulnerabilities generated by GitLab: SAST, Dependency Scanning, Secret Detection, DAST, Container Scanning, API Security. Customizing severity levels in an automated, rule-based way, is more efficient and scalable than one-off severity overrides. ### Scope #### MVC * Customization policies/rules must be visible and editable via the UI and API * Once applied, the policy takes effect immediately. If a new pipeline-based scan runs, the severity overrides must happen quickly enough for the results to appear in the MR widget without a delay. Once a severity override policy is merged, users with merge requests open should be able to rerun their merge request pipelines immediately and see the updated severity. * Note: For MVC, we will focus on updating severity of vulnerabilities on the default branch. The MR should reflect the updated severity for any vulns/findings that are already tracked in default. Any new findings will not update. As a stretch goal, we will explore how to support new security findings. * Manual severity overrides will take precedence over a policy so that an individual with the right permissions can update a severity manually, even if has already been altered by a policy. * The override will appear in each vulnerability's history section * Ability to automated create, update, and delete severity customizations for: * Dependency Scanning - CVE ID * Container Scanning - CVE ID * SAST - CWE ID * DAST - CWE ID * The vulnerability report must include a visual indicator next to any severity that has changed due to customization. * All customizations must be logged via an audit event, including: * Timestamp for when the customization was created, updated, or deleted * Who authored the change * Parameters of the customization * Analyzer it applies to * Severity change * Input parameter (for MVC this is CVE, CWE, secret issuer) #### Future Iterations Expand customization to include additional parameters. These could include factors such as: **All** * Accessibility/internet exposure (internal vs external) * Environment (production vs QA) * [Business criticality](https://gitlab.com/gitlab-org/gitlab/-/issues/515932) ##### Dependency Scanning * EPSS * KEV * CVSS * Component name/version * License type ##### SAST * Rule ID * Language * Framework * Function name ##### Secret Detection * Rule ID * validity status ##### Container Scanning * Package name * Image tag * CVSS score ##### DAST * URL path ##### API Security * HTTP method ### Intended users * [Amy (Application Security Engineer)](https://about.gitlab.com/handbook/product/personas/#amy-application-security-engineer) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/product/personas/#alex-security-operations-engineer)