## Executive Summary During the [beta](https://gitlab.com/groups/gitlab-org/-/epics/18236#proposal) phase, we developed functionality that allows multiple package updates to be consolidated into a single merge request, with configuration options based on severity levels and version targeting paths. To transition this feature from beta to general availability, we need to implement three key enhancements: * **Measurement and Analytics:** Introduce comprehensive metrics to track feature effectiveness and monitor adoption rates across users and organizations. * **Administrative Controls:** Develop a user interface that enables group-level administrators to activate auto-remediation settings, with automatic inheritance by all projects within that group hierarchy. For beta configuration will take place through configuration profiles. For GA ideally we would like to use configuration profiles otherwise Security configurations. During this epic we need to migrate from yaml to using the SPM configurations. * **Incorporate feedback from Beta:** collect feedback and incorporate it into our GA solution along with bug fixes. These additions will provide the visibility and management capabilities necessary for a successful GA launch. #### Engineering Assessment Possible metrics could be * Time to remediation: * Question: How fast do we resolve a vulnerability with a known solution * Business impact: Especially if we have auto-merging capabilities we could show tremendous increase in the remediation times. * How: Measure time from vulnerability creation to remediation (MR is merged and vulnerability is marked as resolved). * How many vulnerabilities were resolved by this feature * Question: What is the impact of vulnerability resolution feature on the user's vulnerability pool * How: Compare the number of resolved vulnerabilities compared to the total number of existing vulnerabilities * Time saved using automatic vulnerability resolution * Question: How much faster are users resolving vulnerabilities compared to baseline? * Business value: It helps us make a strong case for customers to adopt this feature, and can be surfaced as a reason to buy Ultimate/EE. * How: We could have a \[min, avg, max\] time required for a project to resolve vulnerabilities with a solution and compare them with the same numbers from vulnerability resolution feature. **Caveat:** All these metrics might be impacted by the number of MRs that we can open for a certain project. #### Dependencies - Team dependencies: * ~"group::security platform management" - Epic/Issue dependencies: https://gitlab.com/groups/gitlab-org/-/epics/19490 - External dependencies: NA #### DRIs - **PM**: @cwidstrom <!--also add as assignee to this epic--> - **EM**: @efeller <!--also add as assignee to this epic--> - **UX/PDM**: \[Name\] <!--also add as assignee to this epic--> - **Group(s)**: ~"group::composition analysis" ~"group::security platform management" <!--also add as label--> - **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 - 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 - [ ] Update epic description with all relevant information - [ ] Ensure all dependencies are identified - [ ] 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 <!--Apply appropriate labels: - [x] Section (section::dev, section::ops, section::sec) - [x] Stage (devops::plan, devops::create, devops::verify, etc.) - [x] Group (group::product planning, group::project management, etc.) - [ ] Interlock Priority (Product labels = Interlock Priority::P1, Interlock Priority::P2, Interlock Priority::P3, Engineering labels = Interlock Priority::E1, Interlock Priority::E2, Interlock Priority::E3) - [ ] Investment theme (Investment theme::Core-Devops, Investment theme::Security-Compliance, Investment theme::AI across SDLC) - [ ] Platforms (platform: GitLab.com, platform: dedicated, platform: dedicated for gov, platform: self-managed) - [ ] Subscription tier (GitLab Ultimate, GitLab Premium, GitLab Free) - [ ] Quarter (FY27 Q1, FY27 Q2, FY27 Q3, FY27 Q4) - [ ] Pre-interlock status label (interlock status::New/Proposal in progress, interlock status::cancelled, etc) - [ ] Post-interlock status label (R&D roadmap status::Executing, R&D roadmap status::Completed) - [ ] Post-interlock, once quarter begins update health weekly (health::on track, health::needs attention, health::at risk) *For guidance on labels, see the [labels guide here](https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/#labels-guide)-->