Notifications
Clear all
Topic starter
02/08/2026 12:31 pm
TL;DR: Mean time to resolve can help AppSec teams measure improvement and prioritisation, but Veracode’s analysis shows it only works when findings are grouped by policy context, scan scope, and remediation state. Averaging across mismatched sandboxes or business units can produce misleading results that obscure real security debt. The real control is not the metric itself, but the governance boundary around it.
NHIMG editorial — based on content published by Veracode: Using Mean Time to Resolve effectively across static and SCA findings
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
Questions worth separating out
Q: How should security teams use MTTR without distorting remediation priorities?
A: Use MTTR only within a defined policy boundary and pair it with finding severity or policy impact.
Q: Why does MTTR become misleading across different application scopes?
A: Because the same finding can have different meanings in different sandboxes, release stages, or business units.
Q: What do security teams get wrong about average remediation time?
A: They often assume every average is comparable.
Practitioner guidance
- Define the MTTR boundary before using the metric Set the exact policy, application, sandbox, or release scope that qualifies a finding as open or closed.
- Separate finding classes in reporting Report static analysis and software composition analysis MTTR separately, because their lifecycle logic is different.
- Weight roll-ups by closed finding volume When aggregating across teams or business units, sum all time-to-resolve values first and divide by the total number of closed findings.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- The exact MTTR formulas used for static analysis and software composition analysis findings.
- The sandbox and policy-context rules that determine when a finding is considered resolved.
- The worked examples showing why averaging averages produces misleading business-unit comparisons.
- The distinction between resolved, mitigated, and still-open findings in Veracode Analytics.
👉 Read Veracode's analysis of MTTR across static and SCA findings →
Mean time to resolve in AppSec: where policy context changes the metric?
Explore further
02/08/2026 1:29 pm
Policy-bound metrics are the difference between governance and theatre. Veracode’s analysis shows that MTTR only has operational value when teams agree on the policy context that defines a finding as open, closed, or mitigated. Without that boundary, the number becomes a blend of scan timing, sandbox state, and remediation status rather than a measure of control performance. For AppSec leaders, the lesson is that measurement design is part of governance, not an afterthought.
A question worth separating out:
Q: When should organisations treat MTTR as a governance metric rather than a performance metric?
A: When the objective is to determine whether policy-defined findings are being fixed faster than general debt. That is a governance use case because it shows whether the policy is steering work. If the number is being used to rank teams without context, it stops being a control measure and becomes a scoreboard.
👉 Read our full editorial: Mean time to resolve is only useful when policy context is defined
