Measure each layer on its own job. For SCA, track coverage and scan freshness. For ASPM, track how many findings are deduplicated, owned and routed. For the vulnerability management process, track age of open findings and time to fix. Avoid raw finding counts as a headline.
Why layered metrics
One number rarely tells you which part is failing. If open findings rise, is detection better, is routing broken, or are fixes slow? Separating metrics by layer points to the cause.
SCA metrics: is detection complete and current?
| Metric | What it tells you |
|---|---|
| Share of applications with a recent scan | Coverage |
| Median age of the last scan on deployed code | Freshness |
| Share of scans using lockfiles or built artifacts | Accuracy of inputs |
| Share of findings with exact version and path | Data quality |
Coverage comes first. A great dashboard over half your applications is misleading.
ASPM metrics: is the queue useful?
| Metric | What it tells you |
|---|---|
| Duplicate rate removed | Value of correlation |
| Share of findings with a named owner | Routing health |
| Share of tickets created above threshold only | Noise control |
| Share of findings with exploit and reachability context | Prioritization quality |
If owner coverage is low, fix the application to team mapping before anything else.
VM process metrics: are things getting fixed?
| Metric | What it tells you |
|---|---|
| Time to fix by priority tier | Speed where it matters |
| Age of open findings, bucketed | Backlog health |
| Share fixed within deadline | Policy adherence |
| Open exceptions and how many expire this month | Risk acceptance hygiene |
| Inflow versus closure rate | Whether you are catching up |
The CISA Known Exploited Vulnerabilities catalog attaches a due date to every entry, which makes a good model: a deadline on each item and a count of how many met it.
Pitfalls
- Counting findings. More findings can mean better detection or worse noise. It does not tell you which.
- Mean instead of median. One ancient finding skews a mean. Use the median and show the long tail separately.
- Measuring tools, not outcomes. Scans run is an activity, time to fix is an outcome.
- Counting closure by ticket status. Count closure by rescan confirmation.
- Comparing teams without context. A team with an older codebase has a harder baseline.
How many metrics
Pick two or three per layer, report monthly, and annotate changes such as a new scanner or a changed policy so shifts make sense. NIST's patch management publication notes that business owners and technology managers often disagree about the value of patching, and trend lines on a few agreed metrics settle more arguments than opinions do.
A starter set of five
- Share of applications scanned in the last seven days.
- Share of findings with a named owner.
- Median time to fix for KEV listed and reachable findings.
- Count of findings older than your deadline.
- Open exceptions expiring in 30 days.
A worked example
A team reviews its first quarter. The numbers are invented for illustration.
| Metric | Month 1 | Month 3 |
|---|---|---|
| Share of applications scanned in last 7 days | 55 percent | 92 percent |
| Share of findings with a named owner | 40 percent | 85 percent |
| Median time to fix, KEV listed or reachable | 21 days | 9 days |
| Findings older than deadline | 130 | 48 |
| Open exceptions expiring in 30 days | 3 | 7 |
The story is clear. Coverage and ownership improved first, which made fixing faster. The rising count of expiring exceptions is a signal for the next review, not a failure.
Compare that with a report that says only "open findings: 900 then 840." It hides everything that matters.
Step by step: introduce metrics without drowning
- Pick five metrics from the starter set above.
- Define each precisely. For example, scanned means a successful scan, not an attempted one.
- Find the data source for each, and write it down.
- Snapshot a baseline this month, before changing anything.
- Review monthly with the people who can act on the numbers.
- Annotate changes such as a new scanner or a new policy so shifts are explained.
- Retire a metric if nobody acts on it.
Reading metric movements
| Movement | Possible reading | Check |
|---|---|---|
| Open findings rise, coverage rises | Better detection | Is time to fix steady? |
| Open findings rise, coverage steady | Backlog growing | Inflow versus closure |
| Time to fix falls, exceptions rise | Teams avoiding work | Review exception reasons |
| Owner coverage falls | New applications unassigned | Update the catalog |
Metrics that mislead
- Total findings alone. Detection changes can move it either way.
- Mean time to fix. A few ancient items distort it, so use the median plus a count of the oldest.
- Scans run. An activity count, not an outcome.
- Tickets closed. Count rescans that confirm the fix instead.
Who should see what
Developers want their own team's queue and age. Security leads want coverage, exceptions and time to fix by tier. Executives want a few trend lines and a sentence on what changed. Build views for each rather than one dashboard for all.
Try it yourself
Watch how a stored inventory is rechecked and which changes trigger an alert.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard provides dependency scanning, reachability analysis and policies, plus compliance and evidence automation that helps keep records of these measures. A free scan is at gold.safeguard.sh/scan.
Quick check
What is a good first metric for SCA?
Coverage: the share of applications with a recent scan. Without it, other numbers describe only part of your estate.
Should I report total open findings?
Show it, but pair it with age and time to fix. The raw total hides whether the risk is rising or falling.
How soon will metrics show improvement?
Coverage and ownership usually move within the first month or two. Time to fix often follows a quarter later, once routing works.
Sources
Last reviewed: 19 October 2026.
