Research: Validate First-Class Vulnerabilities approach + high-level user flow
What’s this issue all about?
We are making vulnerabilities first-class objects. This will make them behave like epics and issues, where users can add/edit labels, due dates, milestones, description etc.,
Who is the target user of the feature?
Anyone interacting with vulnerabilities. Typically:
- (Primary) Persona: Security Analyst
- (Secondary)
Persona: Security Researcher - (Secondary) Persona: Software developer
What questions are you trying to answer?
- What is the security triage process today in GitLab?
- What is the journey?
- Where does today's process excel or fall-short?
- What are the JTBD(s)
Core questions
- What are the users' tasks today?
- What is the user experience today?
- What is the current triage and review journey?
What hypotheses and/or assumptions do you have?
- Vulnerabilities are management tools not a workflow tool. They are meant to house and track information related to security findings and their resolution.
What decisions will you make based on the research findings?
- Direction for first-class vulns
- Move into flow and journey creation
- Informed designs based on validated JTBD
What's the latest milestone that the research will still be useful to you?
13.4
Todo:
-
Identify approach -
Generate script -
Review script and make adjustments -
Schedule participants -
Conduct interviews and capture findings -
Aggregate and analyze findings
| Participant + TZ | Study day+time EST | Status | Primary researcher | Notetaker |
|---|---|---|---|---|
| James Ritchy | Spetember 30 (3:00 PM) | Complete | @andyvolpe | @beckalippert |
| Costel Maxim | October 1 (8:30 AM) | Complete | @andyvolpe | @beckalippert |
| Dennis Applet | October 2 (8:30 AM) | Confirmed | @andyvolpe | @kmann |
| Juan Broullon | October 2 (1:30 PM) | Confirmed | @andyvolpe | @kmann |
| Ethan Strike | October 2 (3:30 PM) | Confirmed | @andyvolpe | @cam.x |
| Jeremy Matos | October 3 (9:15 AM) | Confirmed | @andyvolpe | @kmann |
- Link to script
- Link to results board
- Link to research notes
Findings:
Summary:
After conducting the research, I believe we should move toward a page-specific like experience to reduce risk and uncertainty that would be present by going with an epic-like or issue-like object approach. This would be akin to the pipeline page where a user can see all pipelines and their status / important information as well as let the user dive into a page-level experience for more interaction and information.
With minor changes, we can keep the same basic flow we have today, and work toward enhancing the data we have available for vulnerabilities as well as how we present this data to the user. This approach saves us from a large and involved workflow overhaul project and instead shifts our efforts toward enhancing the current process we have in place.
Details:
- We invalidated our assumption that an epic-like object for first-class vulnerabilities is the direction we should take.
- Based on the research, we found that the current pain-point present in the two triage workflows (HackerOne>GitLab & Sec Dashboard > Gitlab issues) would not be solved by creating an epic-like or issue-like object for vulnerabilities.
- We identified a need to create a stable vulnerability object from which most of the vulnerability tracking can take place. References to vulnerabilities need to be confirmed or dismissed by security users and in the future, the associated metadata can be changed and resolution progress tracked to enhance the experience.
- The need to change the status of the vulnerability depending on its life-cycle
- The need to change Severity and Priority
- The need to have Severity and Priority manipulate due dates / SLA
- The current model where vulnerabilities have issues created from them and where engineering teams work to prioritize and remediate vulnerabilities that are own by their code.
- The need to house vulnerability specific information like file, file example, auto-remediate options, activity feed for the vulnerability.
- The information present in the security dashboard is lacking but not by much. Missing:
- First detected date
- Who triaged and when
- Where the vulnerability stands in the triage process
- File/Location
- OWASP Category
- CVE and CWE information
Vulnerability life-cycle diagram from the research:
