DevSecOps Metrics: How to Measure (and Improve) Your Security Program

"You can't improve what you can't measure" is a cliché because it's true. But most security programs track the wrong things — total vulnerability count (meaningless without context), time since last pentest (a lagging indicator at best), and a compliance checkbox that has no relationship to actual risk. This guide covers the metrics that matter, how to calculate them, and how to report them to people who sign budgets.

Why Metrics Matter More Than Compliance Evidence

There's a meaningful difference between metrics that satisfy an auditor and metrics that tell you whether your security posture is actually improving. Most programs track the former almost exclusively.

Compliance-driven metrics look like: "we conducted an annual penetration test." They satisfy an auditor's checkbox. They tell you nothing about your current posture, your remediation velocity, or whether the findings from that test are actually getting fixed before the next one.

Outcome-driven metrics look like: "our mean time to remediate critical vulnerabilities dropped from 45 days to 12 days over the last two quarters." That tells you something real. It shows a trend, implies a process, and gives leadership a number they can connect to risk reduction.

The practical consequence of this distinction is sharper than it sounds. Consider two companies: Company A does an annual pentest and fixes 80% of findings before the next one. Company B runs continuous automated scanning and fixes 95% of findings within 48 hours. To an auditor reviewing the annual cadence alone, both companies look similar. In practice, Company B has a dramatically smaller window of exposure — and the metrics to prove it.

The goal of a DevSecOps metrics program is to make that difference visible and quantifiable — to yourself, to your engineering leadership, and to the people deciding whether to fund your team.

The Core DevSecOps Metrics Stack

Six metrics form the foundation of a useful security program measurement framework. For each, what follows is what it measures, how to calculate it, what good looks like, and what levers actually move it.

1. Mean Time to Remediate (MTTR) by Severity

Calculation: For all findings closed in the reporting period, compute (date_fixed - date_found) for each, then average across the group. Calculate separately for critical, high, medium, and low severity buckets — aggregated MTTR hides the issues that matter most.

Good targets: Critical findings closed within 7 days. High within 30 days. Medium within 90 days. These aren't arbitrary — they reflect how quickly exploitability in the wild typically follows public disclosure for critical severity classes.

How to improve it: Assign a named owner at the moment a finding is created, not after triage. Build fix SLAs into team OKRs so remediation velocity is a shared engineering responsibility, not solely a security team concern. Automate the re-scan trigger after a fix is deployed so you're not waiting on manual verification to close the loop.

One warning: MTTR is gameable. A team that bulk-closes unverified findings to hit a number will show excellent MTTR and a high reopen rate. Track both together.

2. Shift-Left Ratio

Calculation: vulnerabilities_caught_pre_production / total_vulnerabilities_found across the period. Count a finding as "pre-production" if it was first identified in a development, staging, or CI/CD pipeline scan — not after deployment to production.

Good target: 70% or more caught before production. Programs just getting started with shift-left practices often see this in the 20–40% range.

Why it matters: The cost difference is not linear. A SQL injection vulnerability caught by a SAST rule during a code review takes a developer fifteen minutes to fix. The same vulnerability caught post-deployment to production triggers incident response, customer communication, possible regulatory notification, and weeks of cleanup. Concrete estimates from industry data put the pre-production fix cost at roughly 1/30th of the post-production remediation cost for the same class of finding.

How to improve it: Add DAST scanning to your staging environment as part of the deployment pipeline. Run SAST in pre-commit hooks or as a CI gate. The two tools are complementary — SAST finds issues in code that hasn't been deployed yet; DAST finds issues in running application behavior that static analysis misses.

3. Vulnerability Density

Calculation: total_findings / total_kloc (thousands of lines of code). If kLOC tracking is impractical, normalize per application or per sprint instead — consistency matters more than the specific denominator.

Good range: The absolute number matters less than the trend. A codebase with 2.3 vulnerabilities per kLOC that has been at 4.1 six months ago is heading in the right direction. A codebase at 0.8 per kLOC that was at 0.5 last quarter is heading in the wrong direction, even though the absolute number looks good.

Normalize for coverage: if you scan 50% of your codebase in Q1 and 90% in Q2, density will appear to rise even if code quality improved. Adjust for coverage changes when presenting the trend.

How to improve it: Security training for developers that targets the specific vulnerability classes showing up in your findings — not generic awareness training. Secure coding standards that are enforced via code review checklists and automated linting rules, not just documented in a wiki. The most durable improvements come from eliminating entire vulnerability classes through framework choices and library upgrades, not from fixing findings one at a time.

4. Scan Coverage

Calculation: (endpoints_scanned / total_endpoints_in_inventory) × 100. This requires maintaining an inventory — which is itself a security hygiene requirement. If you don't have an endpoint inventory, that gap is the first thing to fix.

Good target: 95% or higher coverage of production endpoints. The remaining 5% should be explicitly categorized as acceptable exclusions (internal tools only, no sensitive data) rather than unknown gaps.

