Release the package that contains the fix, then every package that bundles it or pins it, and nothing unrelated. Use the dependency graph to find the set, bump each version, and verify each built artifact. A fix in a shared library that never reaches the apps using it protects no one.
Two ways a fix can fail to propagate
In a monorepo, a shared library may be used in two ways. If apps reference it by workspace link, one change affects all of them at the next build. If apps depend on a published version, they keep using the old one until someone updates the reference. Many repos mix both, so you must check, not assume.
There is also the matter of what each app ships. A server image that bundled the old library needs a rebuild. A mobile app that embedded it needs a new store release.
Steps
- Identify the package that contains the vulnerable code and the fix.
- List every package that depends on it, directly or through another package. Your build tool or package manager can print this graph.
- For each dependent, decide: does it bundle the library into its artifact, or load it at runtime from a separate install?
- Bump the version of the fixed package and of each dependent that must ship again.
- Build every affected artifact from clean state. Do not reuse caches that may hold the old output.
- Scan each built artifact or its SBOM and confirm the fixed component version.
- Release in dependency order: library first, then packages that use it.
What to include and what to leave out
| Package type | Release? | Reason |
|---|---|---|
| Contains the fix | Yes | The fix itself |
| Bundles the fixed package | Yes | The old copy is inside |
| Pins a published version of it | Yes, after updating the pin | Otherwise it keeps the old one |
| Uses it only in tests or tooling | Usually no | Not shipped to users |
| Unrelated packages | No | Keep the hotfix small |
Do not let tooling fool you
Automatic version bump tools save time, but check what they propose. A tool that bumps every package because of one change inflates the release and hides what matters. A tool that bumps only the changed package may miss the apps that bundle it. Review the plan before approving.
Keep a record
For each affected package, record the old version, the new version, and the artifact digest. If you later need to prove the fix reached an app, that table is your evidence. Compare the SBOM of the old and new release for each one.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one component appears across several consumers, which is the graph you need before choosing what to release.
Safeguard builds a dependency inventory and SBOMs across repositories, so you can see which services and apps contain a vulnerable shared component. A free scan is at gold.safeguard.sh/scan.
Quick check
Do I rebuild apps that only link the library at build time?
Yes. The fixed code only enters the artifact when the app is rebuilt.
Should every package in the repo get a new version?
No. Release the fixed package and its dependents that ship the code, to keep the hotfix small and clear.
Last reviewed: 19 October 2026.
