Skip to content
Back to blog
DevSecOps

DevSecOps Metrics That Actually Matter

Which security metrics actually correlate with reduced risk, and which commonly-tracked vanity metrics don't tell you much at all.

S
SecureScout Team· Security Engineering
July 28, 20265 min read

Security programs often measure what's easy to count, not what actually indicates risk is going down. A few metrics genuinely correlate with a healthier posture — many commonly tracked ones don't.

Metrics that tend to be vanity metrics

  • Total vulnerabilities found. This number goes up when you add a new scanner or expand coverage, independent of whether your actual risk changed. Rising counts alone say more about scanning coverage than security posture.
  • Number of security tools deployed. More tools isn't the goal — reduced risk and faster remediation are. Tool count is an input, not an outcome.
  • Training completion rate. Completing a training module says nothing about whether the behavior it covers actually changed.

Metrics that actually correlate with risk

  • Mean-time-to-remediate (MTTR), by severity. How long does a critical finding sit unfixed? This directly reflects your actual exposure window, and trending it over time shows whether remediation discipline is improving.
  • Percentage of findings caught pre-merge vs. post-deploy. This measures whether shift-left efforts are genuinely moving detection earlier, not just adding tools.
  • Recurrence rate of the same vulnerability class. If the same weakness (e.g. missing authorization checks) keeps appearing across different PRs, it signals a systemic gap — training, tooling, or architecture — rather than isolated mistakes.
  • Time-to-detect for incidents. How quickly is unusual activity or a breach actually noticed, versus discovered externally (customer report, public disclosure)?
  • Coverage of critical assets, not total assets. Are your highest-risk, most sensitive systems actually covered by scanning and monitoring, rather than measuring blanket coverage across everything equally.

Making metrics useful, not just tracked

A metric that's tracked but never reviewed or acted on isn't a metric — it's a dashboard nobody looks at. The metrics worth keeping are the ones that change a decision: slowing a release, prioritizing a fix, or funding a new control.

Avoiding metric gaming

Any metric, once it becomes a target, invites gaming. If MTTR becomes a strict KPI, findings might get silently downgraded in severity to hit the number. Pair quantitative metrics with periodic qualitative review to catch this before it becomes the dominant behavior.

devsecopsmetricssecurity-program

Frequently Asked Questions

Is "number of vulnerabilities found" a good metric?

On its own, no — it can increase simply because you added a new scanner, not because your software got less secure. It's only meaningful alongside remediation rate and severity trends over time.

What's a reasonable target for mean-time-to-remediate critical findings?

This varies by organization and risk tolerance, but many mature programs target days, not weeks, for critical/high-severity findings on internet-facing systems specifically.

Related Articles

S

SecureScout Team

Security Engineering

Learn more →