What Is a Software Bill of Materials (SBOM)? The Complete Guide

01Overview

A Software Bill of Materials (SBOM) is a structured, machine-readable inventory of every component that makes up a piece of software — every open-source library, third-party package, and internal module, along with metadata such as version, supplier, license, and unique identifiers like a Package URL (PURL). It is the software-world equivalent of the ingredient list on packaged food, or the parts list a manufacturer keeps for a physical product.

The reason SBOMs exist is simple: most modern applications are assembled, not written from scratch. A typical service might contain a few thousand lines of code its own team wrote, sitting on top of hundreds of open-source and third-party components pulled in as dependencies. Industry research on open-source usage consistently finds that the large majority of a typical codebase, often cited in the range of 70–90%+, consists of third-party and open-source code rather than code written in-house. Without a structured inventory, most organizations simply don't know, with any precision, what's actually running in production.

An SBOM closes that gap. It gives security teams a way to answer "are we affected by this newly disclosed vulnerability?" in minutes instead of days, gives legal and procurement teams a way to verify license obligations, and gives regulators and customers a way to verify what they're being asked to trust. It is also the foundational artifact behind India's CERT-In software supply chain security guidelines, and the broader xBOM family — CBOM, HBOM, AIBOM and QBOM — extends the same idea to cryptography, hardware, AI systems and quantum-safe components.

02History

The SBOM concept didn't appear overnight — it grew out of two separate movements that eventually converged: open-source license compliance tooling, and software supply chain security in the wake of major breaches.

See the full history of SBOM for a deeper treatment of each milestone.

03Architecture

Regardless of format, every SBOM shares the same conceptual architecture — four layers stacked on top of each other:

1. Document metadata layer — who created this SBOM, with what tool, at what timestamp, and against which specification version. This is what lets a consumer trust the provenance of the SBOM itself.
2. Component inventory layer — the flat list of every component: name, version, supplier, license, and identifiers (PURL, CPE, or a SWID tag).
3. Relationship / dependency graph layer — which components depend on, contain, or are derived from which others. This is what separates a real SBOM from a flat parts list: it distinguishes direct dependencies (the ones your team explicitly chose) from transitive dependencies (the ones pulled in automatically by something else).
4. External references layer — outbound links from a component to things like its source repository, download location, vulnerability advisories, or license text.

NTIA and CISA further classify SBOMs by when in the software development lifecycle they were generated — commonly grouped into six types: Design (from architecture/planning, before code exists), Source (from source code and manifests), Build (generated during compilation, most accurate to what's actually assembled), Analyzed (via binary/composition analysis of an existing artifact), Deployed (the configuration of a live system), and Runtime (what's actually executing, including dynamically loaded components). A Build or Deployed SBOM is generally more trustworthy than a Source SBOM alone, since source manifests can miss what's actually compiled or bundled in.

04Core concepts

Direct vs. transitive dependencies

A direct dependency is one your team deliberately added. A transitive dependency is one pulled in automatically because a direct dependency needs it. Most real-world vulnerability exposure lives in the transitive layer, precisely because it's invisible without tooling.

Component identity

"Name and version" is not a reliable unique identifier — the same name can exist across multiple package ecosystems (npm, PyPI, Maven), and version strings aren't standardized across them. This is why SBOMs rely on identifier schemes like PURL (Package URL) and CPE (Common Platform Enumeration) to unambiguously identify a component.

Composition vs. provenance

An SBOM answers what is in a piece of software. It does not, by itself, answer how it was built or whether the build process can be trusted — that's the job of build provenance and software attestation, which are complementary, not interchangeable, concepts.

SBOM vs. VEX

An SBOM tells you a component is present. It does not tell you whether a known vulnerability in that component is actually exploitable in your specific context — that's what a VEX (Vulnerability Exploitability eXchange) document is for. CERT-In's guidelines explicitly recommend pairing SBOMs with VEX documents for exactly this reason.

