AppSec Metrics That Matter

Why most AppSec metrics are useless

The most common AppSec metric is “total vulnerabilities found.” It is also the most misleading. A team that runs five scanners with permissive rulesets will find thousands of issues. That number goes up every time you add a tool or expand coverage. It tells you nothing about whether your applications are actually getting safer.

Metrics that count activity instead of outcomes create wrong incentives. When the scoreboard rewards finding more issues, teams optimize for detection volume. Scanners get added. Thresholds get lowered. The vulnerability backlog grows. Meanwhile, the 15 critical findings that pose real risk sit unfixed because they are buried under 3,000 informational alerts.

The metrics that matter measure risk reduction: how fast you fix dangerous vulnerabilities, how many escape to production, and whether your program covers the applications that handle sensitive data. Everything else is noise unless it directly feeds into one of those answers.

The four metrics that matter

These four metrics give you a clear, honest picture of whether your AppSec program is reducing risk. Track all four. Each one covers a different dimension of program health.

1. Mean time to remediate (MTTR)

MTTR measures how many days pass between a vulnerability being detected and its remediation. Track it separately by severity — a 30-day MTTR is acceptable for medium findings but dangerous for critical ones.

How to calculate it. For each closed vulnerability, subtract the detection date from the remediation date. Average across all closed vulnerabilities in the reporting period, grouped by severity.

Why it matters. MTTR is the single best indicator of your program’s operational effectiveness. A short MTTR means your team has working processes: findings reach the right people, developers understand the fixes, and nothing gets stuck in a triage queue for weeks.

Target benchmarks:

• Critical: under 7 days
• High: under 30 days
• Medium: under 90 days
• Low: under 180 days or accept the risk

2. Vulnerability escape rate

Escape rate measures the percentage of vulnerabilities that are first discovered in production rather than during development or testing. It tells you how effective your pre-production scanning is.

How to calculate it. Count vulnerabilities first detected in production (via DAST against production, bug bounty reports, penetration tests, or incident response). Divide by total vulnerabilities found across all phases. Multiply by 100 for a percentage.

Why it matters. Every vulnerability that reaches production is a vulnerability that your CI/CD scanners, code reviews, and pre-deployment checks missed. High escape rates mean your shift-left strategy has gaps. Fixing issues in production costs 6-10x more than catching them in the IDE or pull request.

Target benchmark: Under 15% for mature programs. Early-stage programs often see 30-50% escape rates, which should decrease as you add scanning coverage and tune rules.

3. Scan coverage

Coverage measures what percentage of your applications and repositories have automated security scanning enabled. It answers a basic question: are you even looking for problems?

How to calculate it. Count repositories with at least one active security scan (SAST or SCA) in the CI/CD pipeline. Divide by total production repositories. Report separately for SAST, SCA, and DAST since each covers different risk types.

Why it matters. An application without scanning is an application where you are flying blind. You cannot measure MTTR or escape rate for applications that are not scanned. Coverage gaps typically cluster in legacy applications and internal tools — the ones teams forget about until they get breached.

Target benchmarks:

• SAST coverage: 90%+ of production repos
• SCA coverage: 95%+ (dependency scanning is low-effort to enable)
• DAST coverage: 80%+ of internet-facing applications

4. Fix rate

Fix rate compares the number of vulnerabilities remediated per period against the number of new ones introduced. It tells you whether your backlog is growing or shrinking.

How to calculate it. Divide vulnerabilities closed this month by vulnerabilities opened this month. A fix rate above 1.0 means you are closing more than you create. Below 1.0, your backlog grows every month.

Why it matters. A growing vulnerability backlog is a slow-motion crisis. If your team introduces 100 new findings per month and closes 60, the backlog grows by 40 every month. In a year, you are sitting on 480 additional unresolved vulnerabilities. Fix rate catches this trend early.

Target benchmark: Above 1.0 consistently. Top-performing teams maintain a fix rate of 1.2-1.5, which steadily reduces the backlog over time.

Building an AppSec dashboard

A good AppSec dashboard shows the four metrics above plus enough context to take action. Keep it to a single page. If someone needs to scroll through five screens, they will not look at it.

Dashboard layout

Top row: four headline numbers. Current MTTR (critical), escape rate (trailing 90 days), scan coverage (percentage), and fix rate (trailing 30 days). Use color coding: green for on-target, yellow for trending wrong, red for outside SLA.

Middle row: trend charts. Line charts showing MTTR and fix rate over the past 6-12 months. Trends matter more than snapshots. An MTTR of 20 days is concerning if it was 10 days three months ago. An MTTR of 20 days is great if it was 45 days three months ago.

Bottom row: action items. Top 10 open critical/high findings sorted by age. Each row should show: finding title, application, owner, days open. This section turns the dashboard from a report into a task list.

Data sources

If you run an ASPM platform like Apiiro, ArmorCode, or OX Security, it provides most of this data out of the box. For teams without ASPM, DefectDojo (open source) aggregates findings from most scanner formats into a single database. You can build dashboards on top with Grafana, Metabase, or even a shared spreadsheet for small programs.

