What is a software bill of materials?
A software bill of materials (SBOM) is a machine-readable inventory of every component, library, and dependency in a software application, along with version numbers, licenses, and supplier information. It's the nutrition label for software, telling you what is inside so you can assess risk, track vulnerabilities, and meet compliance requirements.
Here is what a real SBOM looks like in practice, as a CycloneDX JSON snippet:
{
"bomFormat": "CycloneDX", // Identifies this as a CycloneDX SBOM
"specVersion": "1.6", // CycloneDX spec version in use
"version": 1, // Document version (increment on re-generation)
"metadata": {
"timestamp": "2026-06-18T12:00:00Z", // When this SBOM was generated
"component": {
"type": "application",
"bom-ref": "my-web-app", // Unique ref so other sections can point at this component
"name": "my-web-app", // The application this SBOM describes
"version": "2.1.0"
}
},
"components": [ // Full inventory of dependencies (direct + transitive)
{
"type": "library",
"bom-ref": "pkg:npm/express@4.21.0", // Using the purl as the bom-ref keeps it unique
"name": "express",
"version": "4.21.0",
"purl": "pkg:npm/express@4.21.0", // Package URL — canonical identifier for this package
"licenses": [
{ "license": { "id": "MIT" } } // SPDX license ID
]
},
{
"type": "library",
"bom-ref": "pkg:npm/lodash@4.17.21",
"name": "lodash",
"version": "4.17.21",
"purl": "pkg:npm/lodash@4.17.21",
"licenses": [
{ "license": { "id": "MIT" } }
]
},
{
// Transitive dependency of express — must be declared here, not just in `dependencies`
"type": "library",
"bom-ref": "pkg:npm/body-parser@1.20.3",
"name": "body-parser",
"version": "1.20.3",
"purl": "pkg:npm/body-parser@1.20.3"
},
{
"type": "library",
"bom-ref": "pkg:npm/cookie@0.7.1",
"name": "cookie",
"version": "0.7.1",
"purl": "pkg:npm/cookie@0.7.1"
},
{
"type": "library",
"bom-ref": "pkg:npm/debug@4.3.7",
"name": "debug",
"version": "4.3.7",
"purl": "pkg:npm/debug@4.3.7"
}
],
"dependencies": [ // The dependency graph — who depends on whom
{
"ref": "my-web-app", // Must match a bom-ref above, not a bare name
"dependsOn": [
"pkg:npm/express@4.21.0", // Direct dependency
"pkg:npm/lodash@4.17.21" // Direct dependency
]
},
{
"ref": "pkg:npm/express@4.21.0",
"dependsOn": [
"pkg:npm/body-parser@1.20.3", // Transitive dependency, pulled in by express
"pkg:npm/cookie@0.7.1",
"pkg:npm/debug@4.3.7"
]
}
]
}
This snippet shows the core structure: metadata identifying the application, a component inventory with versions, package URLs (PURLs), and license data, plus a dependency tree that maps how components relate to each other.
Why SBOMs matter for supply chain security
Open-source and third-party code makes up most of a modern application. Endor Labs estimates that open-source components account for up to 90% of a typical codebase. A single enterprise application that declares 30 direct dependencies can resolve to 300 or more transitive components once you trace the full dependency tree. Yet most organizations still cannot answer a straightforward question: what is running in production?
That is the problem a softwarebill of materials helps solve. Borrowing from manufacturing, automakers track each vehicle part and issue targeted recalls.
An SBOM does the same. It provides a formal, machine-readable record of all software components. It also records their supply chain relationships. The NTIA describes it as a nested inventory of software, a list of the ingredients that make up software components.
An SBOM lists direct dependencies (packages in your project) and transitive dependencies (packages your dependencies rely on). This distinction matters because transitive dependencies are where most risk hides. The 2024 OSSRA report found that 81% of audited codebases had at least one known open-source vulnerability. Developers did not choose most of the responsible components.
The practical value is speed. When the Log4j vulnerability surfaced in December 2021, organizations with SBOMs identified their exposure within hours. Organizations without them launched manual audits across repositories, containers, and deployments. CISA reported that the process took some teams weeks.
Two incidents that turned SBOMs into an operational necessity
In 2020, attackers compromised the SolarWinds Orion build pipeline and distributed backdoored updates to about 18,000 organizations, including U.S. government agencies. The core challenge in the aftermath was not just remediation but identification: affected organizations lacked component inventories and had no fast way to determine their exposure.
In 2021, researchers found a critical remote code execution vulnerability (CVE-2021-44228) in Apache Log4j, a logging library embedded in hundreds of millions of devices. Security teams across the industry spent weeks answering a question an SBOM would have resolved in minutes: do we use this library, and if so, which version?
These incidents sped up a regulatory response that keeps building momentum:
- U.S. Executive Order 14028 (May 2021): Mandates SBOMs for software sold to the federal government. This was the single largest catalyst for enterprise adoption.
- NTIA minimum elements (July 2021): Defines the baseline data fields every document must contain: supplier name, component name, version, unique identifiers, dependency relationships, author, and timestamp.
- CISA guidance (2024): Introduces maturity tiers: minimum expected, recommended, and aspirational.
- EU Cyber Resilience Act (2024, enforcement around 2027): Requires SBOMs for products with digital elements sold in the EU, which affects any software vendor with European customers.
- FDA: Requires SBOMs for medical device premarket submissions.
Requirements are expanding from federal procurement into regulated industries and private-sector contracts, a trajectory that keeps gaining speed as EU enforcement ramps toward 2027. For the broader picture, see our guide to software supply chain security.
SBOM formats explained
Two dominant formats both produce valid documents, but differ in governance, design philosophy, and ideal use cases. The choice matters because it determines tooling compatibility, regulatory acceptance, and how well your SBOMs fit existing security workflows.
SPDX
The Linux Foundation governs SPDX (Software Package Data Exchange), which holds ISO/IEC 5962:2021 international standard status, the only format with formal ISO certification. SPDX began as an open-source license compliance format and has expanded to cover security use cases. The current stable version is SPDX 2.3, with SPDX 3.0 available. It supports multiple output formats: tag-value, JSON, XML, RDF, and YAML.
SPDX is the strongest choice when your primary driver is license compliance, regulatory submissions that require ISO certification, or government procurement where ISO standardization carries weight.
CycloneDX
The OWASP Foundation governs CycloneDX. The project took a security-first approach from the start. The current version is CycloneDX 1.6. Its distinguishing feature is native VEX (Vulnerability Exploitability eXchange) support, the ability to flag which known vulnerabilities an attacker can exploit in a specific deployment context, inside the SBOM itself.
CycloneDX also supports multiple BOM types beyond software: SaaSBOM, HBOM (hardware), OBOM (operations), and MLBOM (machine learning). Output formats include JSON, XML, and Protocol Buffers.
CycloneDX fits application security teams focused on vulnerability management and DevSecOps workflows.
Format comparison
A third standard, SWID tags (ISO/IEC 19770-2), exists for software asset management and installed software identification. Few teams use it for SBOM purposes.
Most mature organizations need to support both SPDX and CycloneDX. Your customers, regulators, and partners may each prefer a different format, and your SBOM tooling should handle both without manual conversion.
How to generate an SBOM
SBOM generation falls into three approaches, each with its own accuracy and coverage trade-offs.
Build-time generation produces the most accurate SBOMs. By hooking into the build process, these tools capture the exact resolved dependency tree, including every transitive dependency, as the build compiles and packages the software. This is the gold standard for SBOM accuracy.
Source analysis parses manifest files (package.json, pom.xml, go.mod) to derive a component list. It is fast and low-friction, but it can miss unresolved or dynamically loaded dependencies, the components that appear once the build system resolves the full dependency graph.
Binary and container analysis scans compiled artifacts or container images. This approach catches components that manifests do not declare (vendored libraries, statically linked code), but it can lack version precision.
The practical recommendation: use build-time generation as your primary method and supplement with binary analysis for container deployments. Automate SBOM generation in your CI/CD pipeline so every production deployment produces an updated, monitored SBOM.
With Endor Labs, generating an SBOM from your build graph is a single CLI command:
endorctl sbom export --format cyclonedx --output my-app-sbom.json
This produces a CycloneDX SBOM with full transitive dependency resolution. The endorctl
reference covers configuration options including SPDX output and VEX document generation.
The harder problem is not generating SBOMs. It is managing them at scale. Generating SBOMs across hundreds of repositories and keeping them current as dependencies change is where most organizations hit operational friction. This is where centralized SBOM management earns its keep.
Endor Labs SBOM Hub provides a single system of record for SBOM ingestion, standardization, and continuous risk monitoring, supporting both CycloneDX and SPDX across your entire portfolio. For help choosing a tool, see our breakdown of the best SBOM tools in 2026.
What a good SBOM contains
The gap between a checkbox SBOM and a useful one is wide. It separates compliance theater from real supply chain visibility.
The baseline: NTIA minimum elements
The NTIA minimum elements report defines seven required data fields:
- Supplier name: the entity that created or distributes the component
- Component name: the designated name the supplier assigned
- Version: the version identifier
- Unique identifiers: Package URL (PURL) or CPE for precise identification
- Dependency relationships: how components relate to each other
- Author of SBOM data: who generated the document
- Timestamp: when it was created
Beyond minimum: CISA recommended practices
CISA's maturity framework recommends additional data beyond the baseline:
- Cryptographic hash of each component
- License information
- Known unknowns: components the tool could not identify (acknowledging gaps beats pretending they do not exist)
- Lifecycle phase: whether the SBOM came from source, build, analysis, or a deployed artifact
Useful versus checkbox SBOMs
Four attributes separate bills of material that improve your security posture from those that satisfy an audit requirement and nothing more:
- Depth: Includes transitive dependencies, not just top-level packages.
- Accuracy: Generated from actual build resolution, not just manifest parsing. Build-time reflects what the build compiles into your application.
- Timeliness: Updated with every release, not a one-time snapshot. A stale SBOM provides a false sense of transparency.
- Actionability: Paired with vulnerability data and reachability analysis. Knowing you have a vulnerable component is step one. Knowing whether an attacker can reach and exploit that vulnerability in your context is what enables prioritization, and it is where most programs stall.
The inventory matters only when it is accurate, current, and connected to the vulnerability intelligence and risk context that makes it actionable.
FAQ
SPDX vs CycloneDX: what are the key differences? The Linux Foundation governs SPDX, an ISO-standardized format that began with license compliance and expanded to cover security. The OWASP Foundation backs CycloneDX, a security-first format with built-in VEX support for flagging vulnerability exploitability.
Both produce valid SBOMs. Choose SPDX when your primary driver is license compliance or regulatory submissions that require ISO certification. Choose CycloneDX when your focus is security operations and vulnerability management. Most organizations end up supporting both.
What are the legal and regulatory requirements for SBOMs? In the U.S., Executive Order 14028 makes SBOMs mandatory for software sold to the federal government.
The FDA requires them for medical device premarket submissions. The EU Cyber Resilience Act will require SBOMs for products with digital elements sold in the EU, with full enforcement expected around 2027. No blanket mandate covers all private-sector software yet, but adoption keeps rising as enterprise customers and regulated industries add requirements to procurement contracts.
How often should you update an SBOM? Generate a new one with every software release or significant dependency update. Treat it as a living document to avoid a false sense of transparency. Automating SBOM generation in your CI/CD pipeline is the most reliable way to keep them current without adding manual overhead.
What is VEX in this context? Vulnerability Exploitability eXchange (VEX) is a companion document that communicates which known vulnerabilities in SBOM components an attacker can exploit in a specific deployment context.
An SBOM tells you what components are in your software. A VEX document tells you which vulnerabilities in those components matter. Together they provide both the inventory and the risk assessment, the combination that enables prioritization instead of alert fatigue.
SBOM vs SCA: how do they relate? Software Composition Analysis(SCA) is a process. It identifies open-source components and their associated vulnerabilities.
An SBOM is the output artifact, the inventory itself. SCA tools often generate SBOMs as part of their analysis pipeline, but you can also generate an SBOM on its own. Think of SCA as the scanner and the SBOM as the report it produces.
The takeaway
SBOMs are no longer optional for organizations building or procuring software at scale. The regulatory direction is clear, the operational benefits are concrete, and the tooling has matured to the point where automated SBOM generation and management is a solved problem, not a research project. The organizations that treat SBOMs as a living, monitored asset, rather than a one-time compliance artifact, are the ones that can respond to the next Log4j-scale disclosure in minutes instead of weeks.
Three practical steps to move forward:
- Audit your current state. Can you produce an accurate, complete SBOM for every application in production today? If not, that is where to start.
- Automate generation in CI/CD. Build-time SBOMs generated on every deployment are the minimum viable standard. One-time or quarterly SBOMs go stale before anyone reviews them.
- Centralize management and monitoring. Generating SBOMs is the easy part. The harder problem is keeping them current, correlating them with vulnerability intelligence, and surfacing actionable risk across your entire portfolio.
Endor Labs SBOM Hub handles the full SBOM lifecycle, from generation and ingestion through continuous monitoring and risk enrichment, across both CycloneDX and SPDX formats. Book a demo to see Endor's SBOM Hub in practice.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help: