One SBOM or many for a monorepo? A decision guide

Generate one SBOM per deliverable, not one per repository. A monorepo often builds several services, libraries and images, each with different dependencies. A single repo wide SBOM overstates what any one customer receives and hides what is really inside each artifact.

Start from what you deliver

An SBOM describes a piece of software someone runs or receives. So draw the boundary around that thing.

• A container image has one SBOM.
• A deployable service has one SBOM.
• A library you publish has one SBOM per release.
• A desktop or mobile app build has one SBOM per release.

The repository is just where the source lives. A repo with twelve services and a shared library should produce at least twelve SBOMs.

Why a repo wide SBOM misleads

1. Overstatement. It lists dependencies of services the customer never receives, which creates noise in their scanner and wasted questions for you.
2. Understatement of specifics. It cannot say which version of a library went into which release.
3. Wrong scope for vulnerability triage. A finding in a package used only by an internal tool is reported as if it affected the public product.
4. No release link. Customers need an SBOM tied to the version they run.

When one combined view helps

An internal, repo wide inventory is useful for your own security team. It answers questions like which packages the organization uses at all, or which services use a package that was just reported as malicious. Keep it, but label it internal and do not send it as a product SBOM.

How to decide, step by step

1. List the deliverables the repo produces.
2. For each, identify the build step that creates it.
3. Generate the SBOM at or near that step, from the final artifact if you can. A lockfile alone misses OS packages in images and files copied in during the build.
4. Name the SBOM with the product, version and build identifier.
5. Store it with the artifact, so they travel together.
6. Merge into an internal catalog for organization wide search.

Shared code

Shared internal libraries make this harder. Treat a shared library as a component with its own version, and have each service SBOM list it as a dependency. If the library is vendored or referenced by path, make sure the SBOM still records which commit or version was used.

Keeping them current

Regenerate on every release build, not once a quarter. Make the SBOM a build output, checked in your pipeline, and fail the release when it is missing. Run vulnerability matching against the stored SBOMs when new advisories appear, so you can answer exposure questions without rebuilding.

Common mistakes

• Generating from the root manifest only, which misses package level dependencies in sub projects.
• Reusing one SBOM across releases.
• Dropping the SBOM from the release bundle.
• Leaving out dev tooling that actually ships in the artifact.

Safeguard generates SBOMs and scans dependencies per project and can enforce policies in the pipeline. The free scan at https://gold.safeguard.sh/scan is a quick way to see what one project's SBOM looks like.

Quick check

Last reviewed: 19 October 2026.