Use your SBOMs to answer three questions before a major upgrade: which products use the library, which use it directly or only through another package, and what else changes with it. That turns an open ended migration into an ordered list of services with known owners.
Why upgrade planning starts with inventory
Major version upgrades go wrong when the team finds out halfway that three more services depend on the old version. An SBOM is a machine readable inventory of components and the dependency relationships between them, which is the data you need to avoid that surprise. CycloneDX describes its SBOM as an inventory of components, services and the relationships between them, and lists outdated components as one of the risks it helps you spot.
If your SBOMs live in one searchable place, the first step takes minutes. If they sit in repositories, you will be cloning things.
Steps
- Search for the library and the exact old version. List every SBOM that contains it, across all products. Record product, service, version and environment.
- Split direct from indirect. A direct dependency is yours to upgrade. An indirect one is pulled in by another package, so you may need that package to move first. In npm projects, the explain command prints the chain of dependencies that caused a package to be installed.
- Check what is available. For npm, the outdated command shows the wanted version (the highest your declared range allows) and the latest version, which tells you whether the move is a range change or a code change.
- Group by owner. Give each team its list rather than one giant ticket.
- Order by exposure. Internet facing services and ones with known advisories go first. Internal batch jobs can follow.
- Re-generate SBOMs after each merge and confirm the old version is gone from that service.
What a plan looks like
| Service | Dependency path | Owner | Order | Done when |
|---|---|---|---|---|
| Public API | Direct | Platform team | 1 | New SBOM shows only new version |
| Billing worker | Via an internal shared package | Payments team | 2, after the shared package ships | New SBOM clean |
| Reporting job | Direct | Data team | 3 | New SBOM clean |
What the SBOM will not tell you
It will not tell you whether the new major version changes behaviour you rely on. Read the release notes, run your tests, and try the change in one low risk service first. An SBOM also reflects one point in time, so regenerate it before you trust the list.
It also will not show whether your code actually calls the affected parts of a library. Reachability analysis can help you decide which upgrades are urgent and which can wait for a normal release.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and transitive components appear in the same inventory.
Safeguard generates and scans SBOMs and dependency inventories, so the list in step 1 comes from one place. You can try a free scan on a repository to see what it finds.
Quick check
Do I need a new SBOM for each upgrade step?
Yes. Generate one after each merge so you can confirm the old version is really gone and keep a record of the change.
Can an SBOM tell me if the upgrade will break my code?
No. It tells you where the library is used. Tests and release notes tell you what breaks.
Sources
Last reviewed: 19 October 2026.
