### Theme statement Users need to get a high level overview of their security posture, identify trends, current risks and drill down into items that need attention. They also need a way of measuring successes (or regressions) for security updates for leadership and to assess the efficacy of their security efforts. ### Release Plan The release plan is meant to enable focus on specific reporting use cases. The first use case is actionable reporting, which means being able to identify risky areas in the program. The second use case is reporting program success to executives. Most modules serve both use cases, but in general their primary category is as follows 1. Actionable reporting 1. Vulnerability counts 2. Vulnerabilities over time 3. Total Risk Score 4. Vulnerability Age 5. Top CWEs 2. Reporting program success 1. Vulnerability resolution rates 2. Scanner Adoption 3. Vulnerability Age 4. Top CWEs The modules are prioritized today according to how each use case is served. 1. Release to targeted design partners - before the initial Tier 1 release, some customers have confirmed 2. The first Tier 1 release is meant to broadcast the first use case of actionable reporting 3. The following releases enable a 'steady drumbeat' of features regarding the first use case while also building toward the second. 4. The second tier 1 release is meant to broadcast the second use case of 'reporting program success' | Panel / Feature | Phase | |-----------------|-------| | [Security Dashboard Page or Panel Level Filters: Severity, Status, Scanner, Project, Business Unit](https://gitlab.com/groups/gitlab-org/-/epics/17287) | \| Release to targeted design partners / customer zero \| | | Project Scope | | | [Security Dashboard - Chart 1 Project Scope: Total open vulnerabilities per severity](https://gitlab.com/groups/gitlab-org/-/epics/17073) | Release to targeted design partners / customer zero | | [Security Dashboard - Chart 2 Project-Scope: Open vulnerabilities over time](https://gitlab.com/groups/gitlab-org/-/epics/17076) | Release to targeted design partners / customer zero | | Multi Project Scope | | | [Security Dashboard - Chart 1 Multi Project Scope: Total open vulnerabilities per severity](https://gitlab.com/groups/gitlab-org/-/epics/17411) | Release to targeted design partners / customer zero | | https://gitlab.com/groups/gitlab-org/-/epics/17413+ | Release to targeted design partners / customer zero | | [Security Dashboard - Chart 7 Multi Project Scope: Total risk score](https://gitlab.com/groups/gitlab-org/-/epics/17425) | Tier 1 / GA Release - Story on 'Actionable Dashboards' | | Release 2 | Q4+ | | [New Security Dashboard: Business Context Filters](https://gitlab.com/groups/gitlab-org/-/epics/18201) | \*dependent on SPM Business Context Release | | [Security Dashboard - Chart 7 Project-Scope: Total risk score](https://gitlab.com/groups/gitlab-org/-/epics/17074) | 'Actionable Dashboards' release follow up | | [Security Dashboard - Chart 4 Multi Project-Scope: Vulnerability Age](https://gitlab.com/groups/gitlab-org/-/epics/17417) | 'Actionable Dashboards' release follow up | | [Security Dashboard - Chart 4 Project-Scope: Vulnerability Age](https://gitlab.com/groups/gitlab-org/-/epics/17285) | 'Actionable Dashboards' release follow up' | | [Security Dashboard: Chart 6 Multi Project Scope: Top CWEs](https://gitlab.com/groups/gitlab-org/-/epics/17422) | 'Actionable Dashboards' release follow up' | | \| [Security Dashboard: Chart 6 Project Scope: Top CWEs](https://gitlab.com/groups/gitlab-org/-/epics/17286) \| | 'Actionable Dashboards' release follow up' | | [Security Dashboard - Chart 5 Multi Project -Scope: Vulnerabilities resolution velocity over time](https://gitlab.com/groups/gitlab-org/-/epics/17419) | Beta release to design partners | | | | | [Security Dashboard - Chart 5 Project-Scope: Vulnerabilities resolution velocity over time](https://gitlab.com/groups/gitlab-org/-/epics/17075) | Tier 1 / GA Release - Story on 'Reporting to Executives' | | [Security Dashboard - Chart 3 Project Scope: Scanner Adoption](https://gitlab.com/groups/gitlab-org/-/epics/17284) | Follow up on 'Reporting to Executives' | | [Security Dashboard - Chart 3 Multi Project Scope: Scanner Adoption](https://gitlab.com/groups/gitlab-org/-/epics/17415) | Follow up on 'Reporting to Executives' | ##### **List of considerations for Releases 3+** * Top 10 CWEs can be expanded to include Top 10 CVEs and OWASP Top 10 * Further display customization * Being able to hide certain panels, adjust the data within a panel, and create new panels based on any vulnerability data available.) * Ability to create multiple dashboards, clone and customize dashboards or individual panels, and/or saving and switching views of one dashboard. For example: * Global Dashboard: default view, cannot be modified, no filters. * Project at Risk: shows only Critical and High vulnerabilities on a selection of projects. * Legacy Projects: view limited to certain projects with specific requirements. * Filtering by a particular vuln type to address a "zero day" use case (see [thread here for more](https://gitlab.com/gitlab-org/ux-research/-/issues/3433#note_2556688718)) ### Self-managed Support The new security dashboard leverages https://gitlab.com/groups/gitlab-org/-/epics/13510+. Elasticsearch is available across SaaS/gitlab.com and Dedicated. Self-managed instances have several considerations (technical and licensing). There is no timeline for self-managed support. SSOT issue is https://gitlab.com/gitlab-org/gitlab/-/issues/525484+ ### User Story and Requirements As an AppSec leader, I am tasked with overseeing the organization's security program. I need to measure and improve efficiency and effectiveness, communicate security posture to leadership, and ensure that current risks are being appropriately addressed. To measure success, I need to ensure that our vulnerability backlog is reducing over time and that vulnerabilities are addressed in a timely manner. Charts like "Vulnerability Counts Over Time" and "Vulnerability Velocity Chart" help track whether we are fixing vulnerabilities faster than they are being introduced. "Vulnerability Age" allows me to see if issues are being remediated within SLA timelines, ensuring operational efficiency. Additionally, "Scanner Coverage" helps assess adoption and effectiveness of scanning tools across different teams. To improve success metrics, I need to be able to root cause positive and negative trends. This involves filtering down by severity, scanner types, teams, and business units to understand what is driving improvements or setbacks. By identifying which teams are struggling with remediation or which scanners are yielding excessive vulnerabilities, I can refine processes and resource allocation. I also need to ensure we are addressing the biggest risks by focusing on the most prevalent and critical vulnerabilities. "Top CVEs" helps identify the most recurring threats across our environments, allowing us to prioritize remediation efforts on the most impactful issues. "Static Risk Score" provides a high-level snapshot of our overall security health, ensuring alignment with risk management goals. By leveraging these insights, I can confidently drive data-backed decisions, improve security efficiency, and communicate meaningful progress to leadership. **Requirements** (prev. in this google doc: https://docs.google.com/document/d/1Jo4NAHkYhdNnVrnEky3wAGlw7UL7Xb3RbxCk4flXe2A/edit?tab=t.0) _Sec. 1: Filters_ Filters are a key part of the reporting experience. Filters make the experience more dynamic, and can support general comparisons, root cause analysis, and allows for contextual analysis. Support filters for  * Severity * This will impact Vulnerability Counts over Time, Vulnerability Age, Vulnerability Velocity Chart, and Top CVEs. It will not impact Risk Score nor Scanner Coverage. * Vulnerability status * This will impact Vulnerability Counts over Time, Vulnerability Age, Vulnerability Velocity Chart, and Top CVEs. It will not impact Risk Score nor Scanner Coverage. * Scanner type * This will impact Vulnerability Counts over Time, Vulnerability Age, Vulnerability Velocity Chart, Scanner Coverage, and Top CVEs. It will not impact Risk Score. * Project (at the group level) * This will impact all charts. * Time periods (last 7/30/90 days) * This will impact all charts below except Top CVEs, as those are ‘point in time’ metrics. * This will impact the _time range that is presented on the x-axis_ of vulnerability counts over time, vulnerability velocity chart, and scanner coverage.  * This will impact _the total results that are aggregated_ in the vulnerability age chart and risk score (since there is no continuous time range y-axis). * Risk score may become entirely static based on research.   * [Business units](https://gitlab.com/gitlab-org/gitlab/-/issues/515932) (https://gitlab.com/groups/gitlab-com/-/epics/2468 OR [Business Contexts](https://gitlab.com/gitlab-org/gitlab/-/issues/515932) (SPM feature) * This will impact all charts below. General Filter Requirements * Allow for multi-selection (except time period) * Allow for comparative filtering (group by) - ie how does my burndown for critical severities compare to my high severities? How does my risk score for this project compare to this other one? * Filters won’t apply to all panels, so there must be some way to handle that for UX to determine  * Regardless of the above, in the UI the filters might ‘live’ at the page level or the module level. * We will not include 'groups' as a filter or group by in v1 as it is complex to select what 'level of hierarchy/subgroup' to apply, and is not as sensible to the end user as business context  _Sec. 2: Reports_ Chart 1: Total Vulnerabilities Open Today by Severity 1. Calculation: This is only the total vulnerability counts that are open today. It should be split by severity. This is assumed to be the ‘main datapoint’ that greets you on the dashboard. It is also at parity with many competitors. 2. No filters to be applied here. 3. No groupings need to be applied here. Chart 2: Vulnerability Counts Over Time  1. Calculation: Show vulnerabilities that were in the status ‘**_open’_** during a specific day/week/month (depending on how the x-axis/time renders). This should trend over time. Archived, remediated and dismissed vulnerabilities should not be included.  2. Users should be able to click through the most recent data point to see the set of vulnerabilities that were created in the report. If filters are applied in the dashboard, those filters should be applied at the vulnerability report level.  3. All filters should be available for this graph. 4. Allow groupings by projects, groups, business contexts, severity and scanners 5. Use cases addressed 1. How many vulnerabilities exist in my environment today? 2. Are vulnerabilities going down or up over time? 3. What groups are vulnerable?  4. How many vulnerabilities of X severity do I have? 5. What projects are most vulnerable? What groups are? How have they changed over time? 6. What scanners are returning the most vulnerabilities? The least? How does that change over time. 7. Static counts of vulnerabilities can be captured here, or in the vulnerability report. Chart 3: Scanner Coverage 4. \# of projects configured to use a scanner during a specific day/week/month 5. Filtering 1. Filtering should only be applicable for project, business unit. 2. If the report is on a project or group level, and the scanner is not being used at all on that project and group - then we should disable the filtering capability.  6. Grouping 1. No grouping is required for scanners (aside from the default view of group by scanner) 7. Use cases addressed 1. Are my teams using gitlab security tools?  Which have the strongest adoption and which have the least? 2. Which tools are they using? Are some tools adopted more than others? 3. How frequently are scans run?  4. The health of a pipeline is NOT a use case. That should be handled outside security dashboards. 1. Understanding things like “Are certain scanners failing and needing re-configuration” or “ Did certain teams stop scanning due to multiple failures” are better served at a more granular view. 2. On the same note - Tracking successful or failing merge requests is interesting but this graph does not target that. That may be a separate reporting module.  Chart 4: Vulnerability Age 1. Calculation: Show the average # of days for a vulnerability to be in open state. Age is # of days before a transition to Dismissed, Remediated, or Archived. Vulnerabilities that are open should be captured in this graph too.  1. Archived vulnerabilities should likely be filtered out of this graph entirely, because archived state occurs at a regular cadence so the ‘vuln age’ will appear to converge around the regular archive cadence. 2. Filter behavior: Allow the ability to remove certain statuses from the calculation. For example, deselecting Dismissed will show the vulnerability age of vulnerabilities that remain open and vulnerabilities in remediated status. 3. Filter behavior: Otherwise filters should behave as expected - IE, if severity filter applies, only the age of vulnerabilities with selected severities should be calculated. Same with scanner, for example.  4. All groups should be represented as well. For example, a 'filter' will remove vulnerabilities from the counts. A group will re-color-code the histogram according to the 'counts' of each vuln that fits that group. One group should be applied at a time. 5. This is not a trend graph. It is more of a distribution / histogram / box plot. The y-axis can remain as days. In the future we should allow customize it for SLA 6. Click throughs are not required in this graph because the vulnerability age is not a filter that is present on the vulnerability report.  1. Click throughs may be implemented once the ‘time’ filter is available in the vulnerability report (possible Q3 priority) 7. Use cases addressed 1. Are my vulnerabilities being remediated within my SLA?  2. Are vulnerabilities of a higher severity being remediated faster than others? 3. Are vulnerabilities of different scan types being remediated faster than others? 4. Are specific groups or teams remediated within SLA? Chart 5: Vulnerability Velocity Chart 1. Calculation: Show the total Show vulnerabilities that were newly opened during a specific day/week/month (depending on how the x-axis/time renders). Show the total number of vulnerabilities that were transitioned to a Remediated/Dismissed/Archived state within the same time period  1. Note: according to [this](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/184461#note_2399421853): a separate implementation may aggregate opened vulnerabilities and closed vulnerabilities over time, so each point on the graph represents all vulnerabilities that were opened from date X to origin, and vulnerabilities that moved to closed (remediated/resolved/dismissed) from date X to origin. 2. Archived is likely irrelevant in this view since it only focused on net new opens and status changes. 2. All filters should be available for this graph. 3. This is a trend graph over time. 4. Grouping (comparative filtering) is not likely available for this graph as that may be too complicated with multiple trendlines 5. Use cases addressed 1. Am I fixing vulnerabilities faster than I am creating new ones? Is my backlog decreasing? 2. Is my backlog of vulnerabilities of X severity being decreasing or is it growing? 3. Is my backlog of vulnerabilities from a specific scanner being decreasing or is it growing? 4. Is the backlog of specific teams or groups growing or decreasing? Chart 6: Top CVEs 1. Calculation: Show the number of instances of a CVE within a given project or group (apply filters as well). An instance of a CVE is the number of times the vulnerable library is imported via a manifest file (or transitively imported) across a set of projects or groups. 2. This is a view of the current state of the customer, not a trendline. 3. Only project / business unit / severity filters should be available for this graph. Time and scanner are not relevant. 4. No groupings required. 5. Use cases addressed 1. What are the biggest bang-for-my-buck focus areas? 2. How common is this new, trending CVE (like log4j) compared to other issues?  Chart 7: Static Risk Score 14. Calculation: Show a single 1-100 number to represent ‘risk’ (defined by Vuln. Research team) 15. Severity and scanner filters should not be applicable to this filter as it is only relevant looking at the total scope of the vulnerabilities across environments.  16. Time period can filter to vulnerabilities ‘created’ during that time.  17. Grouping by projects and business contexts should be available for this. 18. Use cases addressed 1. What is the health of my environment right now?  2. What is the health of a specific team, group or project over a specific time period? _Sec. 3: Other Requirements_ 1. The dashboard should support URL-sharing/deep linking, so filters at both the panel and page level should be present in the URL. 1. This is preferable to saved views from an implementation perspective, but saving views is another ‘phase 2’ requirement: users should be able to save a filter set at the page and panel level with a custom name. The user should be able to select it from a list if they returned to the page, even without filtering. 2. The filters and reports should exist at both the project, group, and instance level. 1. Supporting it at a higher level first and allowing for filters to specific projects, groups, (and Business Units/contexts) is OK for first deliverables 3. Feature flag support - each module should have a feature flag. 4. Maintain Old View - Users without elasticsearch should not get the new dashboard as it will break. So there must be a way to prohibit them from accessing it. 5. Data mobility - the data must be available via API to pull into third party systems like Splunk #### Example customer notes and requests [Comprehensive list](https://docs.google.com/document/d/1oNC8E4jKap8tmnsGNe6rwmkp0IxI-z0pDx_urLdWCkk/edit?usp=sharing) (internal) * Specific customer requests [here](https://gitlab.com/groups/gitlab-org/-/epics/16517#note_2322633960) * https://gitlab.com/gitlab-org/ux-research/-/issues/2745#note_1720638901 Customer is interested in scanner coverage * https://gitlab.com/gitlab-org/ux-research/-/issues/2745#note_1741351994 Customized time frame reports Security Dashboard - View Results by Quarter / Year * **Problems Raised by customers in** [UX research deck](https://docs.google.com/presentation/d/133Z88NZUhNlXlPry0n2FnTq5EMYRINOe5p_9nEopiHg/edit) * Customers want the Security Dashboard to give them a visualization overview of all of their vulnerabilities on the Vulnerability Report, in addition to trends over time. They need to see more than a breakdown by severity alone.Examples: * Which projects are the most vulnerable? * What work was done on vulnerabilities? How many were resolved vs dismissed? * Are the developers introducing more or fewer vulnerable dependencies vs 1 month ago across projects in a group? * Did we improve the number of vulns between releases? “If there’s a surge in vulnerabilities, I would want to see which scan is affected, whether there a new component included, if the team introduced a new scan, or what other reason could be causing these changes?” * What are the most detected CWEs? “We do annual training on security, so our team could determine that those kinds of issues need more training.” * What are the trends across branches? “I want to be able to say ‘You can see a lot of vulns on the development branch, but they’re going down by the time it gets to production branch.’” * What percentage of vulnerabilities are false positives? * What is our average time to remediation? * I can’t look at trends by scan type, IP addresses, by technology (e.g.Java)  * No SLAs **-** “We have obligation towards our customers to **make sure our vulns are addressed at the right time**.” * “We would love to have our own dashboard, where **we can add a list of projects** that I we know are related to something specific. For example, for us, a part of the product could be five different projects from different places in GitLab, but we consider them one product. And for that one product, we would like to have a view telling us how many vulnerabilities currently exist? When would each vulnerability like in existence? **If we could configure SLAs to see which vulns are in breach or at risk of being in breach because they're up in the next week or so**. So that's definitely a view that would be super helpful for us.” * https://gitlab.com/gitlab-com/account-management/exfo/exfo/-/issues/19#note_2252063873+ - Customer request for vulnerability trend analysis and coverage * https://gitlab.com/gitlab-org/gitlab/-/issues/466604#note_2252020317 - Customer request for per project policy coverage **Previous work consolidated to this issue:** * [UX Research: Understand Important Vulnerability Metrics and Security Dashboard Requirements](https://gitlab.com/gitlab-org/ux-research/-/issues/2745#top) * [Explore custom dashboards solutions for Security Dashboards](https://gitlab.com/gitlab-org/gitlab/-/issues/9315#top)  * [Spike: Investigate into Security Dashboard](https://gitlab.com/gitlab-org/gitlab/-/issues/425765#top) ## List of Issues **Definitions** * Open vuln = Vuln in “Need Triage” or “Confirmed” * Closed vuln = Vuln in “Resolved” or “Dismissed” <table> <tr> <th>Headline</th> <th>Example UI</th> <th>Issue</th> </tr> <tr> <td>Security Risk Management - Introduce Application / Business Unit Scope</td> <td>In the issue</td> <td> [https://gitlab.com/groups/gitlab-com/-/epics/2468+](https://gitlab.com/groups/gitlab-com/-/epics/2468) </td> </tr> <tr> <td>Security dashboard component - Total Risk Score of scope</td> <td>In the issue</td> <td> https://gitlab.com/gitlab-org/gitlab/-/issues/517329+ </td> </tr> <tr> <td>Security dashboard component - Total Open Vulnerabilities per severity</td> <td>In the issue</td> <td> https://gitlab.com/gitlab-org/gitlab/-/issues/517330+ </td> </tr> <tr> <td>Security dashboard component - Open Vulnerabilities over time (trend graph)</td> <td>In the issue</td> <td> https://gitlab.com/gitlab-org/gitlab/-/issues/517328+ </td> </tr> <tr> <td>Security dashboard component - Vulnerabilities resolution velocity over time (trend graph)</td> <td>In the issue</td> <td> https://gitlab.com/gitlab-org/gitlab/-/issues/517327+ </td> </tr> <tr> <td>Security dashboard component - Vulnerabilities resolution velocity - total numbers</td> <td>In the issue</td> <td> https://gitlab.com/gitlab-org/gitlab/-/issues/517326+ </td> </tr> <tr> <td> Aging information - Open Vulns \> 30 day, Open Vulns \> 60 days, Open Vulns \> 90 days </td> <td>  </td> <td> https://gitlab.com/gitlab-org/gitlab/-/issues/517324+ </td> </tr> <tr> <td>Security dashboard components - Top Vulnerabilities - A list of the top 10 vulnerabilities according to the amount of occurrences.</td> <td> {width="321" height="268"} Examples 2: {width="348" height="239"} </td> <td> https://gitlab.com/gitlab-org/gitlab/-/issues/517325+ </td> </tr> <tr> <td>Security dashboard component - Provide categorised view of vulnerabilities based on different parameters</td> <td>In the issue</td> <td> https://gitlab.com/gitlab-org/gitlab/-/issues/517323+ </td> </tr> <tr> <td>Security Dashboard component - scoped projects tabular view</td> <td>In the issue</td> <td> https://gitlab.com/gitlab-org/gitlab/-/issues/517322+ </td> </tr> <tr> <td>Security Dashboard component - scoped projects tool coverage</td> <td>In the issue</td> <td> @smeadzinger - I think this is more in you area, so I suggest you define the requirements on this one Formerly: https://gitlab.com/groups/gitlab-org/-/epics/5773+ New: https://gitlab.com/gitlab-org/gitlab/-/issues/546265+ </td> </tr> <tr> <td>Security events audit</td> <td>  </td> <td> [Design issue](https://gitlab.com/gitlab-org/gitlab/-/issues/517660) (opened and proposed by Becka) </td> </tr> </table> **Why is this** ~"group::security insights"**'s top priority for 2025?** This has been identified as the [biggest underserved opportunity](https://docs.google.com/presentation/d/1yacfUACleHjJ5n2q6MhXitDAUUWmOwsMaQfDZycqTtY/edit?usp=sharing) for the FY25 JTBD/ODI at GitLab for the Sec section: > **1)  Select the initial triage areas for immediate focus** > > Minimize the time it takes to identify the highest-priority areas for immediate vulnerability triage. > > (Opportunity Score: **13.53**\* | I:9.41 S:5.29) DRI: `@jmandell` ### Design vision Please review this video for a quick overview of our north star vision for the security dashboard refresh MVC. **Please leave any feedback you have in the corresponding research issue here** and cc `@beckalippert`: https://gitlab.com/gitlab-org/ux-research/-/issues/3433+ :popcorn: https://youtu.be/cijGIXtMwOU _Note that we are aware that this proposal is not comprehensive of **all** visualizations that **all** teams may expect from a security dashboard, but we believe that these will provide the most value with the resources we have and priorities identified for FY26. In the future, we'd like to continue iterating on and adding to this concept. We are actively collaborating with the Product Analytics team so more to come as capabilities unfold across our internal teams._ As of July 21, 2025, our MVC is as follows. **Note that there are ongoing conversations and this is subject to change**:  ## Resources 1. [Project sync agenda doc](https://docs.google.com/document/d/151dkzgLMWFUSQAJykOaf8O__Um1zqF7XuLJwo3eb3qE/edit?tab=t.0) <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> > [!important] > > This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc. <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION-->