Skip to content

Design: Track vulnerabilities in locations other than the default branch

Problem to solve

Users want to track vulnerabilities on other branches besides the default one. They currently can't do this from the Vulnerability Report nor see stats about vulns on other branches from the Security Dashboard.

Target user

Primarily: Security engineers

Secondarily: developers responsible for application security (shift left and/or their org is small enough and they don't have a dedicated appsec team)

Customer use cases

  • A developer creates a new branch to work on a large feature, the security team allows the developer to work on the branch without any security constraints, but still wants to have an overview of the state of this branch/feature so they can work on any security issues in parallel to development. We don't want to see these issues for the first time in a MR to main.
  • If I see a vulnerability in Prod AND in QA, I need to go fix it. If I see it’s in Prod but NOT in QA, I probably don’t need to fix it because it’s already fixed in QA. We just need to know WHERE this vulnerability exists so we can make further decisions.
  • Vulnerability duplication across branches: “I’m looking at production branch and seeing a critical vuln, I want to be able to click on that vulnerability and see what other branches it exists on.”
  • We want to compare releases (using tags) so we can include the fixes in the support release notes.
  • Before a team deploys something to production, they undergo a security review, so they’ll create a release branch, and that branch will have to pass QA. QA will create a ticket and then our security team reviews it. We don’t care about the default branch but the release branch.
  • When we're testing in the QA branch, I can't confidently say that if I merge the QA branch into the Production branch that I won't be introducing any vulnerabilities.

JTBD

  1. When I am getting ready for a release, I want to check the staging branch to make sure I am not introducing any new vulnerabilities when I merge to production.
  2. When I want to show leadership the progress the security team has made, I want to show my executive team that there were a lot of vulnerabilities on the development branch, but the total of criticals and highs went down by the time we deployed to the production branch.

What hypotheses and/or assumptions do you have?

MVC of letting users filter by one branch at a time will be sufficient. Post-MVC we can explore comparing branches or looking at multiple branches at once.

Requirements

Release 1

  • Security Configuration page - choosing which refs to track
  • Vulnerability Report and Security Dashboard - filtering by branch (one at a time)
  • Vulnerability Report should be able to show multiple refs, whereas the security dashboard should only show 1 at a time

Release 2

  • Show me the SBOM of this application (artifact) that I released from this non default branch
  • Show me the SBOM of the current state of this project in this non default branch
  • Show me where this library is used across all tracked branches and projects

Demo

A quick overview of what to expect from release 1 of non-default ref tracking: https://www.youtube.com/watch?v=XIoUGhIbjpE

Note that this is a design prototype to communicate the functionality, and the final version will be more aligned to GitLab's design system.

Edited by Becka Lippert