05Components of an SBOM

NTIA's 2021 minimum elements define a baseline set of data fields every SBOM should carry per component. CERT-In's October 2024 guidelines build on this baseline and recommend 21 data fields in total, adding fields like criticality and executable/archived status that are relevant to risk triage rather than just inventory record-keeping.

See the full minimum viable SBOM field reference in the Documentation section for a field-by-field breakdown mapped to SPDX and CycloneDX schema properties.

06Standards & formats

Three formats dominate the SBOM landscape today, each with a different origin story that still shapes what it's best suited for.

SPDX

SPDX (Software Package Data Exchange) began in 2010 as a Linux Foundation project focused on standardizing open-source license compliance data. SPDX 2.2.1 was formalized as ISO/IEC 5962:2021, giving it the broadest formal international standing of any SBOM-adjacent format. Its scope has since expanded well beyond software to cover hardware, AI/ML datasets and more, under SPDX 3.0.

CycloneDX

CycloneDX was created in 2017 by OWASP with a security-first design point — vulnerability correlation, dependency analysis, and component integrity — rather than license compliance. It reached its own formal standardization track when v1.6 was ratified as ECMA-424, 1st Edition in June 2024 (v1.7 followed as the 2nd Edition in December 2025). CycloneDX natively supports VEX and VDR documents and has extended into HBOM, SaaSBOM, ML-BOM and CBOM profiles under one specification family.

SWID

SWID (Software Identification) tags, standardized as ISO/IEC 19770-2, predate the modern SBOM movement and focus narrowly on uniquely identifying installed software for asset-management purposes. SWID identifiers are still referenced by NIST's National Vulnerability Database, but SWID is rarely used as a primary SBOM generation format today.

07Examples

A minimal, valid SBOM entry looks similar across formats — here's the same single component, expressed in both CycloneDX and SPDX JSON.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "metadata": {
    "timestamp": "2026-08-16T09:00:00Z",
    "tools": [{ "name": "example-generator", "version": "2.3.0" }]
  },
  "components": [
    {
      "type": "library",
      "name": "requests",
      "version": "2.32.3",
      "purl": "pkg:pypi/requests@2.32.3",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "hashes": [{ "alg": "SHA-256", "content": "70761cfe03c773ceb22aa2f671b4757c58d69f4c" }]
    }
  ]
}

{
  "spdxVersion": "SPDX-2.3",
  "SPDXID": "SPDXRef-DOCUMENT",
  "creationInfo": { "created": "2026-08-16T09:00:00Z", "creators": ["Tool: example-generator-2.3.0"] },
  "packages": [
    {
      "name": "requests",
      "SPDXID": "SPDXRef-Package-requests",
      "versionInfo": "2.32.3",
      "downloadLocation": "https://pypi.org/project/requests/2.32.3/",
      "licenseConcluded": "Apache-2.0",
      "externalRefs": [
        { "referenceCategory": "PACKAGE-MANAGER", "referenceType": "purl", "referenceLocator": "pkg:pypi/requests@2.32.3" }
      ]
    }
  ]
}

Both examples encode the same underlying facts — component identity, version, license, and a PURL for cross-referencing against vulnerability databases — just structured differently. See the full SBOM JSON examples reference for complete, non-abridged documents.

08Diagrams

Two diagrams accompany this guide: the dependency graph in the Architecture section above, and the SBOM lifecycle diagram below, showing where each of the six SBOM types sits relative to the software development lifecycle.

Suggested illustration for future production: an annotated version of Fig. 1 showing a real vulnerability (e.g. a CVE in a transitive dependency) highlighted in red, to visually demonstrate why transitive visibility matters — planned for the transitive dependency risk article.

09Implementation guide

A practical, sequenced path from zero to a working SBOM program:

