rorixrorix
dashboard →
Back to blog
|Rorix Team

CycloneDX or SPDX? Choose the SBOM Your Consumer Can Use

guidesbomcompliance
One dependency graph transformed into two structured software inventories

Teams often begin an SBOM project by asking which format is better. That is usually the wrong first question.

An SBOM is an interface between the team producing software and someone trying to understand it. The useful format is the one your consumer can ingest, validate, and connect to a real workflow.

For .NET teams, the choice commonly comes down to CycloneDX and SPDX. Both can represent a software inventory. Their emphasis—and the systems built around them—differ.

Start With the Consumer

Name who will use the document before deciding how to generate it:

| Consumer | Primary need | Good starting point | | --- | --- | --- | | Security operations | Match components to vulnerabilities and dependency relationships | CycloneDX | | Legal or open-source program office | Review packages, licenses, and provenance | SPDX | | Enterprise customer | Satisfy a contract or procurement questionnaire | The format named in the requirement | | Internal platform team | Feed an asset inventory or policy engine | Whichever format the receiving system parses best |

This is a starting heuristic, not a universal rule. A customer schema or internal ingestion pipeline should beat generic advice every time.

When CycloneDX Fits

CycloneDX is centered on software supply chain and application security use cases. It represents components, package identifiers, dependency relationships, and security-oriented data in a structure that vulnerability tools commonly understand.

Choose it when your next step is likely to be:

  • continuous vulnerability monitoring;
  • dependency graph analysis;
  • application security review;
  • feeding an internal security platform;
  • attaching security context to a release.

Generate it with Rorix:

rorix sbom --format cyclonedx --output sbom.cdx.json

When SPDX Fits

SPDX is a strong choice when the document will move through compliance, legal, procurement, or broader software inventory workflows. It has a detailed model for packages, relationships, licensing, and document provenance.

Choose it when you need to:

  • exchange inventory data with a customer that requests SPDX;
  • support open-source license review;
  • align with an existing governance system built around SPDX;
  • produce an inventory that spans beyond an application-security workflow.

Generate it with Rorix:

rorix sbom --format spdx --output sbom.spdx.json

Generation Is Only the First Control

A valid JSON file is not automatically a useful SBOM. The document should describe the artifact you actually release and include enough identity to distinguish one build from another.

For each release:

  1. Generate the SBOM from the restored or built source revision.
  2. Preserve the commit, version, and build identity with the artifact.
  3. Store the SBOM somewhere consumers can retrieve later.
  4. Validate that the expected direct and transitive components are present.
  5. Test the document in the system that will ingest it.

If the build restores dependencies differently from the developer machine, generating the SBOM before restore can capture an assumption instead of the release.

Do Not Remove the Dependency Graph

A component list answers “what is present?” A dependency graph adds “why is it present?” That second question is crucial during incident response.

When a new advisory lands, the graph helps responders find the top-level package or application that introduced the affected component. Without relationships, the SBOM becomes a search index rather than a remediation map.

You May Need Both

Producing CycloneDX for security operations and SPDX for a customer is not waste if both documents come from the same resolved dependency evidence. The risky version of “both” is maintaining separate manual inventories that drift.

Treat the build graph as the source of truth and render the required exchange formats from it. Rorix supports both formats; see the SBOM format reference and CLI command guide for the available output options.

The success metric is not the number of SBOM files generated. It is whether the intended consumer can answer a real question—quickly and with confidence—when a release is under scrutiny.

Related guides