Which ASPM metrics show that application risk is really going down?

The ASPM metrics worth tracking measure exposure and response, not finding counts. Use time to fix by severity and exploitability, age of known-exploited vulnerabilities, coverage of repositories and pipelines, and the share of findings that are reachable. Each metric should lead to a decision, or drop it.

Why are raw finding counts misleading?

A number of findings goes up when you add a scanner and down when you suppress a rule. Neither means your risk changed. Counts also treat a flaw in unused code like one on an internet-facing login page. OWASP SAMM, the Software Assurance Maturity Model, makes the same case from the maturity side: it aims to give you an effective and measurable way to analyze and improve your software security posture, which means measuring practices and outcomes, not only alerts.

Which signals deserve a metric?

Start with two public signals about exploitation. CISA's Known Exploited Vulnerabilities catalog is the authoritative list of vulnerabilities seen exploited in the wild, and CISA says to use it as an input to prioritization. FIRST's Exploit Prediction Scoring System publishes a daily probability between 0 and 1 that a CVE will be exploited in the next 30 days. These do not replace severity scores. They add the question of whether anyone is actually attacking it.

Then add your own context: is the vulnerable code reachable from your application, is the service exposed to the internet, and does it handle sensitive data?

What is a good starter set?

1. Time to remediate, split by priority class. Measure from detection to fixed in production, using the median and the slowest decile. Averages hide the stuck tickets.
2. Age of open known-exploited vulnerabilities in your own estate. The target is a short number and a short list. Anything older than your own policy should be listed by name.
3. Share of findings that are reachable or exposed, and how that share moves over time.
4. Coverage: percent of repositories, services and pipelines that are scanned at all, and how fresh the last scan is. A great result on 40 percent of your code says little about the rest.
5. Gate effectiveness: how often a policy gate stopped a new high-risk issue before merge, versus how often it was bypassed.
6. Recurrence: how often the same class of flaw returns, which shows whether root causes are being fixed.
7. Ownership: percent of findings with a named owning team. A finding nobody owns will not be fixed.

Which metrics should you avoid?

Be careful with "number of vulnerabilities closed," which rewards closing easy ones, and with any score that cannot be explained to the engineer who has to act on it. Also avoid comparing teams on raw counts, since a team with more code and more scanning will always look worse.

A constructed example

A company reports 4,000 open findings, down from 5,000, and calls it progress. A closer look shows the drop came from archiving two old repositories. Switching to the starter set tells a different story: coverage is 62 percent, the median fix time for exploited issues is 41 days against a policy of 14, and eleven known-exploited items are open, six of them unowned. Now there are three actions: scan the missing repositories, assign owners, and fix the six.

How to check or apply this

1. For each metric, write the decision it informs, such as adding scan coverage or staffing a fix sprint.
2. Define each term in writing, including when the clock starts and stops.
3. Pull exploitation signals from the KEV catalog and EPSS rather than guessing.
4. Add reachability and exposure context so you can sort by what is actually reachable.
5. Report medians and worst cases together.
6. Review the set quarterly, and retire metrics nobody acts on.

Safeguard provides reachability analysis and compliance automation that feed several of these measures, and the exploitability check in the demo below shows the sorting step.

Open the full demo

Quick check

Sources

• OWASP SAMM
• CISA Known Exploited Vulnerabilities Catalog
• FIRST, Exploit Prediction Scoring System
• NIST SP 800-218, Secure Software Development Framework

Last reviewed: 18 October 2026.