Discovery: How do we MVC an MR / commit for Auto Remediation patch without needing human involvement
For MVC please research and find out how we best create an MR (use the MRs we create for Yarn if possible) and automatically, without human intervention apply, run that MR, and if it's green push it.
Ideally this should be generic to any scan or solution that proposes an MR solution.
Problem to solve
Auto Remediation is able to create a new merge request if a fix is available for a given vulnerability.
Changes should by automatically merged into the original branch if the two following conditions are met:
- the pipeline is green (patch is not introducing errors)
- the vulnerability has been fixed by the change (via security reports feedback)
Target audience
- Sasha, Software Developer
- Sam, Security Analyst
Proposal - Discovery should answer
- How a user (maintainer level makes sense if in project and group settings area?) will enable this feature. Note in the future user can set parameters (feel free to consider now if you want but don't go too deep as they are outside MVC) such as only for high, or only for License Compliance, or only for combination LC + High, and they should be able to set this at group and project levels eventually (where group allows minimum vs default). Note: I left it slightly open on the scanner as I want it to work for any finding with a suggested MR, if BE says they need one to start we start with whichever is easiest in their opinion.
- how do they turn it off
- should they be able to pause it but keep settings (if any)
- How will a user be notified this occurred? At a minimum / in addition we should post a comment in the original merge request (if any).
- how do we actually run it, and decide it's OK, and push it?
- what user will be used / responsible? (bot/maintainer, have we discussed having a security bot) Note: this should NOT override if they require a review, at this time (mvc) if they require a review it will need to wait on review (future i think that also should be a setting - but a real user like the maintainer would need to be the i take responsibility i think?)
- ideas about where to push/promote it in UI (to get people to turn it on)
major issue how are we able to tell there is one vuln in multiple locations vs multiple vulns. (maybe do one at a . time and then re-scan? open to short term and long term ideas.)
Issues:
- We can leverage the auto-merge on green pipeline functionality, but this flow will not give us feedback about the vulnerability itself. There is no reason to merge if the patch is not solving the original problem.
In order to check that the vulnerability has been fixed, we should:
- identify the original vulnerability we are targeting
- check if it is still present in the new report
Since we are creating the new branch from the vulnerable one, we could leverage the "fixed" information in the security report to spot if the change is effective.
The pipeline should be automatically merged only if this check is green.
What does success look like, and how can we measure that?
Plan (set of issues) to deliver MVC
One of which is likely to be a modified Automatic merge for Auto Remediation patches
Links / references
Discovery conclusion, outcome issues, and next steps
- 0:00 - 1:26, context and current UX
- 1:26 - 12:12, MVC review
- 12:12 - end, resulting issues and next steps
1. Implementation MVC
- Issue: #36500 (closed)
- Will reach out to our technical writers to help tighten up UI copy
UX solution validation and provide insights for future iterations
2. UX research issue to look at MVC- Issue: ux-research#530 (closed)
- tentatively scheduled for %12.6, that means findings could inform/influence changes to implementation issue #36500 (closed)
auto-merging of auto-created MRs
.
3. Discovery focused on - #36503
- Will also include looking into: 1) filtering by auto-fix section, 2) re-evaluate auto-created MR author alternative, 3) getting closer to out-of-box UX
#36503; UX solution validation and identifying insights for future iterations
4. Follow up UX research issue on results ofiteration III)
Proposed MVC (Similar/close to design iteration II, but are revised and include trade-offs highlighted in the designs and annotations below. Per feedback from discovery conclusion sync UX/BE/FE (view notes)
A. Activating feature: the UX aimed for the feature to be working/opt-in by default. This would require a ghost user or bot to auto-create the MR. There has in the past been a similar ghost user/trigger, but this has since been deprecated (https://docs.gitlab.com/ee/ci/triggers/#legacy-triggers). We will continue to explore other options in the next discovery (#36503). Given this constraint, a maintainer or above will need to opt-in to the feature. In the proposed MVC, the user that enables the feature will be the MR author by default. An alternative explored is that the user selects the author, but there are two issues here: 1) additional required configuration, 2) audit log implications, since one user selects another. |
---|
B. Discoverability of solutions: there are two cases to cover when displaying available solutions in the MR. 1) when a solution is available, and 2) when an auto-created MR was created. |
---|
C. Findability of auto-created MRs: we initially looked at having the auto-created MRs filtered by category in the MR list, seen in annotation iii in design iteration II. Per BE feedback, we minimized this since it would add a lot more implementation work; so in the below MVC the alternative is that the auto-created MRs will be created with a label assigned by the system, such as vulnerability-auto-fix . The downside to this is the possibility of this is the edge case when the customer creates a label with the same name. As we continue to grow capabilities we’ll work toward the dedicated filter in the MR list in future iterations. |
---|
D. User flows from dashboard: |
---|