Product teams own upgrades for what they ship. Platform teams own the shared files, tooling, and base layers that many products inherit. Security owns the advisory process and the evidence bar. Write the split as a table, because unwritten splits turn into arguments the first time an advisory lands.
Why the question keeps coming back
Dependency work sits between groups. A product team feels it distracts from features. A platform team feels it cannot upgrade what it does not run. Security sees open findings and no owner.
The confusion is understandable. Some dependencies live in a product repository. Others live in a shared parent POM, a root manifest, a base image, or an internal library. The owner changes with the location.
A responsibility table
| Layer | Owner | Examples |
|---|---|---|
| Direct and transitive dependencies of one service | Product team | App manifest, lockfile, local overrides |
| Shared build files across services | Platform team | Root manifest in a monorepo, parent POM, bill of materials, central constraints file |
| Base images and runtime versions | Platform team | Container base, language runtime |
| Internal shared libraries | Library owner | Their own dependency ranges and releases |
| Advisory intake, evidence bar, exceptions policy | Security | Triage rules, time boxes |
Where a layer crosses groups, name the primary owner and the reviewers. A change to the root manifest, for example, is owned by platform and reviewed by the teams whose workspaces resolve the package.
What each group commits to
Product teams act on advisories for their services within the agreed time box, keep tests good enough to make upgrades safe, and record exceptions with dates.
Platform teams keep shared files current, review changes quickly, and publish releases of shared libraries with updated ranges. They also respond when a product team asks for a shared change.
Security supplies facts: which package, which version, whether it is reachable, what the fix is. It does not decide how a team ships.
Funding the work
Dependency upgrades die when they compete with features and lose. Two habits help.
- Reserve a fixed share of each sprint for maintenance, and report on it.
- Count dependency work in team metrics, so it is visible rather than invisible.
Treat a stale dependency as a form of debt with interest. The longer an upgrade waits, the more versions it must cross at once.
Signs the split is working
- Advisories reach a named owner within a day.
- Overrides carry reasons and review dates.
- Shared file changes get reviewed by affected teams without chasing.
- Few items reach the escalation ladder, and those that do end quickly.
Signs it is not
- Findings assigned to a team alias nobody reads.
- The same pin argued about every quarter.
- Product teams waiting on platform for fixes they could make locally.
If you see these, the table is missing a row or is not being followed.
Quick check
Who owns a vulnerable dependency inside one service?
The product team that ships the service, even if the dependency is transitive. Platform helps when the fix lives in a shared file.
Who owns the root manifest in a monorepo?
Usually the platform team, with changes reviewed by the product teams whose workspaces are affected.
Last reviewed: 19 October 2026.
