Orchestrating multiple SBOMs

A product composed of twelve services, three different base images, and two vendor-purchased components easily produces twenty or thirty SBOM documents for each release. The Cyber Resilience Act¹, however, asks for one: the unit of evidence is the product placed on the market, not the repository nor the single build.

It is the gap between how pipelines work and how the regulator thinks. SBOM generation is a solved problem: Syft², Trivy³, and registry-integrated scanners produce CycloneDX or SPDX in a few seconds. What is missing, in most setups we have seen, is composition: an authoritative document per product version that holds together component SBOMs without flattening them into a monolithic file. This article addresses that problem: how to link, sign, and maintain over time a product bill of materials in multi-service architectures.

Why do SBOMs multiply in a multi-service product?

Multiplication is not a configuration flaw: it is a structural property of cloud-native architectures. It operates along three axes that combine by multiplication, not addition:

1. Services and repositories: each service with its own release cycle generates its own documents, and each monorepo with multiple publishable artifacts behaves as N distinct sources.
2. Type along the lifecycle: CISA taxonomy⁴ distinguishes Design, Source, Build, Analyzed, Deployed, and Runtime SBOMs. These are different views of the same software, not copies.
3. Origin of components: first-party code, base images with their OS packages, language runtimes, firmware, third-party components delivered by vendors.

A Source SBOM and a Build SBOM for the same service are not redundant. The former describes what is declared in manifests and lock-files; the latter describes what actually entered the shipped artifact. Generating only from source yields both false positives (declared dependencies that are never compiled) and blind spots: system libraries in the base image, static binaries linked during build, vendorized modules. The first case inflates triage, while the second makes it incomplete right where risk is most opaque.

The recurring failure mode has a recognizable shape. Folders of CI artifacts with limited retention, a spreadsheet tracking which merge is the most recent, no document that anyone is willing to declare authoritative for the release on the market. This SBOM sprawl carries a cost that manifests at the exact worst moment: upon the appearance of an actively exploited vulnerability, the team does not answer the question “which product version contains the affected component and in which service”, but the much poorer question “where is the right file”.

The probability of that question arising is not remote. The 2024 OSSRA report shows 91% of examined repositories containing components that are ten versions or more behind⁵: in a product with ten services, the presence of at least one outdated and potentially affected component is the normal condition, not the exception. Granular visibility into dependencies is the prerequisite for everything else, a point we already covered when analyzing how the Software Bill of Materials makes third-party risks traceable under the CRA.

Technically, the regulation asks for four things, and it is best to read them as specifications. The SBOM must be machine-readable: JSON or XML in CycloneDX or SPDX format⁶, whereas a PDF attached to documentation does not satisfy the obligation. The common format is not prescribed. The legal minimum, set by Annex I, Part II of the CRA, is first-level dependencies, but in cloud native, transitive dependencies are the core of the risk, making the legal minimum a floor, not a goal. Above all: a representation of dependency and containment relationships is required, not a flat list of names.

The SBOM is part of the technical documentation defined in Annex VII of the CRA¹: it is not proactively transmitted, but must exist when placed on the market and be producible upon reasoned request from a market surveillance authority. Deadlines set the context: September 11, 2026 for vulnerability reporting obligations, December 11, 2027 for full application.

Compose or merge: which strategy holds up in a product audit?

Both approaches are compliant. The CRA does not impose an aggregation mechanism; it mandates the existence of a machine-readable document representing the product with its dependency relationships. The choice between merging and linking is therefore an engineering decision, and must be justified by the informational costs it entails.

What you lose when you merge everything into one file

Flat merge has a paradox at its core: deduplication. In build tools, eliminating duplicates is good practice; in supply chain analysis, deduplicating components from N documents erases the only necessary information: which service uses which version. Names remain, the map disappears.

• Triage changes nature: from a query on the graph (“which components of product 3.4 depend on libX < 2.9, and in which service?”) to a text search followed by manual verification service by service. This is where MTTR expands, not in writing the patch.

• Lifecycles are decoupled: a merged document is a snapshot that ages upon the first independent deployment of a single service, and every regeneration requires rebuilding the entire file.

• Provenance is lost: hashes and signatures of original documents do not survive merging, so integrity is verifiable only on the aggregate.

Merging remains the correct choice under precise conditions: a substantially monolithic product, a few dozen components, a single release cadence, or an SBOM consumer that cannot resolve external references. In those cases, it produces an autonomous, verifiable artifact with less surrounding infrastructure.

Hierarchical compose: a root BOM that references, not copies

The structure is simple: one product document per version, whose application-type components represent services, each with an external reference to its own SBOM. In CycloneDX, the mechanism is the externalReference of type bom carrying a BOM-Link⁷ in the form urn:cdx:<serialNumber>/<version>, capable of pointing to an entire document or to a single bom-ref within it. In SPDX, the equivalent is achieved using the ExternalDocumentRef pair plus Relationship (DESCRIBES, CONTAINS, DEPENDS_ON).

