A Software Bill of Materials is a machine-readable inventory of every component in a piece of software — direct and transitive dependencies, with versions, licences and, ideally, cryptographic identifiers. It is the document that answers 'are we affected by this CVE' in minutes instead of days.

What is the difference between CycloneDX and SPDX?

Both are standards for the same job. CycloneDX, from OWASP, is security-first and compact, and is the common default in vulnerability tooling. SPDX, a Linux Foundation and ISO/IEC 5962 standard, originated in licence compliance and carries richer legal metadata. Most generators emit either.

Why publish an SBOM as a readable report?

Because the people who ask for one — auditors, procurement, enterprise security reviewers, customers under a contractual clause — are not going to parse JSON. They need a dated, citable document listing components, versions and licences, at a URL they can open without access to your repository.

SBOM

A Software Bill of Materials is a machine-readable inventory of every component in a piece of software — direct and transitive dependencies, with versions, licences and cryptographic identifiers. It is what turns "are we affected by this CVE?" from a week of archaeology into a query.

Adoption accelerated after US Executive Order 14028 made SBOMs a requirement for software sold to federal agencies; the EU Cyber Resilience Act has pushed the same expectation into commercial contracts.

The two formats

	CycloneDX	SPDX
Steward	OWASP	Linux Foundation, ISO/IEC 5962
Origin	Security use cases	Licence compliance
Strength	Compact, VEX support, vulnerability tooling defaults to it	Rich legal metadata, deep licence expressions
Serialisations	JSON, XML	JSON, YAML, tag-value, RDF

Both describe the same thing. If the requester has no preference, CycloneDX JSON is the path of least resistance; if the request came from a legal or procurement team, they probably want SPDX.

What a usable one contains

Components — name, version, and a package URL (purl) or CPE so a scanner can match it to advisories unambiguously.
Dependency relationships — not just a flat list. "Which of our packages pulls in this" is the question during an incident.
Licences — per component, with expressions, not a single guessed string.
Hashes — so the inventory can be verified against what shipped.
Metadata — what produced it, when, and for which build.

An SBOM without purls and without relationships is a text file that looks like compliance.

Generators

Syft, Trivy, cdxgen, the CycloneDX build plugins (Maven, Gradle, npm, pip, Cargo), Docker Scout, and GitHub's dependency graph export. Most container scanners emit one as a side effect (share an SBOM report).

The readable version is the one people ask for

The JSON is for scanners. The request almost never comes from a scanner:

An enterprise security review blocking a deal.
An auditor needing a dated artifact for the evidence file.
A customer exercising a contractual clause.
Your own incident response, at 2am, reading rather than querying.

None of those want a 4 MB JSON document. They want a table of components, versions and licences, dated, at a URL they can open without access to your repository — and stable enough to cite in the audit report they are writing.

Publishing the rendered report to a permanent link gives them that, and lets a reviewer comment on a specific component — "this GPL transitive came in with the PDF library, replacement tracked in PLAT-441" — next to the row it concerns (comment on HTML). Keep it on a restricted access setting.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish an SBOM report →

Share an SBOM report · Licence report · Trivy
SARIF · Security teams
Share a security scan report · Glossary