Shift-left security is working if security problems are found earlier, fixed faster, and fewer reach production, without making delivery slower. Measure the share of issues caught before merge, how long fixes take, and whether delivery metrics hold steady. A rising count of scans or findings tells you nothing by itself.
What shift-left claims
The idea behind shift-left is simple: detect design flaws and vulnerabilities as early and as cheaply as possible, and keep doing so continuously. The OWASP DevSecOps Guideline states that aim directly, and adds that security controls should not slow delivery. So there are two sides to test: security outcomes get better, and delivery does not get worse.
Measures that fit the claim
| Measure | How to calculate | What a good trend looks like |
|---|---|---|
| Pre-merge catch share | Findings first seen in a pull request divided by all findings of the same class, including those first seen later | Rising |
| Escape count | Issues found in production or by outsiders that a pre-merge check covers | Falling |
| Time to fix for new findings | Median days from first seen to fixed | Falling or stable |
| Override rate | Gate bypasses divided by gated pull requests | Low and stable |
| Rework from security | Pull requests reopened for security reasons | Stable or falling |
Pick a class of issue, for example leaked secrets or vulnerable dependencies, and track it end to end. Averaging across everything hides the picture.
Guard against delivery damage
DORA defines five software delivery measures: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. If you add security checks and lead time jumps while the fail rate does not improve, you are paying a cost without gaining a benefit. DORA also warns against setting these as goals, since mandated targets invite gaming, and against ranking teams. Use them per service, as a conversation starter.
Watch the human side
Numbers can look good while developers resent the tooling. Ask a few direct questions every quarter:
- Do findings usually look right?
- Do you understand what to do about them?
- Has the check ever blocked you for no good reason?
- Do you ask security earlier than before?
Qualitative answers often explain a metric movement before the metric does.
Common traps
Counting findings. More findings can mean better detection or a worse codebase. Without context you cannot tell which.
Counting scans. Coverage is a prerequisite, not an outcome.
Averaging over teams. A good average can hide one team with no coverage.
Ignoring the baseline. Record the starting point before the rollout. Without it, every improvement is a guess.
A simple review rhythm
Each quarter, show one page: the three measures above for the classes you care about, delivery metrics beside them, and two comments from developers. Decide one change: tighten a gate, loosen a noisy rule or add coverage.
Quick check
Is a falling number of vulnerabilities proof that shift-left works?
Not alone. It could reflect fewer scans, narrower rules or less code. Pair it with coverage and with escapes to production.
How long before the trend shows?
Expect at least a few release cycles. Fix time may move first, escapes later.
Safeguard's SBOM and dependency scanning give a consistent baseline to measure against, and you can start with a free scan.
Sources
Last reviewed: 19 October 2026.
