## 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. We determined that presenting CVEs from third party libraries is a requirement for MVP considering users expect all scanners they run to present data in the branches they track. ## Product Requirement Scope This iteration should be seeking to fufill the following functionalities: As an appsec admin, I want to configure which branches are available for vulnerability and dependency scanning, so that engineers can focus on relevant branches without overwhelming the system with tracking every branch. 1. Long lasting/releasing branches should 1. Allow for local changes to vulnerability state 2. Duplicate vulnerabilities of the same type on the vulnerability report 3. Duplicate counts of vulnerabilities on the dashboard As an AppSec engineer, I want to view vulnerability and dependency information by branch, so that I can verify the security of all branches used in production releases. 1. See all vulnerabilities related to a specific branch in the vulnerability report. 1. Composition Analysis (tracked in iteration 2) 2. Detected at time should refer to the first detection of a vulnerability on a specific branch. IE each instance of a vuln on different branches should have different detection times. 3. See all libraries present in a specific branch in the dependency list. 1. When the branch is set, the version of the library should always refer to the specific manifest file present in that branch. 2. All exports (CycloneDX, JSON, SPDX) should support exporting based on the selected filter. 3. If filtering on the dependency list is blocked by elasticsearch and the dependency is not resolved, then we could remove this requirement and track it in a seperate issue. 4. The default view of the dependency list should be default branch. 5. Users can select multiple branches at once the dependency list As an AppSec engineer, I also want to track vulnerability trends on the security dashboard branch, so that I can get a complete view of specific teams/products that represent that branch. 1. CVEs from SCA should be counted among the other vulnerabilities on the dashboard (Note - this is expected to just happen, but documenting here nonetheless) As an AppSec engineer, I also want to ensure my vulnerability management workflows are supported on non default branches in ways that correspond with its existence as a 'long lived releasing branch'. 1. State changes, severity changes, or comments to the vulnerability should default to be local changes (IE - just to the vuln on that branch) with an option to configure a global change to all 'related vulnerbilities' which are calculated in the vulnerability details page.