1. Scope it. Don't try to cover every internal system on day one. If you're in scope for CERT-In's guidelines, start with software supplied to government, public sector or essential-services customers, per the CERT-In SBOM requirements.
2. Choose a format. SPDX or CycloneDX — both are accepted by CERT-In and both have mature tooling. See choosing the right SBOM standard if your organization hasn't picked one yet.
3. Choose a generation method. Source-composition tools (e.g. reading manifests), build-integrated plugins, or container-image scanning each produce different SBOM types. Our SBOM generation tutorials cover Syft, cdxgen and CycloneDX CLI across common ecosystems.
4. Automate it in CI/CD. Manual, one-off SBOM generation goes stale immediately. See CI/CD integration tutorials for GitHub Actions, GitLab CI and Jenkins.
5. Validate the output. Generators disagree on edge cases; validate against the schema before distributing. See validation and conversion tutorials.
6. Store and distribute it. Attach the SBOM to each release artifact and retain it alongside your release history — not in a separate system nobody checks.
7. Feed it into vulnerability monitoring. An SBOM sitting in a folder provides no ongoing value. Connect it to a scanner or SBOM management platform — see scanning tutorials and the vendor-neutral SBOM tools comparison.
8. Set an update cadence. CERT-In's guidelines recommend a separate SBOM per software version, updated when component information changes or when errors in the SBOM are corrected — not on an arbitrary fixed schedule.
9. Prepare for submission, if applicable. If your organization is in CERT-In's scope, see how to prepare an SBOM for CERT-In submission.

10Advantages

11Best practices

• Generate SBOMs automatically in CI/CD, not as a manual pre-release task.
• Prefer Build or Deployed SBOMs over Source-only SBOMs where possible — they reflect what's actually shipped.
• Include transitive dependencies, not just direct ones declared in a manifest.
• Pair every SBOM with a VEX document once you have a vulnerability scanning process in place.
• Validate SBOM output against the format's schema before distribution.
• Version-control SBOMs alongside release artifacts, not in a separate, easily-forgotten system.
• Sign SBOMs where integrity matters — see how to sign an SBOM with Sigstore.
• Standardize on one primary format organization-wide, converting for specific downstream consumers as needed.
• Assign clear ownership — SBOM programs that live solely with security teams, without engineering buy-in, tend to stall.

12Common mistakes

• Generating once and never updating it — an SBOM from six releases ago is actively misleading.
• Relying only on manifest files (e.g. package.json, pom.xml), which can miss what's actually compiled or bundled into the shipped artifact.
• Ignoring transitive dependencies — the majority of real exposure typically sits here, not in direct dependencies.
• Treating SBOM generation as a compliance checkbox rather than an operational security input.
• Skipping validation, and distributing malformed SBOMs that downstream tooling can't reliably parse.
• Assuming an SBOM alone answers "are we vulnerable?" — it answers "what's present," not exploitability; that needs VEX and active scanning.
• Picking a format without checking what your consumers require — CERT-In accepts SPDX or CycloneDX, but a proprietary internal-only format satisfies neither.

13SBOM vs. traditional software inventory

Organizations have tracked software assets for decades through IT asset management (ITAM) systems. An SBOM is a fundamentally different artifact, not just a more detailed spreadsheet.

Read the dedicated SBOM vs. traditional software inventory article for a deeper comparison, including how the two typically coexist during a transition period.

14Frequently asked questions

15References

• CCERT-In — Technical Guidelines on Software Bill of Materials (SBOM)cert-in.org.in · refcode CISG-2024-02 (October 2024)↗
• NNTIA — The Minimum Elements For a Software Bill of Materials (SBOM)ntia.gov (July 2021)↗
• EExecutive Order 14028 — Improving the Nation's Cybersecurityfederalregister.gov (May 2021)↗
• NNTIA — Request for Comment on 2025 Minimum Elements for a Software Bill of Materialsfederalregister.gov (August 2025)↗
• OOWASP CycloneDX specificationcyclonedx.org↗
• SSPDX specificationspdx.dev↗
• EEcma International — CycloneDX (ECMA-424)ecma-international.org↗