Why it matters: An application with 95% scan coverage might have the most critical 5% unscanned. Admin panels, internal APIs, legacy authentication endpoints, and recently deployed microservices are the most likely to fall through coverage gaps — and the most likely to be targeted. A CRIT finding you've never scanned for is indistinguishable from a CRIT finding that doesn't exist, until it's exploited.

How to improve it: Maintain an active API and endpoint inventory, ideally generated automatically from your routing configuration or OpenAPI specs. Ensure scan profiles include authenticated flows — many DAST tools require explicit session configuration to scan endpoints behind login. Treat coverage gaps as findings in themselves.

5. Vulnerability Reopen Rate

Calculation: reopened_findings / total_closed_findings in the reporting period. A finding should be counted as reopened if it returns to an open state for any reason after being closed as fixed.

Good target: Below 10%. Programs without a re-scan verification step often see 20–35% reopen rates. Programs with automated re-scan on fix tend to see this below 8%.

Why it matters: High reopen rates indicate one of two problems. Either findings are being closed without adequate verification — the fix was not actually applied or was applied incorrectly. Or the root cause is not being addressed — the vulnerability class keeps getting reintroduced because the underlying pattern (an unsafe function, a missing input validation layer, a misconfigured template) hasn't been eliminated. Both problems compound over time and inflate MTTR invisibly.

How to improve it: Require a re-scan result as evidence before a finding can be closed — not a developer attestation. Run post-mortems on vulnerability classes that reappear more than twice in a quarter; something in the codebase, the framework, or the development workflow is producing that class systematically.

6. Time to First Scan (New Services)

Calculation: Days from first deployment to first completed security scan. Track separately for production services versus internal tools — the acceptable threshold differs.

Good targets: Critical customer-facing services scanned within 1 day of first deployment. Internal tools within 7 days. New services that go unscanned for 30+ days are a meaningful exposure — they represent unknown attack surface that your security program has no visibility into.

Why it matters: This metric catches one of the most common failure modes in growing organizations: the security scanning program covers what was deployed six months ago but has no visibility into what was deployed last week. In high-velocity engineering teams, the gap between "service deployed" and "service in scan rotation" can stretch to months without deliberate process.

How to improve it: Build scan registration into the deployment pipeline as a required step — alongside environment configuration, monitoring setup, and logging. Make onboarding a new service to the scan program as frictionless as possible. If it takes manual effort from the security team, it will be deprioritized during high-velocity periods.

Leading vs. Lagging Indicators

Security programs that only report lagging indicators are flying blind. They know what happened; they have no signal about what's about to happen.

Lagging indicators measure outcomes that have already occurred: MTTR tells you how fast you fixed something after it was found. Breach count tells you how many times you failed to prevent a compromise. Annual pentest findings tell you the state of your application at the moment the pentester ran their tools. These are important — they ground the program in reality — but they can only tell you about the past.

Leading indicators measure inputs and process quality that predict future outcomes: scan coverage tells you how much of your surface area you'll detect findings on next month. Training completion rate predicts whether vulnerability density will decrease in the next quarter. Time to first scan for new services predicts whether your coverage will stay at 95% or drift below it as new services accumulate.

The practical value of leading indicators is that they let you intervene before the outcome is determined. If scan coverage is dropping from 95% to 87% over three months, you can act on that now — before the gap is exploited. If it only shows up as a finding in a post-incident review, the intervention was too late.

A mature security metrics program tracks both types and uses leading indicators to inform resource allocation decisions before the lagging indicators turn negative.

What NOT to Measure (Common Pitfalls)

The metrics that feel intuitive are often the ones that actively mislead.

Total vulnerability count. This number goes up when you increase scan coverage. More scanning means more findings — which looks worse on a dashboard even as your actual security posture improves. Reporting total finding count to leadership creates a perverse incentive to scan less. Report vulnerability density and trend instead. If you must show total counts, always contextualize with the coverage denominator.

Time since last pentest. Annual penetration tests are point-in-time snapshots. Measuring "time since last pentest" rewards waiting — the metric gets better the longer nothing happens. It tells you nothing about what was deployed in the eleven months between tests. Use it as a compliance evidence data point, not as a security posture metric.

Issues closed this sprint. This is heavily gameable. Teams learn quickly that closing 12 low-severity documentation findings looks identical to closing 3 critical vulnerabilities on a sprint metrics dashboard. If you must track closure velocity, weight by severity or track SLA compliance by severity bucket instead.

Tool uptime. Whether your scanner ran tells you nothing about what it found, whether it found the right things, or whether the findings are being acted on. Uptime is an operational metric for your security tooling team, not a security program metric for leadership.

"Zero critical vulnerabilities." This is an outcome statement, not a metric. It tells you nothing about coverage (did you actually look?), effort (how long did it take to get there?), or trajectory (is it staying at zero or bouncing?). A program with 95% scan coverage and zero criticals is very different from a program with 40% coverage and zero criticals. Report the coverage alongside the count.

Reporting Security Metrics to Leadership

