Measuring an AppSec Program: Metrics That Matter
Ask most application security teams how their program is doing and you will hear a number of findings. It is the easiest thing to count and among the least useful things to know, because it measures how loud your scanners are, not how safe your software is. A program can double its finding count by turning up sensitivity and be no more secure for it. Measuring an AppSec program well means tracking outcomes — risk reduced, time to fix, trust retained — not the volume of alarms.
The purpose of metrics is to answer three questions honestly: is risk going down, is the program getting faster, and are the people it depends on still using it? Vanity metrics answer none of these. A raw count of open findings conflates a critical reachable flaw with a low-severity note in dead code, rewards noisy tools, and tells a CISO nothing they can act on.
Metrics that track outcomes
- Mean time to remediate, by severity. How long from discovery to verified fix? Falling MTTR on high-severity findings is the clearest sign the program is working.
- SLA compliance. What fraction of findings are resolved within their risk-based deadline? This measures follow-through, not just detection.
- Escape rate. How many vulnerabilities reach production and are caught later — in pen tests, bug bounties, or incidents — that earlier stages should have stopped? This grades the whole pipeline.
- Vulnerability age and backlog trend. Is the backlog aging or being worked down? A growing pile of old findings is risk accreting quietly.
- Reopen rate. How often do fixed findings return? High reopen rates mean fixes are treating symptoms.
Coverage and precision, honestly
Two health metrics keep the outcome numbers trustworthy. Coverage — what fraction of your repositories, services, and languages are actually scanned — stops a great MTTR on 30% of the estate from masquerading as program-wide success. Precision — the share of findings that are real — is the leading indicator of whether developers will keep engaging; a falling precision predicts an adoption collapse long before the outcome metrics move.
Adoption is a security metric
A program lives or dies on whether developers use it, so measure that directly: how many findings are triaged versus ignored, how many suggested fixes are accepted, how many teams have the gates enabled rather than bypassed. A rising suppression rate or falling triage rate is an early warning that the tooling has become noise. These are not soft metrics — an unused control provides no security, however good its detections.
Outcome: high-sev MTTR 6 days, SLA 94%, escape rate down, coverage 88%
Report risk, not activity
When the program's numbers reach leadership, frame them as risk over time, not effort expended. “Critical exposure in internet-facing services fell by half, and median time to fix dropped from three weeks to six days” is a sentence a board can act on. “We triaged 12,000 findings” is a sentence that invites the question of why there were 12,000. Tie every metric back to the risk it represents.
Good metrics are themselves a form of discovery — they reveal where the program is blind, slow, or losing trust before those gaps become incidents. Measure the outcomes and the honest health signals, and you will always know which part of your estate you cannot yet defend, because you will have measured exactly where you have not looked.
- Look at what your program reports: a raw finding count (a measure of scanner volume) or outcomes like high-severity MTTR, escape rate, and coverage.
- Check your scan coverage — a great MTTR on 30% of the estate is not program-wide success.
Reading your own dashboard is a start; establishing the outcome metrics and the coverage baseline behind them is what our assessment runs for you.