Most organizations end up with a hybrid: product teams fund fixes in their own code from their own capacity, while a central pool funds shared platforms, cross-cutting migrations and surge work. Pure team funding starves shared code, and pure central funding detaches cost from the people who write the code.
The three models
| Model | How it works | Main strength | Main weakness |
|---|---|---|---|
| Team funded | Each team fixes issues in its services from its own capacity | Ownership is clear | Shared libraries and platforms get no one |
| Central pool | A security or platform group has engineers who fix on behalf of teams | Consistent, fast on cross-cutting work | Teams stop feeling responsible, and the pool becomes a bottleneck |
| Hybrid | Teams fix their own code, the pool covers shared and surge work | Balances ownership and reach | Needs clear rules at the boundary |
Neither extreme fails because of bad intent. Each fails because of incentives. If fixing is free to the team, they ask for more. If fixing is entirely their problem, they hide the work.
What goes where in a hybrid
Write the boundary down, in one page:
- Team funded: vulnerabilities in the service's own code and direct dependencies, scheduled through the team's normal planning.
- Pool funded: shared base images, internal libraries used by many services, build and deploy tooling, and migrations that cut across teams.
- Surge funded: a time-limited draw on the pool when a high-impact advisory hits many services at once.
For shared code the real question is who owns the fix. See who fixes a vulnerable internal shared library for the release train problem.
Make the cost visible
Funding debates go better with numbers that nobody argues about. Track fix effort by team and by category, using the labels from should security fixes count toward team velocity. Then publish a simple view: hours spent on security fixes per team, per quarter, next to the open item count by age.
Showback means reporting the cost to each team without moving money. Chargeback moves it. Start with showback. It exposes the pattern without creating a fight over accounting, and many organizations never need more.
Rules that keep the model fair
- Age is the trigger for escalation, not the owner's mood. When an item passes its service level, the central pool may step in and note the team's missed commitment.
- Fixes are not a favor. If the pool fixes a team's code, a review by that team is still required before merge.
- Capacity is reserved before the quarter starts. A pool without reserved hours is a wish.
- Review the boundary every two quarters. What was cross-cutting last year may be a team concern now.
What to say to executives
Executives usually want one number. Give them two: the share of engineering time spent on security fixes overall, and the share that went through the central pool. Add the trend in open items by age. If the pool is always overloaded, ask for more reserved capacity. If it is idle, the boundary is too narrow.
For the wider question of whether leaders should fund more, see three funding options to put in front of executives.
Where tooling helps
Safeguard's asset discovery and SBOM scanning help find which team owns which component, and its policies can route findings by owner. Autonomous remediation can propose fix pull requests, but it is off by default and every category begins on Manual, so teams review each change.
Quick check
Should security fixes come out of the feature budget?
For code a team owns, yes, because it is part of delivering a sound product. For shared platforms, a central pool avoids penalizing the team that happens to maintain them.
Is chargeback worth it?
Only if showback fails to change behaviour. Chargeback adds accounting overhead and can make teams hide work.
Last reviewed: 19 October 2026.
