### 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** | | ------ | |  | :movie_camera: [view MVC walkthrough](https://youtu.be/pbRhf0LHgq8) * 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 https://gitlab.com/gitlab-org/gitlab/issues/14059. This implementation focuses on `auto-creation of merge requests` with known solutions. There is ~"UX research" https://gitlab.com/gitlab-org/ux-research/issues/530 underway looking at this MVC and to inform our upcoming [discovery](https://gitlab.com/gitlab-org/gitlab/issues/36503), 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](https://yarnpkg.com/lang/en/). 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 https://gitlab.com/gitlab-org/gitlab/issues/35433 (based on https://gitlab.com/gitlab-org/gitlab/issues/9384). ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) ### 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. | | ------ | |  | | **B. Author of the merge request:** `GitLab-security-bot` [per discovery](https://gitlab.com/gitlab-org/gitlab/issues/197349) | | ------ | |  | <details><summary>alternative/original, revised per user feedback</summary>  </details> | **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) | | ------ | |  | | **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` | | ------ | |  | | **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`). | | ------ | |  | ### Permissions and Security * Permission to create MR in the project must be aligned with permission of enabling auto-create ### Documentation ... <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> ### 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 risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ --> ### 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": https://gitlab.com/gitlab-org/ux-research/issues/530 ### What is the type of buyer? ~"GitLab Ultimate" ### Links / references ### Implementation plan #### 1. Create the new setting Implementation issue at https://gitlab.com/gitlab-org/gitlab/-/issues/216026 ~backend (~ weight 3) https://gitlab.com/gitlab-org/gitlab/-/issues/215668 - 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-weight::3") https://gitlab.com/gitlab-org/gitlab/-/issues/215682 - 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 https://gitlab.com/gitlab-org/gitlab/-/issues/216027 ~backend (~ weight 5) https://gitlab.com/gitlab-org/gitlab/-/issues/215669 - 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-weight::2") https://gitlab.com/gitlab-org/gitlab/-/issues/215684 - 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.