The team that owns the affected service pays for fixing its own code, while the requesting team pays for the analysis, tooling and migration notes. For major, org wide bumps, a shared platform budget or a protected engineering allocation covers the gap. Decide this before the first incident, not during it.
Why cost is the real dispute
Many "technical" version disputes are about who will spend the next two weeks. A security team asks for a bump. A product team knows its roadmap does not have room. Both are reasonable, so the argument circles.
The Semantic Versioning spec says a major version signals incompatible API changes. That is a cost signal. A patch bump is usually cheap. A major bump of a shared library can touch every consumer, so the funding rule should depend on that class.
A cost sharing model
| Change type | Who does the work | Who funds it |
|---|---|---|
| Patch fix with passing tests | Service team, in normal flow | Service team |
| Minor bump with small fixes needed | Service team, with help from the requester | Service team |
| Major bump of a shared library | Service teams, coordinated by platform | Platform budget or protected allocation |
| Urgent override for a reachable, known vulnerability | Build owner applies the override, service teams verify | Shared, with the exception recorded |
The model has one principle: the party that creates the demand carries the cost of making the demand easy to meet.
What the requesting team should provide
If you want other teams to move, do some of the work first:
- An inventory of exactly which services are affected, so no team spends time on a false alarm.
- A reachability check, so teams know whether the vulnerable code runs in their service.
- A tested branch or pull request that demonstrates the upgrade on one service.
- A migration note listing the breaking changes found.
- A proposed deadline with a reason.
This lowers the cost for everyone and removes the common objection, "we do not know what this involves."
What the service team should provide
- An estimate within a few days. "We cannot say" is not an estimate, so ask for the smallest test that would give one.
- A named owner for the change.
- A flag if the bump collides with a release freeze or a customer commitment.
Avoid the three stall patterns
- Tragedy of the shared library. Everyone agrees it should be upgraded and nobody schedules it. Fix: the platform owner is accountable and gets a protected allocation.
- Security as the only driver. Teams learn to see security tickets as noise. Fix: bundle bumps into planned upgrade windows where you can.
- Silent local overrides. Teams quietly pin an old version at their root. Fix: require an exception record with an end date, and scan for overrides.
Make the trade visible to leadership
Leadership decisions are easier when options are written plainly: "Upgrade now costs about X engineer days across Y teams. Accepting the risk until the next window means this reachable issue stays for N weeks, with an exception owner." Use your own estimates and your own numbers, not borrowed ones.
Quick check
Should security teams fix other teams' code?
Usually not. They can supply the analysis and a sample fix, but the owning team merges and supports the change because it knows the service best.
What if nobody has budget?
Escalate with the written options. If leadership chooses to accept the risk, record that as an exception with an owner and a review date, so the choice is deliberate.
Sources
Last reviewed: 19 October 2026.
