# What is in an SBOM?

The fields that describe each component and the document as a whole

> An SBOM contains information about each component, such as name, version, supplier, identifier, licence and checksum, plus how the components depend on each other and who created the SBOM.

Updated: 5 October 2026  
URL: https://sbom.se/en/sbom/sbom-contents

An SBOM has two parts: information about the document itself, and a list of components with information about each one. The fields have different names in CycloneDX and SPDX, but the content is largely the same.

## Information about each component

| Field             | Example                             | Used for                                                       |
| ----------------- | ----------------------------------- | -------------------------------------------------------------- |
| Name              | `openssl`, `react`, `log4j-core`    | Identifying the component                                      |
| Version           | `3.0.13`, `18.2.0`, `2.14.1`        | Deciding whether a vulnerability applies to this exact version |
| Supplier          | Apache Software Foundation, Red Hat | Knowing who is behind the component                            |
| Unique identifier | `pkg:npm/react@18.2.0` (purl), CPE  | Matching the component against vulnerability databases         |
| Licence           | `MIT`, `Apache-2.0`, `GPL-3.0-only` | Licence checks                                                 |
| Checksum          | SHA-256 of the file                 | Verifying that the component is the one stated                 |

Name and version are not always enough to pin down a component, because the same name can exist in several ecosystems. That is why a unique identifier is needed. The most common is the Package URL (purl), which states ecosystem, name and version in one string.

## Relationships between components

An SBOM also describes how the components depend on each other. A direct dependency is something the application itself uses. A transitive dependency is something that another dependency needs in turn.

The relationships are needed to understand why a component is included, and which update is required to get rid of a vulnerable version.

## Information about the document

* **Who created the SBOM**, and with which tool.
* **The time** it was created.
* **Which product and version** it describes.

## What is normally not in an SBOM

An SBOM lists components, not vulnerabilities. Which vulnerabilities affect a component changes from day to day, while the SBOM for a given version stays the same. Vulnerabilities are therefore worked out by comparing the SBOM against current vulnerability databases.

The assessment of whether a vulnerability actually affects the product is shared in a separate document, [VEX](https://sbom.se/en/vulnerabilities/what-is-vex).

## Baseline

Which fields must be filled in at a minimum is described in the [SBOM Minimum Elements](https://sbom.se/en/sbom/minimum-elements). [Why is SBOM quality important?](https://sbom.se/en/guides/sbom-quality) describes what happens when fields are missing.

## References

- [CycloneDX 1.6](https://cyclonedx.org/docs/1.6/json/): The reference documentation for CycloneDX 1.6 shows how the fields are defined in the format.