Some vulnerabilities have simple solutions that we can fix for the user so that they can spend their time addressing more complex or time-consuming issues.
Proposal
We want to provide Auto Remediate functionalities in GitLab, so when a new vulnerability is found in the code GitLab automatically provides a code change to fix it. This change is then tested and merged if the output is good.
In order to do that, the first step is to know how to fix a given vulnerability. In the case of Dependency Scanning, for example, we could bump the version of the vulnerable library to the closest one where the bug is solved. So we need to know this version.
What does success look like, and how can we measure that?
How many times a user chooses to auto-remediate a vulnerability.
Design
Flow
Wires and mocks
Mocks still need to be created for the pipeline flow
In Pipeline
Initial State
Vulnerability Selected - The expanded area is broken down into quick info, remediation information and overview. Here the user can learn about the vulnerability and take the necessary steps the start the auto-remediation process. 1) Clicking fix will take the user to a new MR with the fix enabled. 2) Clicking on "learn more about this vulnerabiltiy will take them away from the page or bring up a pop-up. (still not sure where this learn more info will come from) 3) Clicking dismiss will clollapse this vulnerability and change it to the dismissed state.
Fixed State When the user returns from the MR they will see the fixed state where they can go back to the MR for this fixed vulnerabiltiy.
Dismissed State
In MR
Mreged. - After the user opts to fix the vulnerability they are taken to an MR (here shown with Auto-merge) with the options to revert or cherry pick
Reverted - If the user notices error rates increase after the merge they can revert the request