## **Business Case** This is related to the security dashboard initiative. The security dashboard initiative has been: 1. Verified by over a [dozen customers ](https://gitlab.com/groups/gitlab-org/-/epics/18203#note_2885333541)worth $14.1M+ in ARR. 2. Addresses a significant competitive gap that arises frequently in POVs. 3. Broadly enables upsells by proving the value of Gitlab to executives. 4. Target metric: Increase the number of 'valuable' sessions on the reporting page (between org, group, and project) ## Executive Summary Users need to be able to get a broad view of both their vulnerability report and their security dashboards. Today, they are limited by having the most broad view of data be the 'top level group', of which they are usually multiple. CISOs and leaders want to be able to 1. Perform triage and report on across the complete set of vulnerabilities using the org level vulnerability report 2. Report metrics regarding the whole organization to CISO-level leaders using the org level dashboards Additional Detail 1. **What problem are we solving? -** Today users do not have an understanding of their entire appsec program in the case where they have multiple top level groups. This means they can not conduct global triage of vulnerabilities (in cases where ownership is not segregated by groups) and can not see visual aggregations of their whole program either. 2. **Why this problem and not another?** - Improving the scope of visibility for vulnerability management is a use case that nearly every customer needs to properly run their program. This has been mentioned in most roadmaps, reviews of new security dashboard and vulnerability management features, and other customer calls. 3. **What outcome/impact are we driving? -** The outcome is better visibility for triage and reporting use cases. 1. [**$28.8M in affected ARR**](https://docs.google.com/spreadsheets/d/1OJH1VESinAA0zD9IZkmZIjipB82mQiBNJw1vzfXsFkU/edit?gid=0#gid=0): \~30 enterprise customers have explicitly requested this capability, based on analysis of [Organization-level security visibility and reporting capabilities, &10048](https://gitlab.com/groups/gitlab-org/-/epics/10048) 2. Competitive disadvantage against point solutions (Snyk) that offer enterprise-wide visibility ### Dependencies * Organization object support ### DRIs * PM: @mclausen35 * Engineer: @subashis * EM: @ajbiton * ~"group::vulnerability management" ## Scope ### In scope 1. Support the new security dashboard at the 'organization level' 2. ElasticSearch Support only ### Out of scope * PostGres support * Security Attributes Filtering. These are not yet available on Organization level and depend on Security Controls team. ## Decisions | Date | Decision | Why | Impact / follow-up | Status | |----------|--------|----------|----------|-----------| | 2026-08-13 | Include projects in personal namespaces in organization-level Security Dashboard results. | They belong to the organization and the owner can see them, so they should be included. | If we want to exclude them or be able to filter on this, we'll likely need a new field in ES and performance testing. | [PROPOSED](https://gitlab.com/gitlab-org/gitlab/-/work_items/605376#note_3667822382) | | 2026-08-14 | Ship the initial organization-level Security Dashboard without the SAST triage and remediation chart. | The chart is blocked because not all required data is currently available in Elasticsearch. | Sync the necessary data to ES, then add the chart in a follow-up. The group- and project-level charts can reuse the same ES layer and improve performance. | [PROPOSED](https://gitlab.com/gitlab-org/gitlab/-/work_items/608284#note_3688987380) | | 2026-08-24 | Ship the initial organization-level Security Dashboard without Security Attributes Filtering. | Security Attributes are not yet available on Organization level and depend on Security Controls team. | Security Controls team need to add Security Attributes on on Organization level. | [Blocked](https://gitlab.com/groups/gitlab-org/-/work_items/19154#note_3471072234) | ## Outstanding Questions | Question | Answer | Assignee | Priority | Blocking? | |----------|--------|----------|----------|-----------| | [Can we handle multiple TLGs in an organization?](https://gitlab.com/groups/gitlab-org/-/work_items/19154#note_3533896783) | Yes | @subashis | ~"priority::2" | No | ## Functional Requirements ### Page Level Support * [ ] Project * [ ] Group * [x] Organization * [ ] Pipeline \> Security (findings) * [ ] MR Security Widget (findings) * [ ] Security Center * [x] Security Dashboard ### Workflow * [x] Requires ~documentation ## Non-Functional Requirements ### Product Usage * [x] Requires new instrumentation ([docs](https://docs.gitlab.com/development/internal_analytics/internal_event_instrumentation/quick_start/)) ### Feature Flag Usage * [x] This feature should be released behind a feature flag? ([docs](https://handbook.gitlab.com/handbook/product-development/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags)) Feature flag: `organization_security_dashboard` ### Testing * [x] Requires new E2E test coverage ([docs](https://docs.gitlab.com/development/testing_guide/end_to_end/)) * [ ] Requires extended manual / UAT phase * [ ] Performance testing needed ([testing](https://docs.gitlab.com/ci/testing/load_performance_testing/)) ## Verification **Organization for verification:** https://gitlab.com/o/vulnerability-management-verification/-/security/dashboard?riskScore.groupBy=project