Walk into most security programs and you'll find a dashboard proudly displaying the total number of open vulnerabilities. It's the wrong number, and worse, it's a demotivating one — it goes up when you improve scanning coverage and down when you turn a scanner off, so it measures your tooling's verbosity more than your organization's risk. The purpose of DevSecOps metrics is to answer two questions honestly: are we reducing risk over time, and is security helping or hindering delivery? A raw vulnerability count answers neither. This guide covers the metrics that do — the ones that reveal whether your program is actually working and that you can defend in front of both engineers and executives.
Measure remediation speed, not finding volume
The most important operational metric is mean time to remediate (MTTR) — how long a vulnerability stays open from detection to fix, segmented by severity. It measures the thing that actually matters: your exposure window. Track it per severity tier and watch the trend, not the absolute. A program that's working shows MTTR for critical findings shrinking over time. Pair it with remediation rate (what fraction of findings in a period get fixed versus accumulate) so you can see whether you're keeping pace with inflow or falling behind. These two together tell the real story a total count never will.
Track what escapes to production
Escape rate — the proportion of security defects that reach production instead of being caught earlier — is the single best measure of whether your shift-left investment is paying off. If most of your findings are being caught in the IDE and pull request, escape rate falls and the expensive late-stage fixes become rare. If serious issues keep surfacing in production or pen tests, your earlier gates aren't catching what they should, regardless of how busy the dashboard looks. Related: defect density (security defects per unit of code or per service) lets you compare teams fairly and spot where to focus enablement.
Watch coverage and signal quality
A finding count means nothing without knowing what you actually scanned. Track scan coverage — the percentage of repositories, services, and build pipelines under active scanning — because an impressive-looking finding trend across 40% coverage is a mirage. Then track the metric that keeps your whole program credible: false-positive rate. Every false positive spends developer trust, and once trust is gone, real findings get ignored alongside the noise. A rising false-positive rate is an early warning that your gates are about to be routed around. Reachability-based prioritization exists largely to keep this number low.
Align with DORA so security speaks delivery's language
Security metrics land better with engineering leadership when they connect to the DORA metrics teams already track — deployment frequency, lead time for changes, change failure rate, and time to restore service. The framing that wins budget is showing that a well-run security program doesn't degrade these. If your security gates are adding hours to lead time or spiking change failure rate, that's a real problem the metric will expose — and fixing it (usually by improving precision and automating fixes) is how security earns its place in the pipeline rather than being seen as the tax on velocity. A software composition analysis gate that blocks only reachable, exploitable findings keeps lead-time impact near zero.
The metrics worth a dashboard
| Metric | What it tells you | Good trend |
|---|---|---|
| MTTR by severity | Exposure window | Decreasing, esp. for critical |
| Remediation rate | Keeping pace with inflow | ≥ inflow |
| Escape rate | Shift-left effectiveness | Decreasing |
| Scan coverage | Blind-spot size | Increasing toward 100% |
| False-positive rate | Signal quality / trust | Low and stable |
| Findings by stage caught | Where defects surface | Shifting earlier |
| Lead-time impact of gates | Security's drag on delivery | Near zero |
| Auto-fix / PR merge rate | Remediation friction | Increasing |
Avoid the vanity-metric traps
A few numbers look like progress and aren't. Total open vulnerabilities rewards scanning less. Number of scans run measures activity, not outcomes. Findings closed can be gamed by bulk-dismissing low-severity noise. The test for any metric: if this number improved and nothing else changed, would our actual risk be lower? If the answer is no — as it is for a raw count — it's a vanity metric. Anchor your program on outcome metrics (MTTR, escape rate) and use activity metrics (coverage, scan counts) only as supporting context, never as the headline.
Instrument at the source
Metrics assembled by hand from spreadsheets are always stale and usually wrong. The findings, their detection timestamps, the stage they were caught at, and their resolution all live in your scanning and pipeline tooling already — so the metric should be computed there, continuously, rather than reconstructed monthly. This is where an integrated platform pays off: when scanning, prioritization, and remediation share one system, MTTR and escape rate are just queries, and the dashboard reflects reality in real time.
How Safeguard Helps
Safeguard instruments the metrics that matter automatically, because it sees the full lifecycle — detection, prioritization by reachability and exploitability, and remediation. MTTR, escape rate, coverage, and false-positive rate are computed from live data across your SCA and scanning results, not assembled by hand. Because auto-fix opens tested pull requests, your remediation rate and MTTR improve mechanically rather than through heroics, and Griffin AI reduces the false-positive rate that erodes developer trust. Curious how the reporting compares to native tooling? See our Safeguard vs GitHub comparison, and check pricing for what's included at each tier.
Start measuring real risk reduction free at app.safeguard.sh/register, or read the reporting and metrics docs at docs.safeguard.sh.