Safeguard
Research•

CTEM metrics that matter, and the ones that mislead

Which metrics show whether continuous threat exposure management reduces risk, and which ones reward busywork, such as findings closed or scan counts.

Safeguard Security Team
5 min read

CTEM metrics that matter measure exposure that is important, reachable and old: how long exploited flaws stay open on critical assets, how many important assets have owners, and how much of the top ranked list was validated and fixed. Metrics that mislead count activity, such as total findings or tickets closed.

What should a CTEM metric tell you?

NIST SP 800-137 on continuous monitoring describes the aim as visibility into organizational assets, awareness of threats and vulnerabilities, and visibility into the effectiveness of deployed controls. Use that as a filter. A CTEM metric should show one of these. If it only shows effort, it belongs in a team dashboard, not a leadership report.

CTEM is a cycle of scope, discovery, prioritisation, validation and mobilisation, so it helps to attach one or two metrics to each stage.

Metrics that matter, by stage

Scope. Share of critical assets in scope. Report the denominator: how sure are you which assets are critical?

Discovery. Share of in scope assets with a named owner, and the median age of unowned assets. CISA's BOD 23-01 states that continuous and comprehensive asset visibility is a precondition for managing cyber risk, and ownership is part of making that visibility useful.

Prioritisation. Age of the oldest flaw with evidence of exploitation on exposed, important assets. CISA's Known Exploited Vulnerabilities catalog is a public source of exploitation evidence. A single number, in days, that leaders can picture.

Validation. Share of the top ranked findings that were validated as reachable and exploitable, and the share that turned out not to be. The second figure tells you how good your ranking is.

Mobilisation. Time from validated critical exposure to fix, against a target agreed with engineering. Report the share fixed within target and the list of exceptions with sign off.

Cycle health. Cycles completed on schedule on the chosen scope.

Metrics that mislead

Total findings. Grows when you add scanners and shrinks when you disable them. It measures tooling, not risk.

Findings closed. Rewards fixing many trivial items. A team can close thousands of low value findings while an exploited flaw sits open.

Average CVSS or severity score. An average hides the tail. One critical exposure matters more than a thousand lows, and an average dilutes it.

Percent of assets scanned. If the asset list is incomplete, this is 100 percent of the wrong number. Pair it with discovery gap measures.

Mean time to remediate, across everything. Mixes fast easy fixes with slow critical ones. Split by importance and exposure.

EPSS or other scores shown as risk. FIRST describes EPSS as a model estimating the probability that a published CVE will be exploited in the wild in the next 30 days. That is a useful input to ranking. It is not a measure of your risk, because it knows nothing about your assets.

Pair metrics so they cannot be gamed

Targets get gamed. A target on time to fix leads to easy items being fixed first. Pair speed with the age of the oldest important item. A target on closed findings leads to ticket splitting. Pair with validated exposure removed.

How often should you report?

Report headline numbers each quarter, to match the cycle, and keep an operational view weekly for the team doing the work. Reporting more often than the cycle runs only produces noise, and leaders start reacting to week to week wobble that means nothing.

What should the board see?

Four numbers, each with a trend line: age of the oldest exploited flaw on important exposed assets, share of important assets with owners, share of validated critical exposure fixed within target, and cycles completed. Anything more tends to bury the message.

What about software supply chain data?

Add one: the share of important applications with a known component inventory and a reachability check on critical dependency findings. Without it, the exposure number ignores everything inside your code.

What to do

  1. Pick the four headline metrics and write their definitions.
  2. Record each denominator and how you know it.
  3. Split remediation time by asset importance and exposure.
  4. Add a validation sample to every cycle and report the rate of false alarms.
  5. Retire total findings and findings closed from leadership reports.
  6. Agree targets and exceptions with engineering leaders in advance.

Safeguard focuses on the application and software supply chain side, with reachability analysis for dependencies, and does not replace a CTEM platform.

Quick check

What is the single most useful CTEM number?

The age, in days, of the oldest flaw with evidence of exploitation on an important, exposed asset. It is easy to understand and hard to flatter.

Why is findings closed a poor metric?

It rewards closing many trivial items and says nothing about whether the dangerous ones were fixed. Pair any closure count with the age of the oldest important item.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.