Generally no. A personal score turns shared code, shared libraries, and shared pipelines into individual blame, and it punishes people who take on risky legacy work. Measure at the service or team level, and use individual conversations for coaching, never ranking.
Why individual scores mislead
Security outcomes are produced by systems. A developer's name on a commit does not say who chose the library, who set the base image, who wrote the pipeline, or who approved the exception. Assigning a finding to the last person who touched a file is a convenient guess, not a cause.
DORA's guidance says its delivery metrics are meant for the application or service level, and that comparing across very different applications can mislead. The same logic applies even more strongly to individuals. It also notes that isolating people or teams with specific metrics can lead to friction and finger pointing.
There is a second problem, which comes from Goodhart's law. If a score attaches to a person, the person optimizes the score.
What people do when they are scored
- Avoid the old, risky service, because touching it adds findings under their name.
- Skip opening pull requests that bump dependencies, because new findings may surface.
- Hold back a bug they noticed, to avoid looking like they wrote it.
- Pick the easiest items to fix, leaving the hard ones for someone else.
Each choice is rational for the individual and bad for the company.
What to use instead
| Level | Useful view | Avoid |
|---|---|---|
| Service | Open exposure by age, owner, blocker | Rank among services |
| Team | Trend against its own past | Team versus team league table |
| Person | Private coaching on specific practices | Numeric score visible to peers |
| Organization | Paired outcome metrics for leaders | One composite number |
If you want to encourage good habits among individuals, recognize behaviors that are hard to count and easy to see, such as writing a clear threat note in a design review, reporting a near miss, or removing a dependency.
A short way to introduce team views
- Assign every service an owning team and name it in the inventory.
- Show findings by service, not by author.
- Give each team lead a monthly view of its own trend and the oldest open items.
- Keep individual information out of dashboards that peers can see.
- Review once a quarter whether coverage rose or fell after the change.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how dependencies are shown per project, which is the natural unit of ownership, not per person.
Safeguard's SBOM and dependency scanning organizes findings per project, which fits a service or team level view. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Can security data appear in performance reviews at all?
It can inform a conversation about practices, but a numeric score tied to a person invites gaming. Keep it qualitative and focused on behaviors.
What if one person causes most of the findings?
Check the system first: base images, shared libraries, and missing guardrails. If coaching is still needed, do it privately.
Sources
Last reviewed: 19 October 2026.
