Provetry
FRDEGet early access
Free check
Get early access

Provetry opens in November 2026. The free CRA check, the tools and the guides are available now.

What is an SBOM? Meaning, formats, an example and the tools

8 min read

On this page
  1. Why it matters
  2. What an SBOM contains
  3. The two formats: CycloneDX and SPDX
  4. A short example
  5. Kinds of SBOM
  6. How to generate one
  7. An SBOM is a starting point
  8. How Provetry helps
  9. Sources

An SBOM (software bill of materials) is the list of everything a piece of software is made of: each library, framework, runtime and package, with its exact version, who supplies it and how it relates to the rest. Think of it as the ingredients label of a product, written in a format a machine can read.

The idea comes from manufacturing, where a bill of materials lists every part of a physical product. Software is assembled the same way: a typical application written today is mostly open-source components, often hundreds of them once the dependencies of dependencies are counted.

Why it matters

When a serious vulnerability is published in a widely used library, the first question every software maker gets is: are we affected? Without an SBOM, answering means searching repositories, build files and container images by hand, for every product and every version still in use. With one, it is a lookup.

That is why SBOMs have moved from good practice to obligation:

  • In the European Union, the Cyber Resilience Act requires manufacturers to draw up an SBOM for every product with digital elements; see what the CRA asks of an SBOM.
  • In the United States, federal agencies may require one in their software contracts, a practice that started with Executive Order 14028 in 2021 and has been left to each agency since January 2026.
  • Large customers increasingly ask for one in their purchasing terms, whatever the law says.

What an SBOM contains

For each component, a useful SBOM gives:

Field Example
Name express
Version 4.19.2
Supplier the publisher of the component
A unique identifier a package URL (purl) such as pkg:npm/express@4.19.2
A hash a SHA-256 or SHA-512 of the file shipped
Licence MIT
Relationship a direct dependency of the product, or pulled in by another component

And for the SBOM as a whole: which product and release it describes, who produced it, when, and with which tool.

These fields follow the minimum elements first published by the US NTIA in 2021 (supplier, name, version, unique identifier, dependency relationship, author of the SBOM, timestamp). CISA replaced them in 2026 with an updated list that adds, among others, the component hash, the licence, the name of the generating tool and the context in which the SBOM was generated. Germany’s BSI goes further in its technical guideline TR-03183-2, written with the CRA in mind.

The package URL deserves a mention: it is the identifier that lets a tool match a component against vulnerability databases without guessing. An SBOM that only says “openssl 3.0” leaves room for error; pkg:deb/debian/openssl@3.0.11-1~deb12u2 does not.

The two formats: CycloneDX and SPDX

Two open standards dominate, and every serious tool reads both.

CycloneDX started at OWASP in 2017 with security in mind. It is now an Ecma International standard, ECMA-424; its current version, 1.7, is the second edition of that standard. It carries vulnerability and exploitability information (VEX) and also covers services, hardware, machine-learning models and cryptography.

SPDX comes from the Linux Foundation and started with open-source licence compliance. Version 2.2.1 is an ISO standard, ISO/IEC 5962:2021; the current version is 3.0.1, which added profiles for security, AI and datasets.

Which one to choose? If you have no constraint, CycloneDX is the more common choice for security work; SPDX is often what legal teams already use for licences. Both are serialised in JSON (the usual choice) or XML, and converting from one to the other is possible, with some loss of detail. Germany’s BSI accepts CycloneDX 1.6 or later and SPDX 3.0.1 or later.

A short example

Here is a minimal CycloneDX SBOM, in JSON, for a product that depends on one library:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-11-08T09:00:00Z",
    "tools": { "components": [{ "type": "application", "name": "cdxgen" }] },
    "component": { "bom-ref": "gateway", "type": "application", "name": "Gateway", "version": "4.2.0",
      "supplier": { "name": "Acme Devices" } }
  },
  "components": [
    { "bom-ref": "express", "type": "library", "name": "express", "version": "4.19.2",
      "purl": "pkg:npm/express@4.19.2", "licenses": [{ "license": { "id": "MIT" } }] }
  ],
  "dependencies": [{ "ref": "gateway", "dependsOn": ["express"] }]
}

The metadata block describes the product and how the SBOM was made; components lists what is inside; dependencies says how they connect. A real SBOM has the same shape, with hundreds of components. You can open your own in our free SBOM viewer and checker, which also lists the fields that are missing.

Kinds of SBOM

The same product can be described at different moments, and the results differ. CISA names six types:

  • Design: what you plan to use, before code exists.
  • Source: read from the source code and its manifests.
  • Build: produced while the release is built, from what the build actually pulled in. Usually the most accurate for software.
  • Analysed: reconstructed afterwards by scanning a binary or an image.
  • Deployed: what is installed on a given system.
  • Runtime: what is actually loaded while the software runs.

For a maker, a build SBOM for every release is the one that counts: it describes what you ship.

How to generate one

Do not write an SBOM by hand. Generate it in your build pipeline, at every release, from your lock files and the images you ship. Widely used open-source generators include:

  • Syft (Anchore): container images and file systems, many ecosystems.
  • cdxgen (OWASP CycloneDX): source repositories in many languages.
  • Trivy (Aqua Security): images, file systems and repositories, with vulnerability scanning built in.
  • The CycloneDX plugins for Maven, Gradle, npm, .NET, Python and others, which work from inside the build.
  • Microsoft’s sbom-tool, for SPDX.
  • To try it without installing anything: our free SBOM generator turns lock files into CycloneDX or SPDX in your browser, with provetry-core, the open-source engine behind Provetry.

Whatever the tool, check three things in the result: every component has a version and a package URL, transitive dependencies are listed and not only direct ones, and the SBOM names the product and release it belongs to.

The commands and pitfalls of each ecosystem have their own guide: npm, pnpm and Yarn, Python, Java, Rust, Go, .NET and container images.

An SBOM is a starting point

An SBOM on its own does nothing. Its value comes from what you do with it:

  1. Keep one per release, so you can say which versions in the field contain a component.
  2. Match it against vulnerability data every day: new vulnerabilities are published on components you shipped months ago. Prioritise with the EPSS score and the lists of exploited vulnerabilities.
  3. Record your conclusions when a vulnerable component is present but cannot be exploited in your product; that is what a VEX statement is for.
  4. Share it when asked, with customers or authorities. Nothing obliges you to publish it.

How Provetry helps

Provetry builds the SBOM of each release from your CI or from the files you upload, in CycloneDX and SPDX, keeps every release’s SBOM, matches each component against new and exploited vulnerabilities every day, and records your VEX decisions. The free plan covers one product.

Sources