SBOM generation for monorepos: CycloneDX vs SPDX compared.

the · format · question

The format question is downstream, not abstract.

Both standards describe a build — CycloneDX is the depth-of-fields-instrumented one, SPDX is the ISO-backed one. The question is not which is better; the question is which one the downstream tooling ingests. A regulator that asks for SPDX at audit time wants an SBOM it can re-enact on its own tooling; a SecOps reviewer that asks for CycloneDX wants supplier, PURL, and license-expression fields per package on a per-PR cadence. Pick the format that fits what is downstream; emit both only when the audit pull is two-sided. /docs/compliance lists the formats a regulated monorepo ships per merged PR, with the field-level vocabulary the SOC 2 Type II / PCI-DSS scope-of-work reads.

cyclonedx · strengths · monorepo

CycloneDX strengths in a monorepo. Depth per package, SBOM delta by design.

A CycloneDX SBOM gives you per-package fields — PURL, SPDX license expression, supplier, content hashes, and the cryptographic hash that ties the field back to the lockfile. The SBOM diff the same run emits versus the previous PR on the same branch is a depth-of-fields diff, not a flat list; the regulator replays it by run id and reads the package-by-package delta. An FOSSA or Anchore pipeline that ingests CycloneDX handles a per-PR SBOM diff without translation, and a downstream license-anomaly detection surface can route anomalies to the right reviewer per package. /docs/compliance lists the per-PR SBOM fields on the CycloneDX-side, with the field shapes and the verifier commands a security reviewer runs verbatim. /security tracks the same per-PR row under the audit-trail heading, with the key-custody column the SBOM signer writes.

spdx · strengths · cross · tooling

SPDX strengths. ISO standard, cross-tooling coverage, regulator playbooks.

SPDX is the ISO-backed format, and — depending on the regulator — the one a SOC 2 / PCI / FedRAMP-style evidence binder reads first. The cross-tooling coverage is broader than CycloneDX (grok, reuse compliance tooling, and several open-source scanners favour SPDX), and the format is what a regulator can re-enact on its own tooling without translation. The catch is that SPDX does not have the per-package depth CycloneDX gives — a transitively-scoped vulnerability is harder to route to a single reviewer, and the SBOM delta per PR is harder to emit. The handled-link bridge — a CycloneDX document that lands as an SPDX handled-link — closes that gap, and /docs/compliance walks the bridge with the verifier commands a reviewer can run.

pick · criterion · downstream

The pick criterion is downstream. Decide on what is downstream, not what is upstream.

The pick criterion is downstream. If the regulator or the auditor asks for SPDX, emit SPDX primary; if a SecOps pipeline asks for the per-package fields on a per-PR cadence, emit CycloneDX primary. Most regulated monorepos end up emitting CycloneDX primary with an SPDX handled-link bridge, because they want both the downstream depth and the cross-tooling coverage. The /architecture page footer enumerates the audit-trail column shapes and the SBOM delta field shapes the shipping engine produces, in the same vocabulary a SOC 2 Type II scope-of-work reads. The pair — CycloneDX primary + SPDX handled-link bridge — is the practical split a regulator and a SecOps reviewer both accept at audit time.

• CycloneDX primary is per-PREvery dependency-touching PR carries a CycloneDX SBOM, cosign-signed, hash-bound to the lockfile. FOSSA / Anchore / in-house pipelines ingest without translation.
• SPDX handled-link bridge is the auditor pullThe same document lands as an SPDX handled-link for tooling that prefers SPDX over CycloneDX. The audit-trail row stays the same row, on the same run id.
• Depth fields drive routingper-package PURL + SPDX license expression + supplier + content hash — the fields a SecOps reviewer routes by, and the originating inputs the regulator replays.
• Per-PR SBOM delta, not quarterly batchCycloneDX delta per PR lands next to the lockfile diff on the PR. Off-tree packages are rejected at ingest; license change is routed as an anomaly tagged on the row.

where · driftlock · lands

Where Driftlock lands on this. CycloneDX 1.5 plus cosign signature per PR.

Driftlock emits CycloneDX 1.5 on every dependency-touching PR, signed with the customer KMS-resident key, hash-bound to the lockfile that produced the diff. The same document lands as an SPDX handled-link bridge for the tooling that prefers SPDX over CycloneDX. /architecture walks the SBOM-delta step in the pipeline, with the field shapes and the verifier commands a reviewer runs verbatim. /security tracks the key custody posture — KMS-managed by default, HSM-backed on the Enterprise tier — with the same vocabulary the audit-trail row uses. The closing pair closes the audit-trail bar: a per-PR row a regulator can replay, a signature over the commit that survives a key rotation, and an SBOM document a downstream compliance tool can ingest.

• CycloneDX 1.5 on every dep-touching PRJSON + XML, hashed against the lockfile, cosign-signed in your KMS. The next-run delta lives next to the lockfile diff on the PR.
• SPDX handled-link bridgeSame document, second-surface, for tooling that prefers SPDX over CycloneDX. Audit-trail row stays same row, on the same run id.
• Off-tree packages rejected at ingestA package in the SBOM not in the lockfile is a flag — not silent reverification. The regulator replays the row, not the pipeline.
• License anomalies routed per packageA permissive → source-available change routes to the right reviewer per package. The anomaly lands on the row, not as a buried feed event.