The team that builds and deploys the artifact owns every dependency inside it, direct or transitive. A library team may have pulled the package in, but the service team answers for what runs in production. Settle one decision maker per service before a disagreement starts, not during one.
Why the argument happens
A transitive dependency is a package you did not choose. Your library needs package B, and B needs package C. Nobody on the app team typed C into a manifest, and nobody on the library team thinks of C as theirs either.
When C gets a vulnerability advisory, each side has a fair reading. The app team says the library introduced it. The library team says the app controls the lockfile. Both are right about a different part of the problem.
Two kinds of ownership
Split the question in two, because the answers differ.
- Exposure ownership. Who is accountable for the risk in a running service? The team that deploys it.
- Fix ownership. Who can change the thing that causes the risk? That might be the app team (an override), the library team (a release with a newer range), or the maintainer of C.
Exposure ownership never moves. Fix ownership can sit with someone else, and the exposure owner is responsible for chasing it.
| Situation | Exposure owner | Likely fixer |
|---|---|---|
| Service pulls C through a shared internal library | Service team | Library team or service team override |
| Library published to external users pulls C | Each consuming team | Library team, then each consumer |
| C is pulled by a build tool, not shipped | Team that owns the pipeline | Pipeline owner |
| C is in a base image | Team that owns the image | Platform team |
A simple decision rule
Use three steps and write them down.
- Identify the artifact. Which deployable contains the package? Use the dependency tree or an SBOM to confirm it is actually shipped.
- Name the owner. The artifact owner opens the ticket and sets the deadline.
- Assign the fix. If the library team can release a fix faster than an override can be tested, they get the task, but the deadline stays with the artifact owner.
If two services contain the same package through the same library, each service owner tracks their own exposure. Do not merge them into one ticket owned by the library team, or the library team becomes a queue for everyone else's risk.
What to do when the rule is contested
Some disputes are really about priority, not ownership. A library team may say fixing C is not on their roadmap. Ask for a written answer with a date, or a statement that they will not fix it. Either one lets the service team move on to an override, a replacement, or a documented exception.
Keep the exception short and owned. It needs a name, a reason, and an expiry date. An exception that never expires is a quiet decision to accept the risk forever.
Make ownership visible
Put the owner in the place engineers already look. A service catalog entry, a repository ownership file, or a line in the service README all work. The point is that a scanner finding can be routed to a named team without a meeting.
Review the list when teams reorganize. Orphaned services are where these disputes go to sit unresolved.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a package appears in the inventory and which project pulls it in, because that path is what decides who gets the ticket.
Safeguard's SBOM and dependency scanning shows the path from a finding back to the project that ships it, which gives both teams the same facts to work from. You can run a free scan to see your own tree.
Quick check
Does the library team own a vulnerability in a package their library pulls in?
They own the library's dependency choices going forward, so they should respond. The team that deploys the service still owns the exposure in production.
Can an app team fix a transitive dependency without waiting for the library team?
Often yes, through an override or constraint in the ecosystem's own tooling. It needs testing, and it should carry an owner and an expiry date.
Last reviewed: 19 October 2026.