The resulting properties are those that merging cannot offer: independent regeneration per service, integrity verifiable document by document with separate checksums and signatures, preserved provenance, and manageable file sizes even with hundreds of components per service. It follows the same logic as the hierarchical assembly of a manufacturing bill of materials, where the product level references sub-assemblies instead of listing every single screw.

The constraint, which must be declared: reference resolution is the consumer’s responsibility. If the root BOM points to unresolvable URNs or expired artifacts in a registry with a thirty-day retention policy, the evidence breaks and the document becomes an unfulfilled promise. Composition therefore requires immutable, addressable storage for component SBOMs, with the same retention as the product. Evaluating this type of architectural trade-off, where a format choice becomes an infrastructure requirement, is territory we systematized in our guide to defense models for cloud-native architectures.

The diagram: how to read a root BOM

The edges carry references, not copied content: the root BOM remains the sole authoritative document for the release, and each leaf retains its own signature. The side node is the least obvious point: the vendor SBOM does not enter as an opaque link to a third-party URL, because in that case evidence would depend on the availability of an endpoint we do not control. It must be reconciled first, as explained below.

How do you build the product SBOM inside the pipeline?

Every choice here must be anchored to a requirement: it is generated from the artifact because evidence must reflect what was shipped, identifiers are normalized because component tracking demands it, and it is signed because the integrity of preserved evidence is part of the technical documentation.

Generate from the built artifact, not from source

Operational rule: the Build SBOM is generated from the OCI image or binary produced by the pipeline, and compared with lock-files and source code to detect discrepancies. Where tooling cannot infer (such as static binaries, firmware, or vendorized dependencies), manual records that are tracked and dated are added.

# syft 1.x, trivy 0.5x - use digest, not tag
IMAGE="registry.example.com/checkout-service@sha256:9f2a...c41d"
DIGEST="9f2a...c41d"

# primary generator: CycloneDX JSON output to versioned file per service and digest
syft "$IMAGE" -o cyclonedx-json="sbom/checkout-service-${DIGEST}.cdx.json"

# second scanner on the same artifact, to compare component sets
trivy image --format cyclonedx \
  --output "sbom/checkout-service-${DIGEST}.trivy.cdx.json" "$IMAGE"

Honest note: two generators on the same artifact do not produce identical sets. Syft and Trivy typically diverge on statically compiled binaries and packages installed outside package managers. The delta is not a bug; it is information about analyzer coverage. It should be recorded alongside the SBOM, and certainly not hidden by choosing the tool that returns fewer lines.

Normalize component identity before composing

Composition only works if a component is consistently identifiable across documents generated by different tools at different times. The minimum fields, consistent with CISA minimum elements⁸ and BSI TR-03183 technical guidelines⁹, are:

• component name and exact version;

• vendor or author;

• Package URL (purl)¹⁰, or CPE¹¹ where purl is not applicable;

• artifact hash (SHA-256);

• relationship with the parent component.

The problem is concrete: the same package appears as openssl among OS packages, as libssl3 with the distribution name, and as an embedded dependency of a Go binary. Without a normalized purl, a product triage query returns three distinct entities, making the response to authorities or customers incomplete despite being formally produced. Normalization must be executed in the pipeline as a deterministic, versioned step, never manually during an audit.

Assemble, sign, publish

The product release job constructs the root BOM with metadata.component set to the product and version, application components for each service, and external references to already published SBOMs.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:8f7c1c1e-6a3e-4c0b-9e1a-2d5b7f0a11c4",
  "version": 1,
  "metadata": {
    "component": {
      "bom-ref": "prod-retail-3.4.0",
      "type": "application",
      "name": "retail-platform",
      "version": "3.4.0"
    }
  },
  "components": [
    {
      "bom-ref": "svc-checkout-2.11.3",
      "type": "application",
      "name": "checkout-service",
      "version": "2.11.3",
      "externalReferences": [
        {
          "type": "bom",
          "url": "urn:cdx:3e671687-395b-41f5-a30f-a58921a69b79/1"
        }
      ]
    }
  ],
  "dependencies": [
    { "ref": "prod-retail-3.4.0", "dependsOn": ["svc-checkout-2.11.3"] },
    { "ref": "svc-checkout-2.11.3", "dependsOn": [] }
  ]
}

When the consumer cannot resolve references, the alternative path is a hierarchical merge, which at least preserves component nesting:

# cyclonedx-cli 0.32.x - hierarchical merge, preserves assembly structure.
# Merges only canonical, normalized SBOMs from product services.
# One per service: not the raw glob, which would include both Syft
# and Trivy outputs for the same artifact.
cyclonedx merge --hierarchical \
  --input-files \
    sbom/canonical/api-gateway.cdx.json \
    sbom/canonical/checkout-service.cdx.json \
    sbom/canonical/frontend.cdx.json \
  --name retail-platform --version 3.4.0 \
  --output-file product-3.4.0.cdx.json

# cosign 2.x - keyless signing via OIDC, verifiable bundle alongside the document
cosign sign-blob --yes product-3.4.0.cdx.json \
  --bundle product-3.4.0.cdx.json.bundle

