What is an SBOM? Contents, types and how to use one

A software bill of materials (SBOM) is a machine-readable inventory of the components that make up a piece of software: each library, package or module, with its version, supplier, identifiers, license and its relationships to the others. Like a manufacturer's bill of materials for a physical product, it lets you answer what is inside without taking the product apart. Its value comes from what you do with it: find affected software within minutes when a vulnerability is announced, check licenses on every change, and show customers and auditors what you ship.

This page goes deeper on the SBOM section of What is software supply chain security?.

What goes in an SBOM

In 2021 the US National Telecommunications and Information Administration (NTIA) published the minimum elements for an SBOM. They fall into three groups.

Data fields for each component: supplier name, component name, version, other unique identifiers, the dependency relationship, the author of the SBOM data, and a timestamp.

Automation support: the SBOM is in a machine-readable format that tools can generate and consume. The NTIA named SPDX, CycloneDX and SWID tags.

Practices and processes: when to produce an SBOM (with each new build or release), how deep it goes (at least the top-level components, with enough detail to find transitive ones), how to record "known unknowns" where the dependency tree is incomplete, how it is distributed and who may access it, and how mistakes are corrected.

Most generators add more than the minimum: license data, file hashes, the tool that produced the SBOM, and sometimes vulnerability references.

Component identifiers

An SBOM is only as useful as its identifiers. "openssl, version 3" is hard to match against anything; a precise identifier can be matched against vulnerability databases and license lists automatically.

• Package URL (purl). A string that names a package within its ecosystem, such as pkg:npm/[email protected] or pkg:pypi/[email protected]. Widely used by open source tooling.
• CPE (Common Platform Enumeration). A naming scheme used by the US National Vulnerability Database to say which products a vulnerability affects.
• Hashes. Cryptographic hashes of files or packages, which identify an exact artifact regardless of its name.

A component with a purl and a hash can be matched reliably. A component with only a name and a version often cannot.

What an SBOM looks like

A minimal CycloneDX SBOM in JSON, trimmed to one application and one dependency:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-21T09:30:00Z",
    "component": { "type": "application", "name": "checkout", "version": "2.4.0", "bom-ref": "checkout" }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/[email protected]",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/[email protected]",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ],
  "dependencies": [{ "ref": "checkout", "dependsOn": ["pkg:npm/[email protected]"] }]
}

The metadata block describes what the SBOM is about and when it was made. Each entry in components is one component with its identifiers and license. The dependencies block records which component depends on which, so the tree can be rebuilt. SPDX records the same information with different structure and names. For a comparison of the two formats, see CycloneDX vs SPDX.

SBOM types: when in the lifecycle it was made

An SBOM made from a design document says something different from one made from a running container. A 2023 CISA document, Types of Software Bill of Material (SBOM) Documents, names six types:

For vulnerability response and license checks, a build SBOM is usually the most useful starting point: it reflects resolved versions, including transitive dependencies, for an artifact you actually shipped.

How SBOMs are generated

SBOMs are produced by tools, not written by hand. Generators read lockfiles and manifests, inspect built artifacts or container images, or hook into the build itself. Open source examples include Syft, Trivy and cdxgen, and many build ecosystems have their own plugins.

To get an SBOM you can rely on:

• Generate it in CI, from the build. That ties it to an artifact and a commit, and removes the step people forget.
• Use resolved versions. A manifest with version ranges says what is allowed; a lockfile or built artifact says what was used.
• Include transitive dependencies, and record where the tree is incomplete.
• Store it with the release, with a hash, so you can retrieve the SBOM for what was running at a given time.
• Check it. Open a few SBOMs and confirm the components, versions and licenses look right. A generator configured for the wrong directory produces an SBOM that is valid and almost empty.

Using an SBOM

• Vulnerability response. Match component identifiers against advisories. When a new vulnerability is announced, search your stored SBOMs instead of every repository.
• License compliance. Sum the licenses across components and compare them with your policy, on every change rather than only at release.
• Inventory and end-of-life tracking. Find components that are unmaintained or past their support date.
• Customer and regulatory requests. In the US, Executive Order 14028 pushed SBOMs into federal software purchasing. In the EU, the Cyber Resilience Act requires manufacturers of products with digital elements to draw up an SBOM, covering at least top-level dependencies, as part of their technical documentation.

SBOMs and VEX

An SBOM says what is present. A vulnerability scanner matching it against advisories will flag every component with a known vulnerability, including ones where the vulnerable code is never called. VEX (Vulnerability Exploitability eXchange) records the supplier's assessment of each case, using statuses such as not affected, affected, fixed and under investigation, with a justification for "not affected", for example that the vulnerable code is not present or cannot be reached.

VEX can be published in CycloneDX, in the CSAF format or as OpenVEX documents. Together, an SBOM and VEX statements let a customer tell which scanner results need action.

How AI CodeOps does it

AI CodeOps tracks SBOMs per project, in CycloneDX or SPDX format. It does not generate them: you create the SBOM with your usual tool, keep the file with your build artifacts, and record a snapshot with its format, commit, hash, download link, component count and license summary. In the open beta a snapshot is recorded with a request to /api/sbom from a signed-in session; recording one from CI with an API key is not available yet.

The release check your CI calls can deny a change when the project's latest SBOM contains a license you have disallowed, and denies it when a license rule is set and the project has no SBOM. SBOMs appear under Secure → Security and on each project's page.

See Security and SBOM for the details, the SBOM glossary entry, and the free SBOM viewer, which opens a CycloneDX JSON file in your browser without uploading it.