What is in an SBOM?

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 componentCopy Anchor Link

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 componentsCopy Anchor Link

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 documentCopy Anchor Link

• 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 SBOMCopy Anchor Link

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.

BaselineCopy Anchor Link

Which fields must be filled in at a minimum is described in the SBOM Minimum Elements. Why is SBOM quality important? describes what happens when fields are missing.