Concept: Risk based security merge request widget
Problem
Today we overwhelm the user with security data that doesn't inform them of what they need to do to continue with the merge.
Problem statement
How might we communicate (in the simplest way) to the user that the merge request is either safe to merge or unsafe and action is needed?
JTBD
When committing changes to my project, I want to be made aware if I am adding risk through vulnerable code, so that I know my changes can be merged without increasing the risk of my project.
Goal
Tell the risk-based story of this merge request by answering:
- Can I confidently merge this?
- Am I blocked from merging this and why?
- What do I need to do to unblock this merge request?
Philosophy
Synthesize information into insights and actions. The MR widget is a proxy for an Application Security Engineer performing a manual code review.
- Reinforce the good and highlight the bad.
- Keep information simple and concise to drive action.
Solution: WIP
Experience
The idea is similar to: #12896 (closed) where we move the security results to a tab and keep the widget experience concise. This allows us to communicate that it's okay to continue or to stop and take action on explicit vulnerabilities before users can merge.
Widget bluprint |
---|
Wire | Wire with action detail |
---|---|
Widget details and breakout |
---|
Widget in MR |
---|
Widget Detail
Variants & interactions
Widget variations | Micro-interactions |
---|---|