## Problem to Solve AppSec teams need to understand if vulnerabilities are getting addressed in a timely manner, or if they are resolved according to SLAs. They also will want to go a level deeper with filters and understand when specific severities are addressed (critical should be done faster than low, for example), how specific teams/groups/projects are doing, and if specific scanner results age longer than others. Going deeper helps root cause why older vulnerabilities are still out there, and helps identify optimization areas. ## Scope #### In Scope 1. The scope will be group, as all these graphs, since the 'Organization Object' is not available (and neither are Business Context filters) 2. Calculation: Show the counts of a vulnerability to be in open state by age range. Age is # of days from first day a scanner discovers it before a transition to Dismissed, Remediated, or Archived. Vulnerabilities that are open should be captured in this graph too. Vulnerabilities that are moved from open-\>closed-\>open can refer back to the first open date. 3. Archived vulnerabilities should be filtered out of this graph entirely. 4. X axis behavior: We will have static x axis of progressively wider "bins": \< 7 days, 7-14 days, 15-30 days, 31-60 days, 61-90 days, 90-180 days, 180+ days. 5. Filter behavior: Filters should behave as expected - IE, if severity filter applies, only the age of vulnerabilities with selected severities should be calculated. Same with report type and project at the global level, and 'security labels'. 6. The severity filter on the panel level is required here. 7. Report type groupings and severity groupings on the panel level should be represented as well. As a reminder, a 'filter' will remove vulnerabilities from the counts. A grouping 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. 8. 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? **Out of Scope** 1. This is not a trend graph. It is more of a distribution / histogram / box plot. The y-axis can be dynamically rendered time. In the future we should allow customize it for SLA 2. 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) 2. Users can go to the vulnerability report and sort by 'detected date' to find the oldest (or newest) vulnerabilities. 3. Grouping by project in panel level. 4. Backend decides the buckets for the age, this is not requested by the frontend. ## Dependencies ## Functional Requirements ### Page Level Support * [ ] Project * [x] Group * [ ] Pipeline \> Security (findings) * [ ] MR Security Widget (findings) * [ ] Security Center * [x] Security Dashboard ### Workflow * [x] Requires ~&quot;documentation&quot; ## Designs Add'l designs to be added  ## Non-Functional Requirements ### Product Usage * [ ] Requires new instrumentation ### Feature Flag Usage * [x] This feature should be released behind a feature flag (`new_security_dashboard_vulnerabilities_by_age`) ### Testing * [x] Requires new E2E test coverage * [x] Performance testing needed