Automating these steps within CI/CD, with scanning and signing (for example via Cosign¹²) as native steps rather than optional jobs, is the part of DevSecOps work that we described when discussing tooling and pipeline integration in the cloud. The signed SBOM then goes into immutable storage, and the reference to the file enters the technical documentation of the release along with the tool name, version, and generation date.

Vendor SBOMs, missing information, and evidence lifecycle

Two failure modes remain open even in well-automated setups: documents arriving from third parties and maintaining evidence over time.

Vendor SBOMs are inputs, not the finished artifact

The scenario is recurring. One vendor delivers CycloneDX, a second SPDX, a third a PDF with a list of libraries; the release folder contains three links to three different portals. That is vendor material, not a product record, and in the event of a reasoned request, it fails to answer which version of our product contains the affected component.

Reconciliation follows a precise sequence:

1. convert or normalize identity fields (purl, version, hash) into the internally used schema;
2. integrate components into the product bill of materials, or link them via BOM-Link after verifying that the reference is resolvable and persistent;
3. retain original upstream documents as supporting evidence, noting receipt date and channel;
4. explicitly record what could not be determined.

The fourth point distinguishes defensible documentation from deficient documentation. When a vendor fails to deliver a complete SBOM, the component is not omitted: known unknowns are documented, namely contractual and purchasing evidence, verifiable fields gathered independently by scanning received binaries, hashes and version proof, plus an explicit note on what cannot be determined. A declared absence is evidence; a silent absence is non-compliance.

The implications of this chain of responsibility regarding third-party components and upstream dependencies represent a topic that European regulation shifted from the community onto those who place products on the market, and reconciliation is where that responsibility becomes operational.

How often to regenerate and how long to retain

Regeneration responds to triggers, not a calendar: changes in software or firmware versions, patch releases, changes in vulnerability exploitability status resulting in a VEX (Vulnerability Exploitability eXchange) update, additions, removals, or replacements of components, significant design modifications, or changes in applied standards. Periodic schedules remain useful as a safety net: quarterly reviews of SBOMs and vulnerability status, annual reviews of technical documentation, and a freeze before the end of the support period.

Here composition shows its strongest argument. Triggers are local to the service, so a single document is regenerated and the root BOM is reissued upon product release; in merging, every local trigger requires rebuilding the entire document, risking unwanted deltas on components nobody touched.

Regarding retention, the obligation is long-term, mandated by Article 13 of the CRA¹: at least ten years from placement on the market, or the entire support period if longer, starting from the last unit placed. This excludes CI as a storage location.

For example, if the registry is Google Artifact Registry¹³, the reference service for software composition is Artifact Analysis, which supports SBOM generation and management for archived artifacts alongside vulnerability scanning¹⁴: a solid starting point, but not a compliance archive. Repository default retention and cleanup policies do not align with a ten-year obligation, and must be configured or supplemented with dedicated storage.

To manage this complexity long term, infrastructure must evolve beyond simple file saving. It is worth evaluating specific tooling for document fetching, storage, and transformation, such as Bomctl¹⁵, alongside a graph query layer like GUAC¹⁶ to answer triage queries in a timely manner.

Final point, often overlooked: the SBOM is confidential technical documentation, not public material. It is a component map useful to anyone seeking an entry point. Release to market surveillance authorities occurs upon reasoned request (in Italy, the reference role belongs to ACN), and to business customers under NDA, tracking who received which version and when. International convergence on these principles is documented in the joint guidance A Shared Vision of Software Bill of Materials for Cybersecurity¹⁷ published in September 2025 by CISA, NSA, and nineteen partners.

Operational lessons

The decision rule fits in two lines: if the product has more than one independent release cycle, hierarchical compose is the only maintainable strategy; below that threshold, merging costs less and easily passes an audit.

Three things we would do differently, based on our experience with multi-service pipelines:

1. Treat component SBOM storage as a long-term artifact from day one, not as CI output with default retention. Recovering expired documents after six months means regenerating them from images that no longer exist.
2. Normalize identifiers in the pipeline before volume makes the operation retroactive. At three hundred documents, retroactive normalization becomes a project, not a step.
3. Measure orchestration quality with a single, timed question: how long does it take, starting from a CVE, to list affected product versions and impacted services? If the answer is measured in hours, the evidence architecture is failing, regardless of formal document compliance.

One issue remains open and must be stated: consumer maturity in resolving BOM-Links is still uneven, making this the strongest argument against pure composition today. A defensible strategy maintains the linked root BOM as the authoritative source while being able to produce a flattened view on demand as a derived export, never as the reference document.

The next and final article in the series covers observability (logs, metrics, and traces) as the technical foundation for meeting notification and reporting obligations under CRA and NIS2.

We work on these topics daily in our software supply chain security practice, and as members of OpenSSF¹⁸, CNCF, and LF Europe, we contribute to defining tools that make this evidence verifiable rather than merely declared.

Need a discussion, an audit, or dedicated consulting on security, DevSecOps, or CRA compliance? Contact our experts.

Notes and sources