Skip to content

Design: Restructure Project Security Dashboard

Problem to solve

The current Project Security Dashboard is effectively a single page housing a vulnerability list and some basic vulnerability count information; it is not really even a dashboard. This setup limits the potential to expand functionality both for the vulnerability list as well as having a true dashboard in the future.

Intended users

User experience goal

Users will have a new Vulnerability Report section which contains only the vulnerability list so they can focus on managing vulnerabilities for their project. The current Security Dashboard page will be updated with a new chart that provides a more insightful, interactive way to see project-level vulnerability trends over time.

Proposal

Transform the current single-page experience into a new layout and menu structure that sets the framework for future expansion and specialization of security components at the Project level. This will primarily entail breaking apart the existing page:

  1. Move existing vulnerability list to a new Vulnerability Report menu item (still under Security & Compliance)
    1. keep all associated components with the current list such as the list filters, counts by severity tiles, and report export.
    2. ensure the severity totals in the tiles reflect filters applied to vulnerability list
  2. Keep the Security Dashboard menu item but replace the content with a new metrics widgets showing vulnerabilities by severity over time (see mocks)
    1. Default to showing Critical, High, and Medium vulnerability data series on; Low and Unknown are still available but user must click to toggle visibility
    2. Restrict maximum time scale to a reasonable length that prevents performance concerns. If no performance concerns, make unbounded or use first vulnerability's detected date. Otherwise, ideally we can do 1 year.

Mocks

Posted in Design Tab

🖍 Link to Figma mocks View all levels (project, group, instance) in one location

Further details

We should be cognizant that the vulnerability list is currently a shared component across all 3 Security Dashboards. We need to be thoughtful about keeping this pattern for efficiency of future feature development while balancing against the possible complexity this might be add as Project, Group, and Instance-level lists potentially diverge in information displayed.

Permissions and Security

No permissions changes from the current Project Security Dashboard. The updated dashboard screen with new chart as well as the new Vulnerability Report menu item should have the same access permissions as the current Project Security Dashboard. If I can see the dashboard today, I can see the existence of both menu items still.

Documentation

This will require updating all references to the Project Security Dashboard to reflect the new menu placement.

A new section on the new vulnerabilities over time chart is also needed. Be sure to call out this chart is dynamic:

  1. Clicking a data series in the legend will dynamically toggle on or off visibility
  2. Using the zoom and scroll feature, you can adjust the time period displayed
  3. Call out any upper bound determined for how far back in time you can display

Availability & Testing

For the new vulnerability trends chart, we need to consider any potential performance concerns if we all looking over too broad a period of time. A load/performance test should be part of the evaluation of any upper limit (e.g. one year). Assume that a high-volume project may reasonably have over 10,000 vulnerabilities (of all severity levels) over the course of a year. In some cases, this can be over 100,000 for a single project.

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

What is the type of buyer?

GitLab Ultimate

Links / references

Edited by Matt Wilson