The most technically rigorous security metrics program fails if it produces reports that leadership doesn't read. Here's what actually works.

One-page executive format. Three to five headline numbers with trend arrows, one call to action. Everything else goes in an appendix that exists if they ask questions. If your security report requires more than one page to communicate the key message, you haven't done the synthesis yet.

Lead with business risk, not technical findings. "2 critical vulnerabilities open for more than 7 days" lands differently than "total CVE count: 147." The first sentence connects directly to a board-level risk: an unresolved critical finding is an open door. The second number is context-free noise. Train yourself to translate every technical finding count into a business risk statement before it goes into a leadership report.

Show trends, not snapshots. A chart showing MTTR declining from 45 days to 22 days to 12 days over three quarters tells a story of a program that's working. The number "MTTR: 12 days" in isolation tells the reader nothing — is that good? bad? improving? The trend is the signal. Always show at least three data points.

Include the investment. "We reduced MTTR by 62% by adding automated DAST scanning to the staging environment. Cost: approximately €400/month." This is the format that resonates with CFOs and engineering VPs. It connects a security outcome to a resource decision and makes the ROI visible. Most security programs never make this connection explicit, which makes it impossible for finance to evaluate the value of security tooling spend.

Tie to incidents. If you had a security incident in the period, show what the relevant metric looked like before and after. If scan coverage was at 78% when the incident occurred and is now at 94%, that's a direct line from measurement to improvement to risk reduction. Post-incident metrics are some of the most persuasive data you can put in front of a board.

The one metric that matters most to a CFO. Cost per vulnerability found and fixed — internal tooling versus external penetration test. If your automated scanning program costs €400/month and finds 40 vulnerabilities, your cost-per-finding is €10. If an equivalent external pentest costs €15,000 and finds 60 vulnerabilities, your cost-per-finding is €250. The continuous program also provides 12x the coverage in a year. Make this comparison explicit. It's the clearest possible statement of the economic case for DevSecOps investment.

Building Your Metrics Dashboard

The right data lives in the right tools. Aggregating it requires knowing where to look.

Your DAST scanner is the source of truth for: finding count by severity, trend over time, MTTR for findings discovered via dynamic scanning, reopen rate, and scan coverage across endpoints. Most DAST tools export this data via API or CSV — don't rely on the built-in dashboard if your reporting cadence doesn't match the tool's update cycle.

Your SAST tool provides: vulnerability density (findings per kLOC), shift-left ratio (findings caught in CI vs deployed code), and trend data on specific vulnerability classes. SAST output is most useful when it's integrated into the code review workflow so findings are visible to developers at the point of creation, not just in a separate tool.

Your ticketing system (Jira, Linear, or equivalent) is the system of record for: SLA compliance by severity, open time distribution, assignment and ownership, and reopen history. The ticketing system is where you calculate MTTR from created to closed timestamps. If your security findings live in a separate system from your engineering tickets, you'll have gaps in MTTR data wherever the handoff happens.

Your pentest reports serve as a benchmark: compare external pentest findings against what your internal tooling found in the same period. The delta — findings the pentest found that your automated tools missed — tells you the gap in your automated coverage. Closing that gap should be an explicit roadmap item.

For a practical starting point, a shared spreadsheet with the following columns covers most of what you need before investing in a dedicated security metrics platform:

Finding ID | Severity | Application | Discovered Date | Source (DAST/SAST/Pentest/Bug Bounty) | Assigned To | Fixed Date | MTTR | Reopened?

This format makes MTTR calculation trivial (Fixed Date - Discovered Date), supports pivot-table analysis by severity and source, and can be maintained by any team without specialized tooling. Once you're tracking consistently, the patterns that emerge will tell you which dedicated metrics tooling is worth the investment.

Setting Your First Quarterly Goals

A new DevSecOps program benefits from an OKR structure that connects security outcomes to engineering work. The following template is calibrated for a program in its first year — the targets are ambitious but achievable with focused effort.

Objective: Reduce critical vulnerability exposure window

• KR1: Achieve MTTR for critical findings of 7 days or less. (Baseline: measure in the first month — do not set a target without a baseline.) Track weekly.
• KR2: Increase shift-left ratio from current baseline to 60% by end of quarter. This requires DAST deployment to staging and SAST in the CI pipeline — both of which are prerequisites, not just enablers.
• KR3: Achieve 90% scan coverage across all production endpoints. This requires completing an endpoint inventory if one doesn't exist — build that as a Week 1 deliverable.

A few notes on making these OKRs work in practice. Set the baseline before you set the target — a MTTR target of 7 days means nothing if you don't know whether your current baseline is 14 days or 60 days. Instrument before you optimize. Assign a named owner for each KR, not a team — shared ownership means no ownership when the quarter gets busy. And review the metrics monthly, not quarterly — a quarterly review cadence means you can't course-correct until it's too late.

The programs that improve fastest are the ones that make the metrics visible at the team level, not just the leadership level. When an engineering team can see their own MTTR trend on a shared dashboard, they'll optimize for it without being asked.