What Is an SBOM? The Complete Guide to Software Bill of Materials (2026)

What Is an SBOM?

An SBOM (Software Bill of Materials) is a machine-readable inventory of every software component in a product. It lists every library, framework, module, and operating system package that ships inside an application, container image, firmware, or device — along with version numbers, suppliers, licenses, and cryptographic hashes.

The easiest way to understand an SBOM is by analogy: it is a nutrition label for software. Just as food labels list every ingredient and its proportion, an SBOM lists every component and its version. When a new vulnerability is discovered in a library — say, a critical flaw in log4j-core — an SBOM lets you instantly answer the question: "Do we use this library, and if so, where?"Without an SBOM, that question can take hours or days of manual investigation across repositories, container registries, and deployment environments.

The term "Software Bill of Materials" was coined around 2018, borrowing from the manufacturing concept of a bill of materials (BOM) that lists every part in a physical product. The concept gained mainstream attention after the US Executive Order 14028 in May 2021, which mandated SBOMs for all software sold to the federal government. Since then, SBOMs have moved from a niche practice to a fundamental requirement in enterprise software security.

What an SBOM contains

• Component name — the package name as it appears in the package manager (e.g., express, django, openssl)
• Version — the exact version string installed (e.g., 4.18.2, 3.0.13-r0)
• Supplier / Author — who published this component
• License — the open source license (MIT, Apache-2.0, GPL-3.0, etc.)
• Dependency relationships — which components depend on which
• Package URL (PURL) — a standardized identifier like pkg:npm/express@4.18.2
• Cryptographic hashes — SHA-256 or SHA-512 digests to verify integrity
• Timestamp — when the SBOM was generated

What an SBOM does NOT contain

An SBOM is an inventory, not a security assessment. It does not tell you whether any component has known vulnerabilities — that is what vulnerability scanners add. An SBOM says "this application contains lodash 4.17.20." A scanner takes that SBOM and checks OSV, NVD, and vendor advisories to report "lodash 4.17.20 is affected by CVE-2021-23337 (command injection, CVSS 7.2)." The two work together: the SBOM provides the inventory, the scanner provides the risk assessment.

Why SBOMs Matter in 2026

Regulatory requirements are no longer optional

Three major regulations now require or will soon require SBOMs. US Executive Order 14028 applies to all software sold to the federal government. The EU Cyber Resilience Act (CRA) mandates SBOMs for all products with digital elements sold in the European Union, with full enforcement beginning in 2027. The FDA requires SBOMs as part of premarket submissions for medical devices with software components. These are not guidelines — they are legal requirements with enforcement mechanisms.

Supply chain attacks demand visibility

The software supply chain attacks of the last five years have made SBOMs essential. The SolarWinds attack (2020) compromised a build pipeline, injecting malicious code into a legitimate update that was distributed to 18,000 organizations. Log4Shell (CVE-2021-44228) exposed a critical vulnerability in a ubiquitous Java logging library — organizations spent weeks determining which of their systems were affected. The XZ Utils backdoor (CVE-2024-3094) showed how a compromised maintainer could inject a backdoor into a widely-used compression library. In each case, organizations with SBOMs could identify their exposure in minutes rather than days.

Incident response speed

When a new CVE drops with a CVSS 9.8 score and active exploitation in the wild, the first question every security team asks is: "Are we affected?" Without an SBOM, answering this requires manually searching repositories, querying container registries, SSHing into servers, and asking development teams what they use. With an SBOM, it is a database query: SELECT * FROM sbom_components WHERE name = 'vulnerable-lib'. The difference between "we confirmed non-exposure in 3 minutes" and "we confirmed non-exposure in 3 days" is the difference between business as usual and an all-hands incident response.

M&A due diligence and customer requirements

Acquirers now routinely request SBOMs as part of technical due diligence during mergers and acquisitions. An SBOM reveals the true composition of a software product: how many dependencies it carries, whether any have copyleft licenses that conflict with the acquirer's licensing model, and what the vulnerability surface looks like. Enterprise customers are increasingly requiring SBOMs from vendors as a procurement condition — if your competitor provides an SBOM and you do not, you lose the deal.

