When two teams disagree on a shared dependency version, the owner of the build that ships the result should decide, within a stated time limit, using written criteria such as security impact, breakage risk and cost. If no owner exists, name one before the next dispute starts.
Why these disputes stall
Most version disputes are not technical. The tools can already express any answer: npm and Yarn let the root project override a nested version, Maven lets a project declare the version it wants, and Gradle lets you add a constraint. The hard part is that nobody has agreed who is allowed to use those tools on behalf of everyone else.
The usual symptoms are a security team that opens a ticket, a product team that replies "that will break us," and a thread that grows for two weeks. Meanwhile the vulnerable version keeps shipping.
Define the owner of the build, not the owner of the library
A transitive dependency has no single owner in your org. It arrived because some other package asked for it. What you can name is the owner of each place where a version gets chosen:
| Where the version is chosen | Typical owner |
|---|---|
| Root manifest of a deployable app | The team that ships the app |
| Shared parent POM, constraints file or central version list | Platform or build tooling team |
| A library published for other teams | The library maintainers |
| A monorepo root lockfile | Whoever owns the root, usually platform |
The tools themselves reflect this. npm documents that overrides are only considered in the root package.json, and Cargo only reads patch settings from the manifest at the workspace root. So the person who controls the root controls the answer, and that fact should be written down as policy rather than discovered during a fight.
A simple decision rule
Write a short rule and publish it. A workable one looks like this:
- The owner of the deployable build makes the final call for that build.
- For a shared version list, the platform owner decides, after consulting affected teams for a fixed window such as three business days.
- A security finding with a known fix and a reachable path wins over a preference for stability, unless the owner records a time-boxed exception.
- Every decision is written in one place, with a date, a reason and a review date.
The rule does not need to be clever. It needs to be known, short, and applied the same way each time.
What the decider should look at
Ask for the same four facts every time, so the discussion stays on evidence:
- Which versions are in use today, and where. An inventory of the dependency tree answers this in minutes.
- Whether the vulnerable code is actually reachable in the affected services.
- What the change touches: patch, minor or major, using the meaning in the Semantic Versioning spec (major means incompatible API changes).
- What the test suite says after the change.
If the facts are missing, the decision is "gather them by Thursday," not "wait."
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one package can appear at several depths, because that is exactly the situation that starts these arguments.
Where Safeguard fits
Safeguard's SBOM and dependency scanning shows which services pull in which version, and reachability analysis shows whether the vulnerable code is called, so the decider starts from shared facts. You can try a free scan at gold.safeguard.sh/scan.
Quick check
What if the two teams share no common manager?
Name the decider in the policy in advance, usually the platform or build owner for the shared artifact, and give the policy sign-off from engineering leadership once. Disputes then follow the rule instead of the org chart.
Should security have the final say?
Security should set the criteria and the deadline for known, reachable vulnerabilities. The build owner still applies them and records any exception, because they carry the breakage risk.
Sources
- npm package.json: overrides
- Cargo: overriding dependencies
- Apache Maven: dependency mechanism
- Semantic Versioning 2.0.0
Last reviewed: 19 October 2026.
