Export an SBOM for each service, merge them into one list, group components by ecosystem and owner, flag anything end-of-life or with a known advisory, size each group, and cut the list to what the quarter can hold. The result is a ranked backlog you can defend, not a wish list.
What an SBOM gives you that a lockfile does not
A lockfile describes one project. An SBOM, in CycloneDX or SPDX form, is a portable inventory you can produce for every service, container image and build output, then combine. For planning, that cross-service view is the point. It shows that eleven services share the same outdated logging library, which a single lockfile never will.
An SBOM lists what is present. It does not say what to upgrade first. You add that judgment in the steps below.
Step 1: Export and merge
Generate an SBOM per deployable unit in CI so the data is current, not a stale spreadsheet. Merge them into one table with columns for component name, version, ecosystem, which services use it, and whether it is direct or transitive.
Step 2: Group, do not list
A backlog of 600 components is unusable. Group them into upgrade units that a person can own:
- By family. A framework and its plugins move together.
- By runtime. Language runtime, base image and package manager belong in one unit.
- By owner. Every unit needs a team name.
Most inventories collapse into a few dozen units this way.
Step 3: Flag the reasons to act
Add flags to each unit. Keep them factual and checkable.
| Flag | Where it comes from |
|---|---|
| End of support within two quarters | The project's own published support policy |
| Known advisory with a fixed version | Advisory databases, matched to your versions |
| Advisory in code you actually call | Reachability analysis on your code |
| Unmaintained upstream | Release and commit activity, checked by hand |
| Major versions behind | Compare against the latest release |
The reachability flag is useful for ordering. A vulnerable function that your code never calls is real debt, but it ranks below one on a request path.
Step 4: Size it
Estimate each unit in a small, medium or large bucket using your own history rather than guessing in days. If a framework major took two engineers a sprint last time, that is your large. Our guide to taking a major version upgrade in small steps helps break large units down.
Step 5: Cut to fit
Rank by the flags, then draw a line where the quarter's capacity ends. Everything above the line is committed. Everything below goes into a visible deferred list with a reason, not into silence. Review that deferred list at the next planning session.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a dependency inventory shows direct and transitive components in one place, which is the raw material for step 2.
Where Safeguard fits
Safeguard produces SBOMs and scans dependencies across your repositories, so the merged inventory in step 1 does not have to be built by hand. A free scan is available at gold.safeguard.sh/scan.
Quick check
Do I need SPDX or CycloneDX?
Either works for planning. Pick the one your tools and customers already accept, and keep it consistent across services.
How often should the backlog be rebuilt?
Regenerate the SBOMs on every build, and re-rank the backlog once per quarter, with a short check each month for new advisories.
Last reviewed: 19 October 2026.
