Generally no. Ranking teams by raw vulnerability counts penalizes teams with more code, rewards teams that scan less, and encourages hiding findings. Compare teams by trend against their own past, age of open items and closure rate, and use the comparison to find help needed, not to assign blame.
What goes wrong with raw rankings
| Problem | How it appears |
|---|---|
| Size bias | A team with a large codebase always tops the list |
| Coverage bias | A team that scans less appears cleaner |
| Gaming | Findings are closed as false positives or suppressed to move up |
| Blame culture | Teams stop reporting problems early |
| Legacy bias | Teams that inherited old systems are punished for history |
This is Goodhart's law at work: when a measure becomes a target, it stops being a good measure. See Goodhart's law and security metrics examples.
What to compare instead
- Trend against the team's own baseline. Is open priority one work falling, flat or rising?
- Age of open items against SLA. The share past SLA and the oldest item.
- Closure rate versus inflow. Does the team close at least as much as arrives?
- Ownership and scan coverage. Are all the team's repositories scanned, and do all findings have an owner?
- Closure quality. The split between fixed and accepted closures.
Display these side by side for each team in a table, without a rank column.
| Team | Trend | Past SLA | Closure vs inflow | Coverage |
|---|---|---|---|---|
| Team A | up, flat or down | count | ahead or behind | share |
| Team B | up, flat or down | count | ahead or behind | share |
Fill with your own data and no overall score.
When a ranking is acceptable
A short list of teams that need help can be useful, for example items far past SLA on priority one. Frame it as a support list: "these teams have items blocked longer than agreed, and here is what we are doing to unblock them." Pair each name with a proposed action from security or platform teams.
How to run the conversation
- Share data privately with the team lead before it goes to wider audiences.
- Ask what is blocking them, rather than why the number is high.
- Record blockers and fix the repeated ones centrally, such as shared dependency upgrades.
- Celebrate trend improvement openly.
Metrics that help the team
Give each team their own view of their findings with fixed versions and due dates. Teams that see clear next actions fix more than teams that see a score. For making the tools work for teams, see measuring security tool adoption without vanity metrics.
Safeguard's policies and gates can apply the same rules to every team so comparison is fair, and a free scan shows the per repository view.
Quick check
Is it fair to normalize by lines of code?
It helps with size bias but has its own distortions. A better step is to compare each team with its own past.
Should leaders see team level data?
Yes, as a table of trend and age, shared with the team first. Avoid ranked leaderboards.
Last reviewed: 19 October 2026.
