Add true CVE-level MTTR history for vulnerabilities

[ybelMekk]

Problem Statement

AppSec wants the Mean Time To Fix history to reflect real remediation speed for vulnerabilities, not a severity-only approximation. Today the trend can rise or stay noisy even when many criticals are closed, because the metric needs to represent how long each unique CVE stayed open on each app/resource before it was fixed.

Solution

Update the existing MTTR history so it measures each unique CVE per workload/resource, grouped by severity and time range, and only counts closed fixes. The history should use the first observed registration date as the start point, the close date as the end point, and a closed-state snapshot as the basis for each datapoint. Open findings, false positives, duplicate observations, and risk-accepted closures should not inflate the MTTR trend.

User Stories

1. As an AppSec analyst, I want to see MTTR by severity over time for real CVE fixes, so that I can trust the remediation trend.
2. As an AppSec analyst, I want each workload/resource to contribute one fix unit per unique CVE, so that duplicate scanner noise does not distort the metric.
3. As an AppSec analyst, I want the chart to count only closed findings, so that open backlog does not blur the remediation history.
4. As an AppSec analyst, I want severity to be evaluated from the time the CVE was first observed, so that historical points stay stable when classifications change later.
5. As an AppSec analyst, I want the time range selector to filter by close date, so that the graph shows remediation delivered inside the selected interval.
6. As an AppSec analyst, I want the chart to ignore false positives, so that the metric reflects actual work.
7. As an AppSec analyst, I want risk-accepted findings to be visible separately from fixed findings, so that the MTTR remains honest about remediation work.
8. As an AppSec analyst, I want a separate line for each severity, so that I can compare critical, high, medium, and low remediation speed.
9. As an AppSec analyst, I want the main value to remain a mean, so that the metric still matches the name Mean Time To Fix.
10. As an AppSec analyst, I want the history to show when fixes were actually closed, so that I can review delivery trends over time.
11. As a platform user, I want the existing vulnerability API surface to keep the same filter shape, so that the chart can still be scoped by cluster, namespace, workload type, and workload.
12. As a platform user, I want the MTTR trend to remain available through the current vulnerabilities service, so that existing clients do not need a new integration point.
13. As an AppSec analyst, I want the trend to be computed per workload/resource, so that the metric reflects team-owned remediation rather than a global average across unrelated assets.
14. As an AppSec analyst, I want the metric to be based on unique CVE identity rather than a severity-only bucket, so that the result is closer to real vulnerability lifetime.
15. As an AppSec analyst, I want the metric to remain comparable across time ranges, so that month-over-month remediation progress can be tracked.

Implementation Decisions

• Reuse the existing vulnerabilities gRPC seam for MTTR history rather than introducing a second reporting API.
• Keep the current filter model for cluster, namespace, workload type, workload, and since/since_type.
• Change the underlying lifetime aggregation so the unit of measure is a unique CVE per workload/resource instead of a severity-only lifetime bucket.
• Treat a finding as fixed only when the close event is recorded; reopened findings should start a new lifetime.
• Exclude false positives, duplicate observations, and risk-accepted findings from the MTTR average.
• Keep severity-specific trend lines, but source severity from the first observation of the CVE.
• Use close date for time-range filtering and chart bucketing.
• Preserve the mean as the primary value while keeping supporting counts and boundary timestamps for the trend points.

Testing Decisions

• Add behavior-level tests around the MTTR trend response rather than checking implementation details of the SQL aggregation.
• Test that one unique CVE per workload/resource contributes one fixed record to the trend.
• Test that open findings do not affect the MTTR history.
• Test that duplicates and false positives are excluded.
• Test that severity filters, workload filters, and since filters still work on the existing API seam.
• Prior art: the current server tests already exercise MTTR trend responses and workload-level fix stats through the vulnerabilities gRPC client.

Out of Scope

• New dashboard visuals or chart components.
• Changing unrelated vulnerability summary or suppression flows.
• Reworking the overall vulnerability model beyond what is needed for MTTR history.
• Adding a second reporting surface for the same metric.

Further Notes

The current implementation already exposes MTTR history through the vulnerabilities service, so the main product change is in how the history is defined and aggregated. This spec is intentionally strict so AppSec gets a remediation metric that matches how the team thinks about real fixes.