Should you pay developers per vulnerability fixed?

No. A bonus or point for every vulnerability fixed rewards volume, so people pick the easy items, split work into more tickets, and ignore the hard ones that matter. Reward risk removed instead, such as exposed critical paths closed, and share the credit across the whole team.

Why per-fix rewards backfire

A per-fix payment turns a count into a target. Two older ideas describe what happens next. Goodhart's law is usually stated as "when a measure becomes a target, it ceases to be a good measure". Campbell's law adds that the more a quantitative indicator drives decisions, the more it invites pressure to distort the very process it was meant to monitor.

A related pattern is called the cobra effect: an incentive that makes the original problem worse. The well known cobra bounty story is often retold as fact, but a recent note on the Wikipedia article says its historical record is disputed. Treat it as a teaching tale, not as evidence. The point holds without it, because the same incentive logic is easy to see in any ticket queue.

In a vulnerability queue the distortions are predictable:

• Easy items go first. A hundred low-risk library bumps beat one hard architectural fix on the count.
• One underlying problem gets split into many tickets, each of which pays out.
• Items that are hard to fix get reclassified or marked accepted so they leave the queue.
• Nobody wants to look for new problems, because new findings add work that is not rewarded.

What to reward instead

Pick outcomes that follow risk, not volume. A few that hold up better:

Keep the reward small and mostly symbolic. Recognition in a team review, time to work on a painful cleanup, or a shout out for removing a risky dependency all work without turning security into a points race.

Pair every count with a counter metric

If you do report fix counts, put them next to a metric that moves the other way when people game them. Reopen rate shows fixes that did not hold. The count of exceptions and severity downgrades shows items escaping the queue. The age of the oldest open critical shows whether the hard work is waiting. The DORA guidance on software delivery metrics gives the same advice in its own domain: avoid setting a single metric as a goal, and choose several metrics with some tension between them.

A simple policy you can adopt

1. Publish fix counts as information, never as a payment trigger.
2. Review a sample of closed items each month and check that the fix shipped.
3. Name the counter metrics on the same page as the count.
4. Recognize teams for removing causes, not for closing tickets.
5. Retire any metric that has clearly been bent, and say why without blaming anyone.

Try it yourself

Click through it at your own pace, or open it full screen.

Look at how findings are grouped and prioritized, then ask which view would be hardest to game with a simple count.

Safeguard's vulnerability management and reachability analysis can help show which fixes remove real exposure, so reporting can follow risk instead of ticket totals. A free scan is available at https://gold.safeguard.sh/scan.

Quick check

Sources

• DORA, software delivery performance metrics and common pitfalls
• Goodhart's law (Wikipedia)
• Campbell's law (Wikipedia)
• Perverse incentive and the cobra effect (Wikipedia)

Last reviewed: 19 October 2026.