A fair security scorecard compares each team with its own earlier results, adjusts for the size and exposure of what it owns, shows a few outcome measures rather than raw counts, and is shared for conversation rather than ranking. Public league tables reward gaming and punish teams that inherited old code.
Why scorecards go wrong
Teams own very different things. One owns a ten year old billing service. Another owns a new internal tool. Ranking them by open findings punishes the first and tells you nothing. DORA's guidance on its delivery measures applies equally here: use measures to improve over time, apply them per application or service, avoid comparing unlike systems and avoid ranking teams. Mandated targets also invite gaming.
Choose a few outcome measures
| Measure | Why it is fair |
|---|---|
| Median time to fix new high risk findings | Compares behaviour, not inherited debt |
| Share of repositories with required checks enabled | Coverage, which every team controls |
| Overdue items past their agreed date | Reflects follow through |
| Exceptions open and past expiry | Shows discipline with risk acceptance |
| Trend in baseline findings over the quarter | Progress against own start |
Leave out raw totals of findings. If you must show them, show them beside the size of the codebase and the age of the findings.
Layout of a one page card
Show for each team:
- Current value of each measure
- Their own value last quarter, as an arrow or sparkline
- A one line note written by the team lead
- One help request, if any
Add a short column for context: language mix, age of main service, exposure to the internet. Reviewers should see why numbers differ.
How to use it
Share the scorecard in a monthly review with the champions, not in an all-hands. Ask each team what blocked them, not why they are behind. Where several teams struggle with the same thing, treat it as a platform or tooling problem.
Guardrails against gaming
- Do not tie bonuses or performance reviews to a single measure
- Use several measures so improving one at another's expense shows up
- Audit a sample of "fixed" items for real fixes
- Change measures if people optimise the number instead of the outcome
What to avoid
| Avoid | Why |
|---|---|
| Public ranking of teams | Creates defensiveness and hidden problems |
| A single composite score | Hides what to fix |
| Counting findings closed | Rewards closing easy ones |
| Comparing teams with different risk | Unfair and misleading |
Quick check
Should executives see team level data?
They can, with context and trends. Show them where help is needed rather than who is last.
How often should the scorecard update?
Monthly is a good rhythm. Weekly numbers on small teams are mostly noise.
Safeguard provides SBOM and dependency scanning results per repository, which can inform per team views, and you can start with a free scan.
Sources
Last reviewed: 19 October 2026.
