What metrics actually show whether an AppSec program is working?
Four metrics, measured consistently over quarters, will tell you more than any dashboard with fifty widgets: mean time to remediate critical vulnerabilities, coverage of your production estate by your core controls, escape rate from pre-production to production, and risk-adjusted backlog age. Everything else is a supporting indicator or noise.
I have audited AppSec programs that reported 98 percent scan coverage and missed the fact that 40 percent of their production services were never actually scanned, because the denominator was "services in our scanner" rather than "services in production." The right metric set starts with denominators you can defend.
Why does mean time to remediate still matter in 2026?
MTTR remains the single best operational metric because it captures the end-to-end health of detection, triage, ownership, and engineering capacity in one number. But the 2026 version of MTTR must be stratified or it misleads.
Track three tiers separately:
- MTTR for critical CVEs in direct dependencies of production services. This is your core number. Target under 7 days for severity-9-and-above findings with known exploitation.
- MTTR for transitive dependency findings. These take longer because they often require upstream waiting. A reasonable target is 30 days, but you must track whether the delay is because of upstream unavailability or your own team's inaction.
- MTTR for findings in first-party code from SAST and DAST. This is typically the laggard. Programs that confuse this number with the dependency number will convince themselves their remediation is broken when their triage is actually broken.
The formula that matters is time from "finding exists and has an owner" to "finding is remediated or accepted with documented justification." Do not measure from the CVE publication date; that includes detection lag, which is a separate metric.
How should you measure coverage in a way that cannot be gamed?
Coverage is the metric most frequently inflated. To make it credible, define the denominator outside the security team's control. The denominator should come from the platform or infrastructure team's registry of production services, not from the scanner's list of what it has seen.
Compute coverage as:
coverage = (services in platform registry that have a successful scan in last 7 days)
/ (services in platform registry marked as production)
Report coverage weekly and track its volatility. A stable 85 percent is healthier than a number that oscillates between 70 and 95 percent, because oscillation usually signals broken integrations rather than real progress.
For dependency scanning, extend coverage to a second dimension: percentage of critical ecosystems monitored. If you scan Java and JavaScript but your mobile team ships Swift packages with no oversight, your reported coverage lies by omission.
What is escape rate and why is it the best lagging indicator?
Escape rate measures the percentage of findings that reach production without being caught by any pre-production control. It is calculated as:
escape rate = (critical findings first detected in production in period)
/ (total critical findings detected in period)
It is the honest version of the question "are our gates working." A program with a 3 percent escape rate is catching its own mistakes. A program with a 40 percent escape rate is learning about vulnerabilities the same way attackers do, through exposure.
Escape rate must be reviewed with engineering, not just security. When it rises, the root cause is usually a process change such as a new build system, a new team that was not onboarded, or a pre-production gate that started failing silently. Security cannot fix these alone.
The 2026 complication is generative tooling. Code produced by AI assistants often lands in pre-production pipelines that were designed for human-authored change volume. If your escape rate jumped in the last year, ask whether your gates are sized for current throughput.
How do you track risk-adjusted backlog age?
Raw backlog age is misleading. A 400-day-old finding on an internal admin tool is not the same as a 30-day-old finding on your customer-facing API. Risk-adjusted backlog age weights each finding by a risk score and reports the weighted average age.
A pragmatic formula:
risk-adjusted age = sum(age_i * risk_weight_i) / sum(risk_weight_i)
Risk weight can be as simple as a multiplier: 1x for low-risk internal services, 3x for production services, 10x for internet-facing production services that handle regulated data. The exact weights matter less than consistency over time.
The metric becomes powerful when you track its trajectory. A program that is net adding faster than net resolving will see this number grow even if raw counts look stable. That growth is the early warning that capacity is insufficient.
What reporting cadence and audience mix actually works?
Different metrics belong in different rooms. Overloading the executive readout with operational detail is the surest way to lose executive attention.
- Weekly, engineering leadership. Coverage, MTTR by tier, top-10 aging findings with owner names. This is the working-level review.
- Monthly, security leadership plus engineering directors. Escape rate, risk-adjusted backlog age, and trend lines on the weekly metrics.
- Quarterly, executive and board. Three or four numbers, no more: escape rate, percentage of production estate under policy, one incident postmortem with named lessons, one named gap the program will close next quarter.
Anti-pattern to avoid: monthly 40-page reports that nobody reads. A two-page executive summary backed by a detailed appendix is read; a 40-page document is filed.
What metrics should you stop tracking?
Retire metrics that no longer drive decisions. Scan counts, rule coverage percentages, and "vulnerabilities found" numbers belong to an earlier era of AppSec and actively harm your credibility when reported to executives who now know better.
Also retire any metric that cannot survive the "so what" test. If you report a number and the room's response is to ask what action it implies, and you cannot answer, the metric is noise.
Finally, be cautious with any metric that your vendor provides by default. Vendor-native metrics are optimized to make their product look effective, which is not the same as making your program effective. Build your metrics on top of their data, not on top of their dashboards.
How Safeguard.sh Helps
Safeguard.sh produces the coverage, MTTR, and escape-rate metrics described above from first-party production data rather than scanner logs, which prevents the denominator inflation that undermines most AppSec reporting. The platform stratifies MTTR by dependency tier and routes aging findings to their owners automatically, turning the risk-adjusted backlog metric into a live queue instead of a quarterly spreadsheet exercise. Leaders use Safeguard.sh to replace hand-built reporting pipelines and present defensible numbers to their executives without weeks of prep.