SBOM Formats Compared: CycloneDX vs SPDX vs Syft vs SWID

Four SBOM formats are in active use. CycloneDX and SPDX dominate, with Syft JSON as a popular tool-specific format and SWID tags declining in relevance. Here is how they compare across the features that matter.

For most security teams, CycloneDX is the recommended choice. It was purpose-built for security workflows, has native VEX support for communicating vulnerability status, and is the most widely supported format in DevSecOps tooling. SPDX is the better choice for legal and compliance teams because of its ISO standardization and deeper license compliance features. For a deeper look at license compliance, see our open source license compliance guide.

CycloneDX JSON example (annotated)

{
  // CycloneDX identifier — tools check this to detect format
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",

  // Unique serial number for this specific SBOM instance
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,

  // Metadata about the software being described
  "metadata": {
    "timestamp": "2026-01-15T10:30:00Z",
    "component": {
      "type": "application",
      "name": "my-web-app",
      "version": "2.4.1"
    }
  },

  // The inventory — every component in the product
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",

      // PURL: universal package identifier
      "purl": "pkg:npm/lodash@4.17.21",

      // License declared by the package author
      "licenses": [{ "license": { "id": "MIT" } }],

      // Integrity verification
      "hashes": [
        { "alg": "SHA-256", "content": "abc123def456..." }
      ]
    },
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ]
}

SPDX JSON example (annotated)

{
  // SPDX version identifier — used by tools to detect format
  "spdxVersion": "SPDX-2.3",

  // SPDX data is licensed under CC0 (public domain)
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "my-python-api",
  "documentNamespace": "https://spdx.org/spdxdocs/example-2026",

  "creationInfo": {
    "created": "2026-01-15T10:30:00Z",
    "creators": ["Tool: syft-0.100.0", "Organization: Acme Corp"]
  },

  // Packages — SPDX's term for components
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-django",
      "name": "Django",
      "versionInfo": "4.2.11",
      "downloadLocation": "https://pypi.org/project/Django/4.2.11/",

      // SPDX's primary focus: license compliance
      "licenseConcluded": "BSD-3-Clause",
      "licenseDeclared": "BSD-3-Clause",
      "copyrightText": "Copyright Django Software Foundation",

      // PURL as an external reference
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:pypi/django@4.2.11"
        }
      ]
    }
  ],

  // Relationships between packages (dependency graph)
  "relationships": [
    {
      "spdxElementId": "SPDXRef-DOCUMENT",
      "relatedSpdxElement": "SPDXRef-Package-django",
      "relationshipType": "DESCRIBES"
    }
  ]
}

How to Generate an SBOM

Several open-source tools can generate SBOMs from container images, source repositories, and build artifacts. Here are the most popular options with actual commands and expected output.

ScanRook

ScanRook generates enriched SBOMs — the component inventory plus vulnerability data from OSV, NVD, and Red Hat OVAL, all in a single pass.

# Generate a CycloneDX SBOM from a container image
scanrook scan --file nginx-1.27.tar --format cyclonedx --out sbom.cdx.json

# Generate an SPDX SBOM
scanrook scan --file nginx-1.27.tar --format spdx --out sbom.spdx.json

# Import an existing SBOM and enrich with vulnerability data
scanrook sbom import --file ./sbom.cdx.json --format json --out enriched-report.json

# Compare two SBOMs to detect supply chain drift
scanrook sbom diff --baseline ./v2.3-sbom.json --current ./v2.4-sbom.json --json

Syft (Anchore)

Syft is the most popular open-source SBOM generator for container images. It detects packages from package managers, language lock files, and binary metadata.

# CycloneDX output from a Docker image
syft nginx:1.27 -o cyclonedx-json > sbom.cdx.json

# SPDX output from a local directory
syft dir:./my-project -o spdx-json > sbom.spdx.json

