An SBOM diff for an extraction should show components removed from the monolith, components added to the new service, and any component now present in both. Matching each change against known vulnerabilities tells you whether exposure fell or only moved.
What an SBOM gives you
CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components. CycloneDX, one common format, can represent components, services, dependencies and relationships. That makes it a good basis for comparing two states of a system.
Which SBOMs to compare
Generate three documents with the same tool and settings:
- The monolith before extraction
- The monolith after the feature is removed
- The new service
Using the same generator matters. Different tools name components differently, and the diff fills with noise.
What to look for
| Diff result | What it means | Action |
|---|---|---|
| Component only in monolith (before) | Was removed with the feature | Confirm it is really gone from the build |
| Component in new service only | New exposure | Scan it, check versions |
| Component in both after | Duplicated | Decide if a shared version policy is needed |
| Same component, different version | Drift | Converge on one version |
| Component still in monolith though code moved | Dead dependency | Remove it |
The last row is often the biggest win. When a feature leaves, its libraries often stay in the monolith's build file, still present and still scanned. Remove them and the finding count drops with no code change elsewhere.
Step by step
- Export each SBOM in the same format.
- Normalize identifiers, for example package URLs, so the same library matches across files.
- Compare by identifier and version.
- Run vulnerability matching on each result.
- Record the result in the pull request or ticket for the extraction.
Reading the vulnerability side
Do not stop at counts. Ask which findings are new, which were closed by removal, and which carry over. A new service that inherits a vulnerable library from the monolith has copied the problem. Reachability analysis then tells you whether the new service actually calls the vulnerable code, which may differ from the monolith because the service has a narrower job.
Keep SBOMs with the release
Store the SBOM with each build artifact so that, months later, you can say what shipped. For related guidance see SBOM for microservices architecture and our guide to deduplicating components across many SBOMs.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the component list and version column. Those are the fields you compare between the before and after documents.
Safeguard generates SBOMs and matches them to advisories, and the free scan at gold.safeguard.sh/scan lets you try it on a repository.
Quick check
Why use the same tool for all SBOMs?
Different generators name and group components differently, which creates false differences.
Is a smaller SBOM always better?
Not necessarily. Fewer components usually means less to patch, but what matters is that the diff is explained.
Sources
Last reviewed: 19 October 2026.
