## **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 * Security Infrastructure (possibly for ES work) ### DRIs * PM: @mclausen35 * Engineer: * EM: @ajbiton * ~"group::security insights" ## 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. ## 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) | | @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)) ### 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/))