## Executive Summary In https://gitlab.com/groups/gitlab-org/-/epics/17403 we introduced an experiment that allows users to have MRs generated on their behalf that increment versions of their vulnerable dependencies. In this experimental phase we had limited configuration for users and only targeted vulnerabilities with `LOW` severity, which are generally considered lower stakes versus other severity levels. The focus of this epic will be to make improvements based on any feedback during the experiment phase, but also improve usability so we can expand the breadth of vulnerabilities targeted for remediation. We should also allow users to choose how MRs are created: either in groups for all version bumps or individual MRs. At this phase of maturity we would like to incorporate UI elements to help users better understand vulnerabilities that were auto-remediated. #### Engineering Assessment \[Brief description of the engineering assessment of this candidate item.\] ### Proposal * Pre-requisite: all Experiment work has concluded + feedback is incorporated into beta delivery * Add configuration for multiple levels of severity (`LOW`, `MEDIUM`, `HIGH`, `CRITICAL`) * Add configuration for update version target (`MAJOR`, `MINOR`, `PATCH`) * Allow users to group dependency version bumps into one MR * This should be configurable through the GitLab config file. * Use configuration profiles to store the config values at the project and group level. This will be done through an **API only** approach at this time. * UI changes to highlight vulnerabilities that have been auto-remediatied * See Child issue and User Experience Goals section below for complete details. * Any AI-related follow on work stemming from the AI experiment in https://gitlab.com/groups/gitlab-org/-/epics/17884. ### User experience goals * Auto-remediation will run without human intervention until the MR is created and goes through the MR approval policy defined by an organization * User will configure auto-remediation through their GitLab config file * To inform the user of an auto-remediation action we should incorporate this into the UI (see child issue for complete details). * Users should see `Status` change for auto-remediated vulnerabilities * Users should see `Activity` change for auto-remediated vulnerabilities ### Metrics In beta maturity level we are adding configuration for users to: 1. Expand the vulnerabilities that are eligible for auto-remediation - `LOW` through `CRITICAL` severity. 2. Expand proposed version selection options - `MAJOR`, `MINOR`, `PATCH` To understand outcomes we should: * Capture auto-remediated MRs accepted / rejected by: * Severity * Upgrade version This will allow us to understand if certain vulnerabilities are being rejected or accepted based on the proposed version and the severity of the vulnerabilities that are being remediated with this feature. ### Dependencies * Team dependencies: * ~"group::security insights" EM: @nmccorrison * ~"group::composition analysis" * Epic/issue dependencies: https://gitlab.com/groups/gitlab-org/-/epics/18449 * External dependencies: none ```glql display: table query: project = "gitlab-org/gitlab" AND ID = 550961 fields: title, state, milestone, assignee, health title: Epic Dependency Tracking ``` ### DRIs * PM: @joelpatterson | @mclausen35 * Engineer: @hacks4oats * EM: @nilieskou * ~"group::composition analysis" ~"group::security insights" * Engineering Owner: @twoodham #### 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 - [ ] **Engineering-driven initiatives (E1/E2/E3)** - Internal technical improvements that may not have customer-facing components #### Sizing and Funding (Optional) - **Size**: L - **Funding Status**: TBD, based on interlock feedback ### Target Metric/s * Improved usability of CA, which can result in an increased adoption of SCA. _(Will update with data via comment section)_ ### 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) - [ ] 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