What is an SBOM? A practical guide to software bills of materials

What is an SBOM?

A software bill of materials (SBOM) is a formal, machine-readable list of the components that make up a piece of software. Think of it as the ingredient list on food packaging: it does not tell you whether the product is safe, but without it you cannot answer questions about what is inside.

For a typical application, the SBOM lists every open-source and third-party package it ships, the exact version of each, a unique identifier such as a package URL (purl), the license, who supplied it, and how components depend on one another. Because most of a modern application's code comes from dependencies, and most of those dependencies are transitive (pulled in by other packages rather than chosen by you), the SBOM is usually the first place you see how much third-party code you actually ship.

Why SBOMs matter now

SBOMs moved from good practice to a common requirement after a run of supply-chain incidents, Log4Shell in particular, showed how long it took organisations to answer "do we use this?"

• Incident response. When a critical vulnerability is published, an up-to-date SBOM per release turns a week of searching into a query.
• Customer and procurement requests. Enterprise buyers increasingly ask suppliers for SBOMs during security review, alongside questionnaires.
• Government requirements. US Executive Order 14028 (2021) set SBOM expectations for software sold to the federal government, and the NTIA published the minimum elements an SBOM should contain. The EU Cyber Resilience Act requires manufacturers of products with digital elements to keep an SBOM as part of their technical documentation, with the main obligations applying from December 2027.
• License compliance. The same inventory shows which licenses you ship, before a copyleft package reaches a product that cannot accept it.

What goes into an SBOM

The NTIA's minimum elements are a good baseline. Every component entry should carry:

Useful SBOMs go further: licenses for each component, hashes so a consumer can verify they have the same artifact, whether each dependency is direct or transitive, and references to known vulnerabilities at the time of generation.

SPDX vs CycloneDX

Two formats cover almost every SBOM in use. Both are open, both describe components and relationships, and good tooling reads and writes both.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": { "timestamp": "2026-11-03T09:00:00Z" },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.2",
      "name": "log4j-core",
      "version": "2.17.2",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.2",
      "licenses": [{ "license": { "id": "Apache-2.0" } }]
    }
  ]
}

If you also ship AI features, the same idea extends to models, prompts, agents and MCP servers. That is an AI bill of materials; see What is an AI-BOM?.

How to generate a useful SBOM

Generating some SBOM is easy. Generating one you can rely on takes a few rules:

1. Generate from lockfiles or the built artifact, not from loose manifests. A package.json with version ranges says what could be installed; package-lock.json says what was installed. Without a lockfile, transitive versions are guesses.
2. Generate per release, automatically, in CI, and store the SBOM with the release artifact. An SBOM that someone produced by hand last quarter describes software you no longer ship.
3. Cover every layer you ship. Application dependencies and the operating-system packages in your container base image are both components.
4. Use real identifiers. Package URLs and hashes let consumers match components to advisories without guessing.
5. Do not invent data. Missing supplier or license information should be marked as unknown, not filled in with a plausible guess.

An SBOM is not a vulnerability report

The most common misunderstanding: sending an SBOM does not tell anyone which vulnerabilities matter. It tells them what you ship. Turning that into decisions takes two more steps:

• Vulnerability matching. Software composition analysis (SCA) matches each component version against advisory data, and should be re-run as new advisories appear even when the SBOM has not changed. Prioritise matches by exploit signal (the CISA Known Exploited Vulnerabilities catalog, then EPSS exploit probability, then reachability) rather than severity alone.
• VEX (Vulnerability Exploitability eXchange). A VEX statement records your assessment of a vulnerability in a product: affected, not affected (with a justification such as "the vulnerable code is not present"), fixed, or under investigation. It stops customers chasing a CVE in a component you do not actually use in a vulnerable way.

For the difference between scanning dependencies and scanning your own code, see SAST vs SCA.

SBOM checklist

Generating SBOMs with CodeStax

CodeStax's SCA builds the dependency inventory from supported manifests and lockfiles on every scan (npm, pip, Maven, Gradle, Go modules, Cargo, Composer, RubyGems and NuGet), then lets you export it as an SBOM. Each component carries its name, version and package URL, SPDX license identifiers, CVE references and whether it is a direct or transitive dependency. CycloneDX export is included on the Free plan; SPDX export is available on Growth and above. Vulnerabilities are prioritised by KEV and EPSS alongside CVSS, and VEX workflows record your assessments.