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).
- 0:00 - 1:26, context and current UX
- 1:26 - 12:12, MVC review
- 12:12 - end, resulting issues and next steps
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)).
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sam (Security Analyst)
|A. Activating feature: If dependency 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:
|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
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 (
Permissions and Security
- Permission to create MR in the project must be aligned with permission of enabling auto-create
- 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