# Syft's native JSON format (most detailed for Anchore ecosystem)
syft alpine:3.19 -o json > sbom.syft.json

Trivy (Aqua Security)

Trivy can generate SBOMs as part of its multi-purpose scanning. It supports CycloneDX and SPDX output alongside its native vulnerability report format.

# CycloneDX SBOM from a container image
trivy image --format cyclonedx --output sbom.cdx.json nginx:1.27

# SPDX SBOM from a filesystem
trivy fs --format spdx-json --output sbom.spdx.json ./my-project

# Combined: generate SBOM and scan for vulns in one pass
trivy image --format cyclonedx --output sbom.json --scanners vuln nginx:1.27

cdxgen

cdxgen is a source-code-focused SBOM generator that supports over 25 programming languages by analyzing lock files, manifests, and build configs.

# Generate CycloneDX from source code (auto-detects language)
cdxgen -o sbom.json

# Specify output type explicitly
cdxgen -o sbom.json --type node

# Recursive scan of a monorepo
cdxgen -o sbom.json -r --type python ./backend

Tool comparison at a glance

Interactive SBOM Explorer

Paste a CycloneDX or SPDX JSON document to analyze it instantly. The tool parses the SBOM in your browser (nothing is sent to any server), detects the format, and displays the component inventory, license distribution, and component types. Click "Try CycloneDX sample" or "Try SPDX sample" to see it in action.

All processing happens in your browser. No data is transmitted to ScanRook or any third party. For automated scanning and vulnerability enrichment, try uploading a file to ScanRook.

SBOM Diff — Tracking Changes Between Versions

An SBOM diff compares two SBOMs to reveal exactly what changed between software versions. This is one of the most operationally valuable uses of SBOMs because it catches supply chain drift — unexpected additions, removals, or version changes in your dependencies.

Why SBOM diffs matter

• A new dependency was added that introduces a copyleft license, violating your licensing policy
• A critical library was downgraded from a patched version to a vulnerable version
• An unknown package appeared that was not in any package.json or requirements.txt — possible supply chain injection
• A component changed suppliers — the same package name, but from a different publisher

Example: SBOM diff output

$ scanrook sbom diff --baseline v2.3-sbom.json --current v2.4-sbom.json --json

{
  "baseline": "my-web-app v2.3.0 (127 components)",
  "current": "my-web-app v2.4.0 (131 components)",
  "summary": {
    "added": 6,
    "removed": 2,
    "changed": 3,
    "unchanged": 124
  },
  "added": [
    { "name": "sharp", "version": "0.33.2", "license": "Apache-2.0" },
    { "name": "ws", "version": "8.16.0", "license": "MIT" },
    { "name": "color", "version": "4.2.3", "license": "MIT" },
    ...
  ],
  "removed": [
    { "name": "jimp", "version": "0.22.12", "license": "MIT" },
    { "name": "pngjs", "version": "7.0.0", "license": "MIT" }
  ],
  "changed": [
    {
      "name": "express",
      "from": "4.18.2",
      "to": "4.19.2",
      "type": "patch"
    },
    {
      "name": "openssl",
      "from": "3.0.13",
      "to": "3.0.14",
      "type": "patch"
    },
    {
      "name": "lodash",
      "from": "4.17.21",
      "to": "4.17.21",
      "supplier_changed": true,
      "note": "Publisher changed from 'lodash' to 'lodash-es'"
    }
  ]
}

In a CI/CD pipeline, an SBOM diff can serve as a gate: if the diff reveals unexpected new dependencies or license changes, the pipeline fails and the team reviews the changes before deployment. ScanRook's dashboard displays diffs visually with +added / -removed / ~changed counts for each release, making it easy to track supply chain evolution over time.

SBOM + Vulnerability Scanning: How They Work Together

An SBOM by itself is an inventory — it tells you what is present but not whether any of it is vulnerable. Vulnerability scanners take the SBOM as input and check each component against one or more vulnerability databases. The scanner matches each component's PURL (Package URL) or name+version against known advisories and produces a report listing which components are affected and at what severity.

