Finding Lifecycle Metrics: MTTR and KPIs in Vexta

Vexta's finding lifecycle metrics answer how fast a team actually fixes what it finds, tracking MTTR (expressed as P50 median, P95, and max time-to-fix), defect density, recurrence rate, and SLA breaches for every finding. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and these numbers come straight from the finding_lifecycle data behind every scan rather than from a separate tracking system.

What KPIs does Vexta track for findings?

Four metrics. MTTR is the P50, P95, and max time-to-fix, calculated per target and severity so a critical on one system isn't averaged in with a low on another. Defect Density is a per-month finding count across a trailing 12 months, showing whether a target's overall exposure is trending up or down. Recurrence Rate is how often a specific finding type comes back after it was marked fixed, a sharper signal than a single fix confirmation. SLA Breaches is a count of findings sitting in each SLA band, act now, this sprint, or backlog, so a team can see queue health at a glance instead of scrolling every open finding.

Each of these answers a different question, and none of them substitutes for the others. MTTR tells you how long fixes take. Defect Density tells you whether the underlying rate of new problems is getting better or worse. Recurrence Rate tells you whether fixes actually hold once they ship. SLA Breaches tells you how much of the backlog is currently overdue by the team's own timelines. A target can look healthy on one of these and troubled on another, which is exactly why Vexta tracks all four instead of collapsing them into a single score.

Where does the data come from?

All four metrics compute from a single finding_lifecycle table in Vexta's local SQLite store, the same record of a finding's status changes that also feeds fix verification (reverify), which re-tests a previously found vulnerability and flips it from open to fixed or open to still_vulnerable. That shared source is what keeps the KPIs honest: MTTR only closes out once reverify has actually confirmed the fix, not the moment someone marks a ticket done.

That distinction is worth sitting with. A ticket marked resolved in an issue tracker reflects what a developer believes happened. A reverify pass that flips a finding to fixed reflects what Vexta actually observed on a re-test. Building MTTR on the second source rather than the first means the metric measures whether the vulnerability is gone, not whether someone closed a ticket.

It also means the lifecycle metrics stay grounded in the same scan history a hunter or security lead already trusts for everything else Vexta reports, the same Confidence Score, the same proof-of-exploitation status, the same fingerprinted findings. There is no second system to reconcile against and no separate export to keep synchronized with what the scanner actually found.

Vexta's public feature list does not tie these metrics to one specific plan tier; check the pricing page for what your license includes.

Why P50, P95, and max instead of a single average?

A single average time-to-fix hides the worst cases. A median (P50) shows what a typical fix looks like, a P95 shows what the slow tail looks like, and max shows the single worst outlier still sitting open. A team with a good median and a terrible P95 has a process problem for a specific class of finding, not a general one, and that calls for a different fix than a team where everything drifts slowly.

Because both are broken down per target and per severity, the comparison stays fair. A critical on a customer-facing payment flow and a low on an internal admin tool should not be judged against the same clock, and folding them into one number would hide exactly the case a security lead most needs to see: the slow-moving critical buried inside an otherwise decent average.

How SLA bands turn metrics into a queue

The SLA Breaches metric buckets findings into act_now, sprint, or backlog bands and counts how many sit in each. That turns a raw finding count into something closer to a work queue: a stack of findings that need attention this week versus a stack that can wait for planning, without a separate ticketing export to build that view.

All four metrics power the executive dashboard tiles, which is the intended audience for this data: a security lead or engineering manager who needs a status readout on remediation performance, not a hunter working a single finding at a time.

Recurrence Rate deserves a second look here, because it's the metric that catches a fix that didn't actually hold. A finding that gets marked fixed, drops off the open list, and then reappears in a later scan as the same fingerprinted bug is exactly what Recurrence Rate is built to surface. On its own, MTTR would only ever tell you the first fix was fast. Recurrence Rate is what tells you whether it stuck.

Put together, the four metrics answer a question that a raw finding count never can: is remediation actually working. A target can show a shrinking number of open findings and still be in trouble if the ones that get fixed keep coming back, or if the handful still open have been sitting past their SLA band for months. Reading MTTR, Defect Density, Recurrence Rate, and SLA Breaches side by side is what surfaces that kind of problem instead of a single, misleadingly reassuring headline count.