DORA's guide lists six ways teams misuse delivery metrics: setting them as goals, relying on one metric, comparing unlike applications, siloed ownership, competing, and measuring instead of improving. Each has a direct security twin, and knowing them in advance keeps your security dashboard honest.
The six, side by side
| DORA's warning | Security version |
|---|---|
| Setting metrics as goals invites gaming | A target of "zero criticals" leads to reclassifying or suppressing findings |
| One metric to rule them all | Judging a program by open vulnerability count alone |
| Comparing disparate applications | Ranking a legacy batch job against a new API on fix time |
| Siloed ownership causes finger-pointing | Security owns the number, engineering owns the code, nobody owns the fix |
| Competing between teams | A public leaderboard of teams by findings |
| Measurement over improvement | Months building a dashboard before fixing anything |
1. Metrics as goals
DORA ties this to Goodhart's law, where a measure that becomes a target stops being a good measure. If a team is rewarded for closing findings, you will see findings closed as won't fix. Counter it by pairing the target with a check, such as the reopen rate or a sample audit of closed items.
2. One metric
Open vulnerability count rises when you start scanning more, which is good news that looks like bad news. Use several measures with some tension between them: time to remediate, scan coverage, share of findings that are exploitable, and exception count.
3. Unlike comparisons
A service shipping daily and one shipping quarterly cannot share a fix-time goal. Compare each against its own history. Our post on DORA metrics being per service covers the grain.
4. Siloed ownership
If the security team owns the dashboard and engineers own the repos, the number belongs to neither. Name one accountable owner per service for both delivery and security metrics, and review them in the same meeting.
5. Competition
Security leaderboards feel motivating for a week and then teams hide issues. DORA says the goal is improvement over time, not competition. Share trends per team privately and show only aggregate progress broadly.
6. Measurement over improvement
DORA suggests that complex integrations may not be worth the upfront investment and that conversations or its Quick Check can be a start. For security, a spreadsheet exported from your scanner once a month is enough to begin. Spend the saved time fixing the top three issues.
A short audit you can run
- List every security number on your current dashboard.
- For each, write who acts on it and what they would do differently if it moved.
- Delete any with no answer.
- Check that none is tied to a bonus or a public ranking.
Quick check
Are targets always bad?
No. Targets are fine when they are paired with counter-measures and reviewed by people who can see the context. The risk is a single number tied to reward.
What is the fastest sanity check on a metric?
Ask what behavior would improve the number without improving security. If you can name one easily, add a counter-measure.
How Safeguard fits
Safeguard offers dependency scanning, reachability analysis and policy gates, which give you exploitability context so counts are not the only signal. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, DORA's software delivery performance metrics (misuse guidance): https://dora.dev/guides/dora-metrics/
Last reviewed: 19 October 2026.
