The team that owns the service should own its dependency upgrades, whatever the language. A central group sets the baseline and tracks the shared report, but it should not carry out every upgrade. Name one person per service, give them a cadence, and make the escalation path for stuck updates explicit.
Why language based ownership fails
A common first idea is to make a "Python person" and a "Java person" responsible for all upgrades in their language. It sounds efficient and tends to break in two ways. Those people become a bottleneck, and they lack the context to know whether an upgrade is safe for each service.
A security team doing all upgrades fails differently. It sees the findings but cannot test the behavior, so changes arrive as unreviewed pull requests that service owners learn to ignore.
A three role model
| Role | Owns | Does not own |
|---|---|---|
| Service owner | Upgrades, testing and merge for their service | The baseline policy |
| Platform or security group | Baseline controls, CI templates, the shared report | Upgrades inside a service |
| Escalation owner | Decisions when an update is blocked or contested | Routine upgrades |
Keep the third role a named person with authority, such as an engineering manager. When a service cannot upgrade because a breaking change needs weeks of work, someone must decide whether to accept the risk for a stated period, add a mitigation, or fund the work.
What each side commits to
The platform group commits to a few things: a template that installs from the lock, a report that groups findings by service owner, and small, well explained update pull requests. The service owner commits to a response time, such as triaging new findings within a stated number of days, and to recording a decision when they cannot upgrade.
Put these commitments in writing, in a single page. Do not rely on a verbal agreement.
Handling cross-cutting libraries
Some dependencies appear in several languages, such as a protocol library with ports for each. Assign a single coordinating owner for the upstream project and let each service owner apply the change. Otherwise five teams investigate the same advisory five times.
Making it visible
Ownership only works if it is in the data. Store the owner as a field on each repo or service record, and route findings by it. If a finding has no owner, treat that as a finding of its own.
A short weekly or biweekly review helps. Thirty minutes, one screen: open findings by owner, oldest first, and any decision waiting on the escalation owner. See also a weekly update routine for many languages.
When ownership is unclear
Orphaned services are the hardest case. Decide a rule in advance: an orphaned service is assigned to the team that depends on it most, or it is scheduled for retirement. Leaving it nobody's problem is the one outcome to avoid.
Safeguard can help here: it scans dependencies and generates SBOMs, applies reachability analysis so you can sort findings by what your code can actually call, and enforces policies and gates on pull requests. You can try a free scan on a repository to see what it finds.
Quick check
Should the security team do all dependency upgrades?
No. They can set policy and provide tooling, but the service owner can test behavior and decide on risk. Split the work by service.
What if a service cannot upgrade for months?
Record a decision with an owner, a mitigation and a review date, and send it to the escalation owner.
Last reviewed: 19 October 2026.
