For a product made of many services, produce an SBOM per deployable service and, if buyers want one document, a rolled up SBOM for the product that references them. Tell the buyer which one describes what they use, and keep all of them tied to the release version.
The problem buyers do not see
A buyer imagines one application with one dependency list. A startup may run twelve services in a monorepo, each with its own lockfile, plus shared libraries and container images. Handing over a single flat file can hide structure. Handing over twelve files can confuse.
Options compared
| Approach | Strength | Weakness |
|---|---|---|
| One SBOM per service | Matches what each service really contains | Buyer must assemble the picture |
| One rolled up SBOM for the product | Easy to hand over | Can blur which service holds which component |
| Both, linked | Clear and complete | More to maintain |
The CISA 2026 minimum elements guidance addresses this directly. It says an SBOM can include subcomponent information in one document or link to separate SBOMs for each subcomponent, and that either approach can satisfy its Coverage expectations, provided the recipient has access to all linked SBOMs (see Sources).
A practical default
- Generate per service in CI. Each deployable unit gets its own SBOM on release.
- Name by service and version. Use a consistent naming pattern so any file can be found from a release.
- Roll up on request. If a buyer wants one file, combine the per service files and state which release it represents.
- Share the right slice. If a buyer only uses your API, you may send only the API related SBOMs, and say so.
Shared libraries and duplicates
In a monorepo, a shared library may appear in many services at different versions. The guidance says that if multiple instances of a component have different metadata, each instance should be listed separately with its dependency relationship. Do not collapse them to look tidy. A reviewer checking for a vulnerable version needs to see every place it appears.
What to say about it
"We run several services from one repository. We generate an SBOM for each deployable service on release and can provide a combined view for the version you run. Shared libraries are listed wherever they are used."
Pitfalls
- Scanning the repo root only. You may capture the workspace tooling and miss what the services actually ship.
- Including test only tools without labeling them. Reviewers may think they are in production.
- Version drift. If the rolled up file is not regenerated with the services, it goes stale quickly.
When a dependency scope shows up in a diff between two SBOMs, it may change a risk assessment; a dev only package that reaches runtime deserves a second look.
Where Safeguard fits
Safeguard can scan multiple repositories and projects, produce SBOMs and keep findings per project. You can test the approach on a single service with the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how components are grouped, and think about which grouping your buyer would find easiest to read.
Quick check
Should every microservice have its own SBOM?
Every deployable unit benefits from one, since each has its own dependencies. You can still offer a combined view for buyers who want a single file.
Can I send only the SBOMs for services the buyer uses?
Often yes, if you state the scope clearly in your cover message so nothing looks hidden.
Sources
Last reviewed: 19 October 2026.
