Changes to VR in MR workflow

Purpose

Based on the discussion in https://gitlab.com/gitlab-org/gitlab/-/issues/502919, it's been decided that changes to the VR in MR workflow are needed as described below:

  1. Instead of a suggestion, the feature will create a new merge request (MR 2) branched from the merge request where the vulnerability was detected (MR 1).
  2. A comment will also be added to MR 1 at the line where the vulnerability was detected. The comment should look something like this:

Screenshot_2024-11-08_at_2.35.29_PM

Examples:

  1. Vulnerability -> VR MR (legacy VR workflow)
  2. MR with a new finding -> Finding Fix MR (This example was manually constrcuted to demonstrate the workflow and content described in this issue)

Outstanding questions:

  1. Should the MR generated in this case be any different from the original version. For example: gitlab-org/govern/threat-insights-demos/verification-projects/cwe-samples!7 (closed)
    1. Decision: The only difference is that the original version links to the vulnerability, while the new version will link to the merge request (MR 1)
  2. It seems to makes sense to add the comment in MR 1 on the line where the vulnerability was detected, but that pattern might make less sense for multi-file resolutions. What do we think?
    1. Decision: As we currently support only single-file findings, this does not need to be decided now. We will add a comment for the line detected in the finding.
  3. Are there any concerns about MR 2 being a nested dependency? It's a nice use of GitLab features, but it does also introduce friction.
    1. Decision: No. We discussed this might be overbearing to the user. And would cause annoyance if the button was clicked unintentionally.

Resources

  1. Local setup https://handbook.gitlab.com/handbook/engineering/development/sec/govern/threat-insights/ve_vr_setup/

Implementation Plan

  1. Switch MR finding workflow to create a "fix" merge request (MR 2)
    1. MR 2 should target the branch of the initial MR (MR 1)
    2. MR 2 description should link to MR 1. (example
      1. MR created from vulnerability finding: !4+
  2. Add a line number comment to MR 1 with this text and link to the new fix MR (MR 2):
    • Vulnerability Resolution has generated a fix in an MR for this vulnerability finding.
    • In order to apply the fix, merge the following MR: !5+
  3. Update documentation https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution-in-a-merge-request

possible improvements:

  • we can possibly move the MergeRequestLinks creation async to make the UI seem snappier (src)
Edited by Michael Becker