Ask a build system for an SBOM and it will happily give you one — for that repository, or that container image. Useful, but not quite the thing the CRA asks about. The regulation cares about the product your customer receives, and that product is almost never a single repo.
The product is the unit
The CRA's obligations — the SBOM, the vulnerability handling, the reporting, the technical file — all attach to the product with digital elements placed on the market. That product might be assembled from a dozen repositories, several microservices, a handful of container images and some vendored firmware. The unit of compliance is the whole, not any one part.
Why a stack of per-repo SBOMs falls short
Per-component SBOMs are the right raw material, but on their own they don't answer the question that matters: what is in the thing we shipped? A few concrete gaps:
- No single view. "Which of our products contains this newly-exploited library?" requires one inventory per product, not twelve to cross-reference by hand.
- Double-counting and gaps. Shared dependencies appear in several repos; components that only exist in the assembled artifact (base images, bundled binaries) appear in none.
- Wrong granularity for VEX. A
not_affectedor a report is about the product, so the SBOM it's reasoned against has to be the product's.
How to assemble one
The mechanics are a merge, done as part of shipping rather than by hand:
- Generate component SBOMs for each part in CI — per repo, per image, per service — with Syft, Trivy or cdxgen.
- Merge them into a single SBOM keyed to the product and version, deduplicating shared components while preserving where each one came from.
- Capture what only exists in the assembly — base-image packages, bundled artifacts — by scanning the final built product, not just its sources.
- Regenerate per release, timestamped and stored immutably, so the application-level SBOM tracks what you actually shipped each time.
This aggregation — turning many component inventories into one product inventory — is the part of the SBOM layer that takes real engineering, and it's where a good platform earns its place over raw open-source generators.
Containers, services and monorepos
- Containers. Scan the built image, not just the app repo — the base image and OS packages are components you ship and are answerable for.
- Microservices. If they're released together as one product, aggregate them; if they're separately-placed products, each gets its own application-level SBOM.
- Monorepos. One repo can produce several products; the boundary is what's placed on the market as a unit, not the repository layout.
Once you have one SBOM per product, the rest of the CRA pipeline — correlation, evidence-backed VEX, reporting — has the right unit to work on. The full SBOM picture is in the SBOM pillar.
Frequently asked
What is an application-level SBOM?
A single software bill of materials describing all the components of the product a customer receives, aggregated across every repository, service, container and build artifact that makes it up — rather than one SBOM per repo or image.
Why does the CRA need an application-level SBOM?
The CRA’s obligations attach to the product placed on the market, so the inventory has to describe that product as a whole. A pile of per-repository SBOMs doesn’t answer “what is in the thing we shipped” without being aggregated first.
How do I build an application-level SBOM?
Generate component SBOMs for each part (repo, image, service) in CI, then merge them into one product SBOM keyed to the product and version, deduplicating shared dependencies and preserving where each came from. Do it per release so it stays current.