## Problem to Solve AppSec doesn't have the a way to understand how quickly teams are fixing vulnerabilities, and if they are getting faster or slower, and what teams / scan type results are speedier and which cause friction. Vulnerability age is for open vulnerabilities. ## Business Case This is related to the security dashboard initiative. <details> <summary>Why the security dashboard initiative matters</summary> 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. </details> * **Target metric:** increase the number of 'valuable' sessions on the reporting page * Secondary metric: number of PDF exports ## DRIs * PM: @mclausen35 * Engineer: @lorenzvanherwaarden * EM: @ajbiton * ~&quot;group::vulnerability management&quot; ## In Scope * Support for project, group, and organization level * A new "MTTR over time" panel: line + bar chart * Weekly "buckets" * Filters: Project, Report type, Security attributes, and Severity * Grouping: All, By Severity, By Report type ## Out of Scope * Grouping by source <details> <summary> Proposed source values [here](https://gitlab.com/groups/gitlab-org/-/work_items/22408) </summary> * fully remediated by AI (MR created and automerged) * remediated by AI+human (MR created by AI, merged by human) * triaged by AI, remediated by human (SDLC agent and/or FP runs on it, no VR runs on it, but is closed or no longer detected) * Fully remediated by a human (No VR, SDLC, or FP runs on it, but is closed or no longer detected) </details> ## Decisions | Date | Decision | Why | Impact / follow-up | Status | |------|----------|-----|--------------------|--------| | 2026-09-14 | Non-rolling. The backend does not return rolling data, and there is no smoothing control | `count` and `sumDays` per week let the frontend compute a rolling mean exactly, as `Σdays / Σcount`. Averaging the weekly `mttr` values would be wrong whenever weekly volumes differ | No backend change. Rolling stays a frontend calculation | Decided | | 2026-09-14 | Linear y-axis, not log | Scoping to new vulnerabilities applies the relevant smoothing. A log axis stops the chart answering "are we inside our 30-day SLA", which is the question users came for | Frontend only | Decided | | 2026-09-14 | Dismissed vulnerabilities are excluded. Resolved or no longer detected only | Counting them creates a perverse incentive to dismiss rather than fix | Was not enforced in code. Tracked in https://gitlab.com/gitlab-org/gitlab/-/issues/631001. Implemented in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/256204 (the separate MR https://gitlab.com/gitlab-org/gitlab/-/merge_requests/257914 was closed and folded into it) | Decided | | 2026-09-17 | Ship the default view only in the first iteration. No "all vulnerabilities" toggle, no configurable window | Keeps scope down and gets the chart out sooner. Customizations can follow once there is feedback | Frontend and backend | Decided | | 2026-09-23 | Each weekly bucket counts only vulnerabilities detected within 90 days before that bucket's Monday | Caps the influence of ancient vulnerabilities, which is what made the chart noisy. The cap is identical for every bucket, so it can be explained in a tooltip. `N = 90` is a first-iteration hypothesis | Implemented in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/256204. The GraphQL field description in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/259541 and the docs issue https://gitlab.com/gitlab-org/gitlab/-/issues/626732 carry it. A frontend tooltip still needs to explain what "new" means | Decided, implemented | | 2026-09-23 | Defer per-week histogram buckets of days-to-remediate, and therefore median | Sizeable frontend and backend effort with a performance cost. Revisit based on customer feedback | Would be an addition to the GraphQL contract rather than a restructure, so it needs no new fields or backfill | Deferred | ## Outstanding Questions | Question | Answer | Assignee | Priority | Blocking? | |----------|--------|----------|----------|-----------| | How many weeks can a single query return? | 12, the range the chart shows. Production performance testing in https://gitlab.com/gitlab-org/gitlab/-/issues/627301: 12 weeks for `gitlab-org` takes about 0.4 s after the query was narrowed to the bucketed window | @hptrs | ~&quot;priority::2&quot; | No | ## Designs _Mockups of prototype_ {width="50%"}{width="50%"} ## Dependencies ## Functional Requirements * Visualization: a line chart for weekly MTTR, with a bar chart behind it for the number of vulns remediated that week * Buckets: weekly, fixed Monday–Sunday. The current week can be an incomplete week. * Remediated date: earliest of `resolved_at` and `undetected_since` * MTTR calculation, see below * Weeks with no remediations: show no data point, but do show a popover (MTTR is `null`, not zero) ### MTTR calculation $$ \mathrm{MTTR}(W) = \frac{\displaystyle\sum\\_{v \in R_W} \mathrm{remediation\_days}(v)}{|R_W|} $$ Where: - $`R_W`$ : the set of vulnerabilities remediated in week $`W`$ - $`|R_W|`$ : the number of vulnerabilities remediated in week $`W`$ - $`\mathrm{remediated\_at}(v) = \min\bigl(\mathrm{resolved\_at}(v),\ \mathrm{undetected\_since}(v)\bigr)`$ - $`\mathrm{remediation\_days}(v) = \mathrm{remediated\_at}(v) - \mathrm{detected\_at}(v)`$ - membership: $`v \in R_W \iff \mathrm{remediated\_at}(v)`$ falls within week $`W`$ and $`\mathrm{detected\_at}(v)`$ is on or after 90 days before the start (Monday) of $`W`$ Because of the 90-day detection window, a week's MTTR is at most about 97 days. When $`|R_W| = 0`$ (no vulnerabilities remediated that week), MTTR is `null`, not zero. ### Workflow * [x] Requires ~documentation ## Non-Functional Requirements ### Product Usage * [ ] 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))