Security teams love dashboards, but most AppSec programs still can't answer a simple board-level question: are we actually getting more secure, or just busier? A CISO tracking "vulnerabilities found" alone can show a chart going up and to the right for years while risk stays flat — because scanning more code and more repos naturally surfaces more findings. The fix isn't fewer metrics; it's the right metrics, tied to outcomes attackers actually care about: how fast you close exploitable holes, how much of your alleged risk is real, and how much of the fix work happens without a human touching a ticket.
Teams already know how to measure DevOps success — deployment frequency, lead time, change failure rate — but most haven't applied that same rigor to security. This post breaks down the metrics and KPIs that separate a mature AppSec program from a scanner-and-spreadsheet operation, with concrete benchmarks pulled from 2024-2025 industry data, and how to instrument each one without drowning your team in noise.
What Metrics Actually Matter for Application Security?
The metrics that matter are the ones tied to exploitability and time, not raw volume. Five deserve a permanent spot on any AppSec scorecard: Mean Time to Remediate (MTTR) for critical/high findings, vulnerability density (findings per 1,000 lines of code or per service), reachability rate (percentage of findings actually callable in running code), false positive rate, and fix-without-human-touch rate (auto-remediated PRs merged). A sixth, SBOM coverage — the percentage of production services with a current, machine-readable software bill of materials — has become non-negotiable since Executive Order 14028 pushed SBOM requirements into federal procurement in 2021, and it's now a standard vendor-risk question in enterprise contracts. Teams that track only "open vulnerabilities by severity" end up optimizing for a number that scanner vendors can inflate at will simply by tuning sensitivity higher.
How Do You Calculate Mean Time to Remediate (MTTR)?
MTTR is calculated as the average time elapsed between when a vulnerability is first detected and when a verified fix is deployed to production, typically bucketed by severity. The formula is straightforward: sum the remediation times for all closed findings in a period, divide by the count. The benchmarks are less forgiving than most teams expect. The Ponemon Institute's 2023 State of Vulnerability Management report put average time-to-patch for critical vulnerabilities at 97 days across surveyed enterprises — well past the 7-day window CISA recommends for actively exploited CVEs under Binding Operational Directive 22-01. Meanwhile, Verizon's 2024 Data Breach Investigations Report found exploitation of vulnerabilities as an initial access vector nearly tripled year-over-year, jumping to 14% of breaches, largely driven by edge-device and zero-day exploitation windows measured in days, not months. If your critical MTTR is above 14 days, you're operating on a timeline attackers have already outpaced.
What Is Vulnerability Density and Why Does It Matter More Than Raw Counts?
Vulnerability density matters more than raw counts because it normalizes risk against codebase size, letting you compare a 50,000-line service to a 2-million-line monolith on equal footing. It's typically expressed as findings per 1,000 lines of code (KLOC) or findings per service/repo. A monolith with 400 open findings across 3 million lines of code (0.13 per KLOC) is in far better shape than a microservice with 40 findings in 20,000 lines (2.0 per KLOC) — even though the first number looks scarier in a headline stat. Density trends also expose whether your program is actually improving: a team that goes from 1.8 to 0.9 findings per KLOC over two quarters has halved its real risk surface, even if the absolute finding count barely moved because the codebase grew 40% in the same window.
How Do You Measure False Positive Rates in AppSec Tooling?
False positive rate is measured as the percentage of flagged findings that a human or automated triage system confirms are not exploitable or not applicable, out of total findings generated. Calculate it as (dismissed/invalid findings ÷ total findings) × 100 over a rolling 90-day window. This number is the single biggest driver of AppSec team burnout: a 2024 GitLab Global DevSecOps survey found that 42% of security professionals said their teams don't have enough time to fix all critical vulnerabilities identified, and a large share of that lost time goes to triaging noise. Traditional SCA tools that flag every vulnerable dependency — regardless of whether the vulnerable function is ever called — routinely produce false-positive-equivalent rates (functionally unreachable findings triaged as if they were real) north of 70-85% in typical enterprise codebases, based on reachability studies published by multiple application security vendors since 2022. Cutting this number is usually higher-leverage than buying another scanner.
What Percentage of Vulnerabilities in a Typical Codebase Are Actually Exploitable?
The industry-wide answer, consistently, is a small minority — typically cited in the 10-20% range across reachability-analysis research from 2022 through 2024. The rest are present in a dependency tree but sit in code paths that are never invoked at runtime: dead functions, unused optional modules, or dev-only tooling that ships in the same package. This is why "number of CVEs in your SBOM" is a poor KPI on its own — it's a superset that includes both real and theoretical risk with no way to tell them apart from the SBOM alone. Programs that add reachability data to their vulnerability metrics typically cut their "must-fix-now" queue by 80% or more, because most of the SBOM's CVE count was never callable in the first place.
How Should You Benchmark Your AppSec Program Against Industry Standards?
Benchmark against published percentile data from your industry vertical and company size band, not against an arbitrary internal target set three years ago. The 2024 DORA-adjacent security metrics work from groups like the Cloud Security Alliance and vendor-published benchmark reports (Snyk, Veracode's State of Software Security series, now in its 14th year as of the 2024 edition) consistently segment MTTR, fix rate, and open-critical-count by company size and sector — financial services and healthcare organizations report materially longer critical MTTR (often 60+ days) than SaaS companies under regulatory pressure to move faster. It's the same instinct behind how to measure DevOps success with DORA's four keys (deployment frequency, lead time, change failure rate, and MTTR) — AppSec just needs its own version of that scorecard, tracked with equal discipline. Track your percentile position quarter over quarter rather than chasing an absolute "zero open criticals" target that's unrealistic for any org shipping code weekly. A realistic 2025 target band for a mid-size SaaS company: critical MTTR under 7 days, high MTTR under 30 days, reachability-confirmed exploitable findings under 25 open at any time, and SBOM coverage above 95% of production services.
How Safeguard Helps
Safeguard turns these metrics from a manual reporting exercise into a live, defensible scorecard. Reachability analysis automatically separates the 10-20% of findings that are truly exploitable from the noise sitting in dead code paths, so your MTTR and false-positive-rate numbers reflect real risk instead of raw scanner output. Griffin AI, Safeguard's remediation engine, triages new findings against your actual call graphs and prioritizes what to fix first, then opens auto-fix PRs for the fixable subset — driving up your fix-without-human-touch rate without adding headcount. Native SBOM generation and ingest (supporting CycloneDX and SPDX) keeps your SBOM-coverage KPI current across every repo automatically, satisfying both the compliance box and the audit trail your board actually wants to see. Teams running Safeguard typically report their critical MTTR and reachable-vulnerability backlog moving in the same conversation, for the first time.