The enrichment pipeline

ScanRook enriches SBOM components against five data sources for maximum coverage and accuracy:

• OSV — ecosystem-native vulnerability matching with exact package name + version range. Covers 24+ ecosystems with minimal false positives.
• NVD CVSS — official CVE severity scores. CVSS base scores from 0.0 to 10.0 provide standardized severity assessment.
• EPSS — Exploit Prediction Scoring System. Predicts the probability that a vulnerability will be exploited in the wild within the next 30 days. A CVE with CVSS 9.8 but EPSS 0.01% is far less urgent than one with CVSS 7.5 and EPSS 97%.
• CISA KEV — the Known Exploited Vulnerabilities catalog. If a CVE is on this list, it is actively being exploited and should be patched immediately.
• Red Hat OVAL — for RPM-based distributions (RHEL, Rocky, Alma), OVAL definitions check the full NEVRA (Name-Epoch:Version-Release.Architecture) to account for backported patches.

The result is that every component in the SBOM gets a comprehensive vulnerability assessment — not just "this CVE exists" but "this CVE exists, has a CVSS of 9.1, EPSS predicts 34% exploit probability in 30 days, it is on the CISA KEV list, and the installed RPM version does not include Red Hat's backported fix."

Regulatory Requirements: Who Requires SBOMs and What They Must Contain

US Executive Order 14028 (May 2021)

Executive Order 14028, "Improving the Nation's Cybersecurity," directs federal agencies to require SBOMs from all software vendors. Section 4(e) specifically mandates that vendors provide an SBOM for each product. The order applies to all "critical software" used by the federal government, which includes operating systems, web browsers, cloud services, identity management tools, and security software. NIST was directed to publish guidelines for SBOM content, which became the NTIA Minimum Elements.

EU Cyber Resilience Act (CRA)

The CRA applies to all products with digital elements placed on the EU market. Article 13 requires manufacturers to "identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials." The CRA takes full effect in 2027, with vulnerability reporting obligations starting 21 months after entry into force. Unlike EO 14028, which applies only to federal procurement, the CRA applies to all commercial software sold in the EU.

FDA Cybersecurity Guidance

The FDA's "Cybersecurity in Medical Devices" guidance (effective October 2023) requires medical device manufacturers to include SBOMs in premarket submissions. The SBOM must list all software components including commercial, open source, and off-the-shelf software. The FDA specifically requires SBOMs for devices that contain software or connect to networks — which includes virtually all modern medical devices from insulin pumps to MRI machines.

NTIA Minimum Elements for an SBOM

The National Telecommunications and Information Administration (NTIA) published the minimum data fields that every SBOM must contain, regardless of format:

CISA SBOM Sharing Recommendations

CISA recommends several practices for SBOM distribution: make SBOMs available at a well-known URL (/.well-known/sbom), sign them with a verifiable signature (Sigstore cosign), update them with every release, and provide machine-readable access (not just PDF downloads). CISA also recommends that organizations consuming SBOMs store them in a centralized repository and correlate them with their asset inventory.

The SBOM Lifecycle: From Source Code to Dashboard

SBOMs fit into a larger workflow that connects build systems, vulnerability scanners, and security dashboards. Here is the full lifecycle:

The SBOM is generated during the build phase and stored alongside the artifact. The vulnerability scanner reads the SBOM, checks each component against multiple data sources, and produces an enriched report that feeds into dashboards and CI/CD gates. This pipeline runs automatically on every build, ensuring that vulnerability data is always current.

Frequently Asked Questions about SBOMs

Further Reading

• cyclonedx.org — Official CycloneDX specification and tools
• spdx.dev — SPDX specification, license list, and tooling
• NTIA SBOM Resources — NTIA minimum elements and sharing guidelines
• CISA SBOM Guidance — Federal guidance on SBOM creation and consumption
• EU Cyber Resilience Act — Full text of the CRA regulation
• github.com/anchore/syft — Syft SBOM generation tool

Related ScanRook articles