The key requirement is that all scanner findings feed into one central store. If SAST results live in SonarQube, SCA results in Snyk, and DAST results in ZAP’s UI, you cannot calculate any of these metrics without manual aggregation.

Reporting to leadership

Engineering teams and executives need different views of the same data. Sending a detailed operational report to the CISO wastes their time. Sending a high-level summary to team leads gives them nothing to act on.

Executive report (quarterly)

Executives care about risk posture, trend direction, and budget justification. Keep the quarterly report to one page:

• Risk trend. Is the organization getting safer? Show MTTR and escape rate trends over the past four quarters.
• Coverage progress. What percentage of applications are scanned? Where are the gaps?
• Top risks. The 3-5 most significant open vulnerabilities, described in business terms (“customer payment data exposed to unauthenticated access”) rather than technical jargon (“SQLi in /api/payments endpoint”).
• Program ROI. Estimated cost of vulnerabilities caught pre-production versus production remediation costs. Use the rough multiplier of 6x: a finding caught in CI/CD at $500 to fix would cost $3,000 to fix in production.

Engineering report (monthly)

Engineering leads care about operational detail. The monthly report should answer: what do I need to fix, what is getting worse, and where are we improving?

• Team-level MTTR and fix rate. Break metrics down by team so engineering managers can see how their teams compare and where bottlenecks exist.
• New findings by category. Show where vulnerabilities are being introduced: dependency issues, code flaws, configuration problems. This guides training and tooling investments.
• SLA compliance. How many critical findings are within SLA? How many are overdue? Name the applications with overdue critical findings.
• Coverage gaps. Which repos still lack scanning? Assign owners to close the gaps.

Benchmarks: what good looks like

Benchmarks vary by industry, team size, and application complexity. These numbers come from aggregated data across BSIMM, DORA, and vendor-published reports. Use them as directional guidance, not absolute targets.

If your numbers are worse than the “Early-Stage” column, focus on coverage first. You cannot improve what you do not measure.

Metrics by maturity level

Not every metric is useful at every stage. Track what is actionable given your current program maturity.

Ad-hoc (no formal program)

Start with exactly two metrics:

1. Application inventory completeness. Do you know how many applications you have, who owns them, and which are internet-facing? You cannot measure anything until you know what exists.
2. Scan coverage. Pick one scanner (Semgrep for SAST or Trivy for SCA) and deploy it to as many repos as possible. Track the coverage percentage weekly until you hit 80%.

Foundational (basic scanning in CI/CD)

Add MTTR and fix rate:

3. MTTR by severity. Start tracking how long it takes to close findings. Set initial SLAs and measure compliance.
4. Fix rate. Are you keeping up with new findings or falling behind?

Integrated (multiple tools, formal processes)

Add escape rate and team-level breakdowns:

5. Escape rate. With DAST and production monitoring in place, you can now measure how many issues slip through.
6. Team-level metrics. Break MTTR and fix rate down by team. Identify which teams need support.

Optimized (ASPM, champions program, executive reporting)

Add business-context metrics:

7. Risk-weighted findings. Not all critical CVEs are equal. Weight findings by reachability, internet exposure, and data sensitivity. ASPM platforms automate this.
8. Program ROI. Calculate the cost savings from pre-production detection versus estimated production remediation costs.
9. Developer friction score. Survey developers on how much security tooling slows them down. If friction is too high, adoption drops.

Anti-patterns: metrics that create wrong incentives

“Total vulnerabilities found” as a KPI. This rewards running more scans and lowering thresholds. Teams inflate numbers by adding tools, scanning test code, or counting the same dependency vulnerability across 50 repos. The number goes up while actual risk stays flat.

Punishing teams with the most findings. If you publish a leaderboard showing which team has the most open vulnerabilities, teams will avoid enabling scanners on their repos. You want more scanning, not less. Instead, recognize teams that improve their MTTR or achieve the highest fix rates.

False positive rate without context. A 10% false positive rate sounds bad, but if the tool finds 1,000 issues and 100 are false positives, that means 900 real findings surfaced. A 0% false positive rate might mean the tool is too conservative and missing real issues. Track false positive rate to tune scanners, not to evaluate program success.

Using CVSS alone for prioritization. CVSS scores measure theoretical severity. A CVSS 9.8 in a library used only in offline test environments is less urgent than a CVSS 7.5 in an internet-facing payment service. Metrics based purely on CVSS counts (like “zero critical findings”) push teams to fix low-risk issues while ignoring high-risk ones in context.

Counting scanner runs as “security activities.” Running a scan is not the same as doing security work. A scanner that runs nightly and produces 500 findings that nobody reads provides zero risk reduction. Measure what happens after the scan: triage rate, assignment rate, and fix rate.

Setting SLAs without enforcement. An SLA that says “fix critical findings in 7 days” means nothing if there is no process when the deadline passes. Track SLA compliance and escalate overdue findings. An SLA without teeth trains teams to ignore it.

For more on structuring your AppSec program around these metrics, see the DevSecOps hub. To evaluate platforms that automate this measurement, browse the ASPM tools category.

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 129 AppSec tools across 10 categories on AppSec Santa. Learn more.