No. Ranking individuals by vulnerabilities introduced rewards avoiding hard code and discourages reporting. Attribution is also unreliable, since a flaw often comes from a design, a dependency or a review that missed it. Measure systems and flow, such as time to fix and recurring causes, and review incidents without blame.
Why the idea is tempting
It feels fair: if someone writes the bug, count it against them. Leaders also want a simple accountability signal. But the signal this produces is weak and the side effects are strong.
Four problems
- Attribution is shaky. Version control shows who last touched a line, not who decided the design, who reviewed it or which library behaviour surprised everyone. A vulnerability in a dependency has no author in your team at all.
- Work is not equal. The people who handle authentication, parsing and payments touch more risky code, so they score worse. A leaderboard moves them away from important work.
- Reporting dries up. If finding a flaw in your own code costs you, you find fewer. The Campbell's law formulation says the more an indicator drives decisions, the more it distorts the processes it monitors.
- Teams game it. Squash commits under another name, split changes, delay scans until after review, or argue each finding's severity.
What to measure instead
| Level | Measure | Use |
|---|---|---|
| Team | Time to fix, by severity or context band | Find stuck work |
| System | Recurring weakness classes | Pick a shared fix, such as a safer library |
| Process | Share of findings caught before merge | Check if gates work |
| Learning | Repeat issues after a fix | Improve guidance and tests |
Recurring classes are the highest value. If many findings share one pattern, the remedy is a secure default, a lint rule or a wrapper, and not a reprimand.
A blameless review routine
- For each notable finding, ask how the system allowed it: what check should have caught it, and why did it not?
- Record the cause class, not the person.
- Choose one change to make the class harder to repeat: a test, a rule, a template, a doc.
- Check after a quarter whether that class recurred.
Handling real performance concerns
If a specific person repeatedly ignores agreed practice, that is a management conversation based on observed behaviour, such as bypassing gates, not on a count of findings. Keep it separate from metrics.
Use of gamification
Light recognition for useful behaviours, like closing old findings or writing regression tests, can work, but choose behaviours that cannot be inflated cheaply, and reward the team rather than an individual. Avoid public negative boards.
What to tell leadership
Offer a replacement, not just a refusal: time to fix per team, recurring cause classes and gate coverage. That answers the accountability question without the side effects.
Safeguard offers SBOM and dependency scanning, reachability analysis and policy gates. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Can commit history tell us who introduced a flaw?
Only who last changed the line. Design, review and dependencies are not visible there.
What replaces a leaderboard?
Team level time to fix, recurring cause classes and share of findings caught before merge.
Sources
Last reviewed: 19 October 2026.
