Use four rungs with a time limit on each: the two engineers, the service owner, a standing dependency review, then a named executive. Each rung has one decider and one deadline. Disputes stall when nobody knows who can say yes, so write that down before you need it.
Why a ladder helps
Most dependency disputes are small. A version bump, an override, a pin that blocks a release. They become large because they sit in chat threads with no decider. Two weeks pass, the advisory is still open, and everyone is irritated.
A ladder does not make disputes disappear. It makes them end.
The four rungs
| Rung | Who | Time limit | Decides |
|---|---|---|---|
| 1 | The two engineers involved | 2 working days | Anything both agree on |
| 2 | Service owner of the affected artifact | 2 working days | Version, override, or exception for their service |
| 3 | Dependency review group | Next weekly slot | Cross team changes, shared files, policy exceptions |
| 4 | Named executive sponsor | 3 working days | Priority conflicts the group cannot resolve |
The time limits are examples. Pick your own, but pick them.
Rung by rung
Rung 1. The two people try to agree on the facts: is the package shipped, is it reachable, what fix exists. If they agree, they act. If not, whoever is blocked escalates, without apology.
Rung 2. The service owner decides for their own service. They can approve an override, accept a short exception, or ask for a bump. The decision is written in the ticket. Most disputes should end here.
Rung 3. Some changes reach beyond one service: a root manifest in a monorepo, a shared constraints file, a company wide bill of materials. A small standing group of platform, security, and two rotating service representatives handles these. They meet weekly, and their decisions are short and recorded.
Rung 4. If priorities collide, such as a release date against an advisory, a named executive picks. This should be rare. If it is not, the policy needs fixing.
What each escalation must include
- The question in one sentence.
- The five facts: shipped, reachable, attacker controlled, fix available, exposure.
- Options considered and the cost of each.
- The deadline that matters, such as a release or an advisory date.
An escalation without these goes back to the sender.
Keep the group light
The review group is not a committee that approves every update. Routine bumps with passing tests never reach it. Its job is the shared levers and the true conflicts. If it meets for an hour a week and mostly says yes, that is a healthy sign.
Track the outcomes
Count how many disputes end at each rung and how long they took. If most reach rung 3, the earlier rungs lack authority or evidence. If rung 4 ever fires often, priorities are unclear at the top.
Quick check
Who has the final say on a vulnerable dependency in one service?
The service owner, within the written defaults agreed with security. Cross team changes go to the review group.
How long should a dispute take?
Set a limit for each rung. A week or less from first disagreement to a recorded decision is a reasonable target for most teams.
Last reviewed: 19 October 2026.
