## Business Case 1. This is the first iteration of non-default branch tracking. 2. This is the most oft-requested Security Insights feature request with [32 accounts totaling $30.6M](https://10az.online.tableau.com/#/site/gitlab/views/CustomerIssueDashboard/CustomerIssuesEpics?:iid=1) ARR requesting this. 3. It is a blocker to adoption because customers lack visibility and the ability to conduct vulnerability management for branches that are releasing artifacts to production. Providing this capability will provide a path for increasing the value of Ultimate, increasing adoption and in turn reducing churn and/or providing expansion opportunities. 4. Target metric 1. Metric: ‘Vulnerability Management Activity’ on Tracked non-default branches 2. Target: Equal VM Activity on non default branches to default branches 3. Why? We are providing the same must-have vulnerability management flows for non default branches. If customers are treating those branches like they are default branches, we assume they are accomplishing the goal of the feature which is to support vuln management on branches with that are deploying live artifacts. Iteration 4 will be the MVP GA release for Tracking Non Default Branches. Iteration 1 represents the functional scope and this epic represents the scalability work required to ensure a safe and stable General Availability release of the feature. ## Product Requirement Scope 1. Key tables are partitioned to ensure performance of queries is optimal as the quantity of data grows substantially. Any vulnerability/dependency tables over or close the 100GB threshold should be partitioned for this reason. The currently known list is: 1. `vulnerabilities` 2. `vulnerability_occurrences` 3. `vulnerability_reads` 4. `vulnerability_identifiers` 5. `sbom_occurrences` 2. A global quota system allowing the allocation of tracked branches on a per organization basis that can be managed by GitLab.com support. Customers should be able to: 1. Allocate as many tracked branches as they like to any project in their organization, up to their quota limit. 2. See their current usage of the quota and be able to see where this quota has been allocated to from a global perspective. 3. Request an increase to the quota from GitLab via the UI. This should permit our support team to be able to review the request, engage with GitLab engineers to ensure that the increase in allocation would be safe to facilitate, and then apply the increase. ## Out of Scope 1. Any functional / UI capabilities outside those necessary to facilitate the scalability functions. ## Release Plan 1. TBD - ideally, a sliding or iterative ramp up of the counts of users/namespaces/branches with this feature turned on would be best until the metrics reach a certain GA-acceptable threshold.