Usually not. A public ranking of teams by findings or fix speed pushes people to hide, reclassify, or avoid scanning instead of reducing risk, and it compares teams with very different systems. Show each team its own trend over time, and let leaders look at the whole picture privately.
What goes wrong with rankings
Ranking works in a sport because every team plays the same game under the same rules. Engineering teams do not. A payments service with ten years of history and a new internal tool will never produce the same number of findings, even with equal discipline.
DORA's guidance on delivery metrics lists several pitfalls that map directly onto a security leaderboard. It warns against competing: the goal is to improve your own team over time, not to beat other teams. It warns against disparate comparisons, because a mobile app and a mainframe system should not be put on one scale. And it warns against siloed ownership, since isolating teams with specific metrics can lead to friction and finger pointing.
Add the general effect described by Goodhart's law, and the leaderboard becomes a prize for whoever games the number best.
Common ways a leaderboard gets gamed
- Teams stop onboarding new repositories, because a new scan adds findings and drops them down the table.
- Severity gets argued down, one ticket at a time.
- Findings move into an accepted risk status so they no longer count.
- The easiest team to score well is the one with the smallest, newest codebase, which says nothing about care.
The cost is not only bad data. A team that learns that honest scanning makes it look worse will scan less. You lose coverage, which is the thing you needed most.
What to show instead
| Instead of | Use | Reason |
|---|---|---|
| Team rank by open findings | Each team's own trend line | Compares like with like |
| Single score per team | Two or three paired metrics | Harder to game, richer picture |
| Public shaming list | Private review with each team lead | Keeps focus on help, not blame |
| Findings per team | Exposure window for exploited or reachable issues | Tracks risk, not volume |
If leaders want to know where to send help, give them a view that lists the oldest unresolved high risk items by service, with the owner and the blocker. That is a work queue, not a leaderboard.
If you already have a leaderboard
- Stop publishing the rank. Keep the data.
- Replace it with a trend per team and a short note on what changed.
- Add the counter metrics next to it: exceptions, severity changes, and scan coverage.
- Tell teams in plain words that the change is to protect honest reporting.
- Check coverage a month later. It should rise, not fall.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how findings change over time for one project, and notice how much more useful a trend is than a rank.
Safeguard's continuous monitoring and policy features can track findings per project over time, which suits a per-team trend view. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Can a leaderboard motivate teams in a healthy way?
It can for a short, well framed campaign, but it rarely lasts. Comparisons across unlike systems feel unfair, and people respond by optimizing the score.
How do we find the teams that need help without ranking?
List the oldest high risk items with owners and blockers, and talk to the leads privately. Offer time and tooling rather than a place on a table.
Sources
Last reviewed: 19 October 2026.
