🔒 Interlock Epic | Automated Vulnerability Severity Overrides/Customization Policy (#18378) · Epics · Epics · GitLab.org

🔒 Interlock Epic | Automated Vulnerability Severity Overrides/Customization Policy

## Executive Summary This new security policy capability will extend the vulnerability management policy, granting AppSec teams the ability to automate severity overrides based on rules/conditions, including KEV/EPSS, CVSS, Reachability, CVE, CWE, Current Severity, Vulnerability State, and Scan Type. By allowing AppSec teams to modify severity, they can better map risk to their business needs and automate their triage process, ultimately reducing toil on security teams while maximizing impact in addressing business impact. Details tracked in https://gitlab.com/groups/gitlab-org/-/epics/15839+. #### **Target Metrics** * Increase count of vulnerability management policies for existing users of the policy type by 20% in 3 months. * Why? Adoption correlates to realization of value which is ultimately increasing the signal to noise ratio for developers. * Reduce % of total number of Critical/High vulnerabilities per project on average (where a policy is applied) by 20% in 3 months. * Why? Reduce the total noise of vulnerabilities and give developers clearer priority. #### Engineering Assessment Building off of the work done by ~"group::security insights" in https://gitlab.com/groups/gitlab-org/-/epics/16157+ and https://gitlab.com/groups/gitlab-org/-/epics/5708+, we will update the vulnerability management policy to automate the severity changes. Notable challenges - Processing new vulnerabilities when they are added that match policy conditions - We will ensure that new vulnerabilities that are found in the default branch pipeline will be updated. If those vulnerabilities are found in a merge request pipeline, the override will be reflected. - New vulnerabilities found in a merge request pipeline that match the policy criteria will not be updated until the vulnerability is found in the default branch pipeline. - Processing large amounts of historical data could cause performance issues - Currently the auto-resolve mechanism is limited to 1000 updates per pipeline run and usually there are a large amount of vulnerabilities in the database, but we will investigate having a background service #### Dependencies - Team dependencies: * [Q3 UX Research](https://gitlab.com/gitlab-org/ux-research/-/issues/3579) - External dependencies: * As this work will involve ~"group::security insights"'s domain (e.g. perform historical and continuous automation tasks on the vulnerability management database to change vulnerability states, add a new Activity icon indicating when vulnerabilities have been modified by a policy and record details in the vulnerability page, introduce a filter to filter by this Activity). We would benefit from - Architecture guidance - Refinement review - Code review * Note: Introducing the Activity Filter is a stretch goal, dependent on ElasticSearch improvements. Activity Filters will not be supported for all Self-Managed customers as it requires them to configure ES. - Epic/Issue dependencies - None #### DRIs - **PM**: @g.hickman - **EM**: @alan cc @aturinske while Alan is :palm_tree: - **UX/PDM**: @tparker1 - **Group(s)**: ~"group::security policies" - **Engineering Owner**: @rvider #### Initiative Driver - Product or Engineering? - [x] **Product-driven initiatives (P1/P2/P3)** - Customer-facing features or improvements driven by Product teams that require engineering resources and commitment - These initiatives require a Product Priority label (P1/P2/P3) - They may also receive GTM tier labels (T1/T2/T3) for external communication - [ ] **Engineering-driven initiatives (E1/E2/E3)** - Internal technical improvements that may not have customer-facing components - These initiatives require an Engineering Priority label (E1/E2/E3) - They have internal visibility only and are not externally communicated - Examples include: technical debt reduction, infrastructure improvements, refactoring, dependency upgrades #### Sizing and Funding (Optional) - **Size**: \[XS/S/M/L/XL\] - **Funding Status**: \[Funded/Partially funded/Not funded\] --- ### Hygiene Guidelines :bulb: \_See additional details about this process at \__https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/_ ##### :one: Pre-Interlock - [x] Update epic description with all relevant information - [x] Ensure all dependencies are identified - [x] Apply appropriate labels (see below) - [x] Apply target delivery Milestone - [ ] Update interlock status as discussions progress (via label) ##### :two: Post-Interlock: once quarter begins - Update health status weekly (via label) - Document any newly identified risks or dependencies - Link to implementation epics/issues as work begins - Flag any scope or timeline changes immediately

epic