The team that owns the library fixes it and publishes a patched release. The teams that use it each upgrade and deploy. Splitting the work this way keeps one person accountable for the fix and many for the rollout. Track adoption by service, with a deadline set by the library owner's severity call.
Two jobs, two owners
A vulnerable internal library creates two separate tasks that often get mashed together.
- Remediation of the library itself: patch, test, release.
- Adoption by consumers: bump the version, rebuild, redeploy.
If nobody owns the first, the second never starts. If nobody owns the second, the library has a fix that sits unused. Name both owners in the incident or ticket.
What the library owner must do
- Publish a patched version with a clear changelog line saying what was fixed.
- Keep the upgrade small. A security release that also changes a public interface slows every consumer down.
- Backport to supported older lines when consumers cannot jump a major version.
- Publish the affected and fixed versions in a place consumers can query.
- Give a deadline and a reason, not just a link.
What consumers must do
- Bump to the fixed version, or apply an override if the library arrives transitively.
- Rebuild and redeploy. A merged version bump does not fix production.
- Report back, or let the pipeline report, so the owner can see completion.
Decide centrally, apply locally
Central teams can reduce the effort by opening the upgrade pull requests themselves. Dependabot style tooling can group updates, and GitHub documents that by default each outdated dependency gets its own pull request unless groups are configured. Grouping makes sense in a service with several related bumps.
Keep a clear line, though. The consuming team still owns review and merge for its service.
Measure adoption
| Measure | Why |
|---|---|
| Services on a fixed version | Progress |
| Services deployed on a fixed version | Real exposure |
| Median days from release to deploy | Process health |
| Services with no owner response | Escalation list |
Report to the library owner weekly until deployed coverage reaches the agreed level, then close the item.
Prevent the next one
Version your internal libraries with semantic versioning, publish a deprecation window, and make consumers declare ranges that accept patch releases. A fix that arrives as a patch update flows in far faster than one that needs a manual major upgrade.
Quick check
Should the security team fix the library?
Security can help, but the owning team should ship the fix. Otherwise nobody is accountable for maintenance later.
What if a consumer cannot upgrade?
Ask for an exception with an expiry and a compensating control, and keep it visible on the adoption table.
Safeguard can open fix pull requests when you enable autonomous remediation, which is off by default, and its dependency scanning shows which services still use the old version. You can run a free scan to see it on one project.
Sources
Last reviewed: 19 October 2026.
