One SBOM per product version, assembled from what actually shipped.
A product is dozens of components, each with its own repository, pipeline and SBOM. The customer asks for one SBOM for the version they received. Stitching it together by hand means guessing which component versions went into that release.
Component releases arrive from CI
Every pipeline run creates a component release in ReARM and attaches the SBOMs it produced. Nothing to collect later: the SBOMs are recorded at build time, against the exact version they describe.
↳ SBOM/XBOM ManagementProducts are assembled by rules
A product's feature set defines which component branches belong to it. Rules decide when a new component release rolls into a new product release, automatically or after approval. No one maintains a version matrix by hand.
↳ Feature SetsEvery product release is pinned
Each product release records the exact component releases it contains. Ask ReARM what went into product version 3.2.1 and the answer is a list of pinned versions, not a best guess from dates.
↳ Feature SetsAggregated SBOM on demand
For any product release, ReARM merges the component SBOMs into one product SBOM: one document that covers everything shipped in that version, ready to hand to a customer, a regulator or a scanner.
↳ SBOM/XBOM ManagementDelivered with the product
Aggregated SBOMs are ready to be served downstream, so each customer can receive the SBOM for each version they run.
↳ DistributionFindings follow the aggregate
New vulnerabilities are evaluated against every component pinned in every shipped product version, so a finding in one library maps straight to the product versions and customers it affects.
↳ Findings Aggregation