The library owner triages first. A vulnerable dependency inside a shared library is the owner's to assess and, if it matters, to fix with a new release. Consumers become responsible for upgrading once that release exists, and for any consumer specific exposure.
Direct and transitive
A direct dependency is one the library declares. A transitive dependency is pulled in by one of those. Consumers usually have both inside their own tree, and a scanner will report the finding in every service that includes the library, which is why one advisory can look like forty problems.
The owner sits upstream of all of them, so a single fix in the library is cheaper than forty separate workarounds.
The triage flow
- Confirm the finding. Is the affected version actually resolved in a build of the library, or only allowed by a range?
- Check reachability. Does the library call the vulnerable function? If not, record that, and the urgency drops.
- Check exposure by consumer. A consumer may call the library in a way that exposes the path, even when the library itself does not.
- Decide. Fix now, fix in the next release, or accept with an end date.
- Release. A patch release if the update is compatible, a minor or major if it is not.
- Tell consumers. Use the notice template from how to announce a security release.
Who does what
| Step | Library owner | Consumer |
|---|---|---|
| Confirm and assess | Yes | Reviews the owner's assessment |
| Release a fix | Yes | No |
| Override a transitive version locally | Only as a stopgap | Possible if the owner is slow, with a note |
| Upgrade and deploy | No | Yes |
| Accept residual risk in their service | No | Yes |
Overrides are a stopgap
A consumer can force a newer version of the transitive package with an override or resolution setting. That works, but it creates a hidden difference from what the owner tested. Record it with the reason and a removal date, and remove it when the owner ships the fix.
Use reachability to share the work
If the owner can show the vulnerable code is not called by the library, most consumers can wait for the next release. If it is called, speed matters. See reachability across internal packages for how the call path analysis works across package boundaries.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory and follow a vulnerable component back to the library that pulls it in.
Safeguard can help with the inventory side: its SBOM and dependency scanning shows which services pull in a given internal library, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Should every consumer patch separately?
Usually not. A fix released once in the library is cheaper and more consistent. Local overrides are for urgent cases only.
What if the library owner does not respond?
Escalate through the engineering manager route, apply a documented local override, and raise whether the library is orphaned.
Last reviewed: 19 October 2026.
