# What Is an SBOM? — CycloneDX, SPDX and What a Bill of Materials Is For

Canonical: https://commareports.com/glossary/sbom
Published: 2026-09-11

> An SBOM is a machine-readable inventory of every component in a piece of software. The two formats, what a complete one contains, and why the readable version is the one people ask for.

# 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 `purl`s 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](/share-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](/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 →](https://commareports.com/)**

### Related

- [Share an SBOM report](/share-sbom-report) · [Licence report](/share-license-report) · [Trivy](/share-trivy-report)
- [SARIF](/glossary/sarif) · [Security teams](/for/security-teams)
- [Share a security scan report](/share-security-scan-report) · [Glossary](/glossary)