Skip to content

Suggested Solution (was Auto-Remediation): auto-create merge request when solutions are available

Problem to solve

When there are solutions available to known vulnerabilities, users would need to: go to security dashboard, find available solutions, and then create an MR (or download patch or issue) to fix. This is a cumbersome process because 1) the flow can be time-consuming (needed for each individual fix one-by-one) and 2) when solutions are available: insight is not displayed or communicated to the user on the dashboard UI (it's only seen once the user selects to see vulnerability details, see current UX flow below).

Current UX/UI
0

🎥 view MVC walkthrough

  • 0:00 - 1:26, context and current UX
  • 1:26 - 12:12, MVC review
  • 12:12 - end, resulting issues and next steps

Further details

Context: This is a follow-up implementation issue to the auto-remediation discovery #14059 (closed). This implementation focuses on auto-creation of merge requests with known solutions. There is UX research ux-research#530 (closed) underway looking at this MVC and to inform our upcoming discovery, which is focused on auto-merging auto-created merge requests. Current auto-remediation capabilities will affect projects that are using dependency scanning and using yarn. As we evolve the UX for auto-remediation our objective is for a 1) generic auto-remediation UX that handles multiple capabilities (consistent UX across different capabilities) and 2) geting closer to out-of-box UX (meaning it works without configuration). Example of upcoming capability is #35433 (closed) (based on #9384 (closed)).

Intended users

Proposal

A. Activating feature: If dependency and/or container scanning is configured the feature is opt-in by default. User may opt-out of the feature on the configuration screen. Option will be disabled is configuration is not complete.
a
B. Author of the merge request: GitLab-security-bot per discovery
b
alternative/original, revised per user feedback 1a
C. 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. (flows from project dashboard)
c
D. Findability of auto-created MRs: The auto-created MRs will be created with a label assigned by the system: GitLab-suggested-solution. Also, could be found by the author GitLab-Security-Bot
d
E. User awareness display: when there are MRs created, this messaging is shown on the dashboard. This additionally could help with learnability, as it will take the user to the MR list page with the label applied (GitLab-suggested-solution).
e

Permissions and Security

  • Permission to create MR in the project must be aligned with permission of enabling auto-create

Documentation

...

Testing

  • Possible race condition: auto-create is enabled but MR not created before we display vuln in the dashboard (e.g. sidekick worker overloaded).

What does success look like, and how can we measure that?

  • User can easily setup the feature
  • User understands what current auto-fix capabilities are available
  • User can find auto-created MRs

These questions and more are in UX research: ux-research#530 (closed)

What is the type of buyer?

GitLab Ultimate

Links / references

Implementation plan

1. Create the new setting

Implementation issue at #216026 (closed)

backend ( weight 3) #215668 (closed)

  • Create and push the suggested_solution feature flag.
  • Create an API endpoint to toggle the new project setting Automatically create MRs for different report types.
  • Those settings should be enabled by default.

frontend (possibly frontend-weight3) #215682 (closed)

  • Create the new Auto-fix vulnerabilities section in Security & Compliance > Configuration (picture a.).
  • Implement API calls to toggle the setting.

2. Automatically create MRs & user awareness

Implementation issue at #216027 (closed)

backend ( weight 5) #215669 (closed)

  • Register the bot user GitLab-security-bot that will author auto-fix MRs.
  • Make GitLab-security-bot's profile link available to the frontend (HAML).
  • Automatically create remediation MRs assigned to GitLab-security-bot and labelled with gitlab-vulnerability-auto-fix whenever an available solution is detected for a given vulnerability.
  • Notify the users that MRs were created via an alert/flash message (picture e.).

frontend (possibly frontend-weight2) #215684 (closed)

  • Display the information exposed by the backend to display either the lightbulb icon or the Autofix: link (picture c.).
  • The alert mentioned in the backend part might require frontend work. TBC.
Edited by Neil McCorrison