## Executive Summary Dependency Scanning and Container Scanning return sizable result sets. These identified CVEs are a blessing and a curse for our users. On one hand they have a thorough understanding of the open-source risk within their projects. However, many users attribute the influx of CVEs as noise which prevents focus on CVEs that actually matter. We should be driving toward an outcome of reducing the manual work attributed to triaging and remediating CVEs. In the context of our users, AppSec must focus their time and energy on triaging vulnerabilities post-scan. The Developer persona must validate the triage output from AppSec, in some cases make a determination of whether or not the CVE is relevant and then manually increment versions, which is a painful process. Removing the human from this workflow will enable AppSec to focus on managing their broad AppSec programs and for developers to focus on shipping business critical features. In https://gitlab.com/groups/gitlab-org/-/epics/17884 an experiment was kicked off by the AI-experiment team to leverage AI to automate the bumping of dependencies and prevent breaking changes. This epic is focused on implementing functionality around MR creation and also continuing the AI-focused experiment, which will move this feature set to beta and ultimately GA. ### Engineering Assessment ### Proposal for experiment level support Implement an automated system that proactively creates Merge Requests (MRs) to update vulnerable dependencies to secure versions. The system will: * Allow users to turn on/off auto-remediation on a project-by-project basis * Use DS scan results to identify **Ruby** dependencies with known vulnerabilities * Focus on resolving **1 vulnerability** at a time with **the highest severity** (simplified approach for experimental maturity) * Determine a proposed upgrade path (solution) for the vulnerabilities - we should only focus on patch and minor versions. * Generate code changes (manifest files) to update the dependencies * Create MRs with the update to the manifest files * This will be a 1:1 relationship with vulnerabilities to MRs * We will address grouping changes into 1 MR in [beta](https://gitlab.com/groups/gitlab-org/-/epics/18236) * MR is generated by a bot user * MR will be generated post-scan and require no human input outside of the MR approval policies defined by an organization. * Enable a user to turn functionality on or off at the project level. * Metric instrumentation: auto-remediated MRs accepted, tranches of severity and package manager. ### Users experience goals * In the experimental release we will have minimal configuration for turning this feature on and off via yaml configuration * Beta maturity level will include UX-focused work ### Metrics To understand impact on users we should instrument metrics to understand usage and ensure that we are solving our users problems. We should focus on capturing the `auto-remediated MRs accepted by package manager`. This will provide us insight on broad usage of the feature, but also which languages experience the highest volume of auto-remediated vulnerabilities. We will be able to understand if there are certain languages where this feature does not provide value to users. This will allow us to make improvements to the auto-remediation feature or seek alternatives to solve their vulnerability management problems. ### Further information AI-team Experiment Details: * Data Availability: No for major versions (breaking changes), Yes for minor versions * Customer Impact: High - directly addresses remediation friction * AI Feasibility: Yes, for small and minor updates. Human-generated change checklists could be easily executed by Workflow * Implementation Type: Duo Workflow (automated process with human review) ### Dependencies * Team dependencies: * ~"Sec AI team" * ~"group::composition analysis" * Epic/issue dependencies: https://gitlab.com/groups/gitlab-org/-/epics/17884 * External dependencies: none ### DRIs * PM: @joelpatterson | @khornergit * EM: @nilieskou | @nrosandich * UX/PDM: NA * Groups: ~"group::composition analysis" ~"Sec AI team" * Engineering owner: @rvider #### Initiative Driver - Product or Engineering? - [ ] **Product-driven initiatives (P1/P2/P3)** - Customer-facing features or improvements driven by Product teams that require engineering resources and commitment - [x] **Engineering-driven initiatives (E1/E2/E3)** - Internal technical improvements that may not have customer-facing components #### Sizing and Funding (Optional) - **Size**: L - **Funding Status**: 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