What is SBOM?

What SBOM is

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component inside a piece of software. It lists every open-source library, third-party dependency, framework, and module, along with version numbers, licenses, and supplier information.

The concept borrows from manufacturing. A car manufacturer knows every part in every vehicle: the steel grade, the chip supplier, the tire model. If a part is recalled, the manufacturer knows exactly which vehicles are affected. Software has lacked this transparency for decades. When the Log4Shell vulnerability hit in December 2021, most organizations could not answer a basic question: “Do we use Log4j, and where?”

An SBOM answers that question definitively. If you have an accurate, up-to-date SBOM for every application, you can query it in minutes and know exactly which applications, services, and deployments contain a vulnerable component.

Modern software is mostly assembled, not written from scratch. Studies consistently show that 70 to 90 percent of the code in a typical application comes from open-source libraries and third-party components. An SBOM makes that invisible majority visible.

Why SBOM matters

SBOMs have moved from a nice-to-have to a regulatory requirement. Three forces are driving adoption:

Supply chain attacks are increasing. The SolarWinds compromise, the Codecov breach, the ua-parser-js malware incident, and the XZ Utils backdoor all exploited the trust organizations place in their software supply chain. An SBOM does not prevent these attacks, but it dramatically reduces response time when one hits.

Regulations now require it. The U.S. Executive Order 14028, the EU Cyber Resilience Act, and FDA medical device guidance all mandate SBOM generation and sharing in specific contexts. Organizations selling software to the U.S. federal government or the EU market cannot ignore this.

Vulnerability management depends on it. Without knowing what components you use, you cannot know what vulnerabilities affect you. SCA tools work by comparing your dependency list against vulnerability databases. An SBOM is the standardized, shareable version of that dependency list.

The practical benefit is speed. When the next critical vulnerability drops, organizations with SBOMs measure their response time in hours. Organizations without them measure it in weeks.

SBOM formats

Two formats dominate the SBOM landscape. Both are accepted by U.S. and EU regulators, and both are machine-readable.

CycloneDX

CycloneDX is an OWASP-maintained standard designed with security as its primary focus. The current version is 1.7, released in October 2025.

Strengths:

• Native support for VEX (Vulnerability Exploitability eXchange), which lets you communicate whether a vulnerability actually affects your product
• Supports multiple BOM types: SBOM, SaaSBOM, HBOM (hardware), AI/ML-BOM, and CBOM (cryptographic)
• Available in JSON, XML, and Protocol Buffers
• Tight integration with security tooling and vulnerability databases
• Provenance tracking via citations (added in 1.7)

SPDX

SPDX (Software Package Data Exchange) is a Linux Foundation standard that originated in the open-source licensing and compliance space. Version 3.0 expanded its scope to include security use cases.

Strengths:

• Deepest support for license compliance tracking
• ISO/IEC 5962:2021 international standard
• Broad adoption in legal and procurement workflows
• Mature tooling ecosystem, especially for license review

Format comparison

If your primary use case is security and vulnerability management, CycloneDX is the stronger choice. If you need license compliance tracking for legal review, SPDX has deeper support. Many organizations generate both: CycloneDX for their security team and SPDX for their legal team.

Regulations and mandates

Several regulations now require or strongly encourage SBOM generation:

U.S. Executive Order 14028 (2021). Requires SBOM submission for any software sold to U.S. federal agencies. SBOMs must be machine-readable (CycloneDX or SPDX), traceable, and kept current through software updates. NIST published minimum elements guidance that defines what an SBOM must contain.

EU Cyber Resilience Act (CRA). Applies to manufacturers of digital products sold in the EU. Requires an up-to-date, machine-readable SBOM as part of technical documentation, available for audit by market surveillance authorities. Vulnerability and incident reporting requirements take effect September 2026. Full SBOM requirements take effect December 2027.

FDA medical device guidance. Since October 2023, the FDA requires an SBOM as part of premarket submissions for medical devices. All software components must be disclosed, including open-source libraries and their versions.

NIS2 Directive. The EU’s updated Network and Information Security Directive encourages SBOM adoption for essential and important entities as part of supply chain risk management.

PCI DSS 4.0. While not explicitly mandating SBOMs, PCI DSS 4.0 requires organizations to maintain an inventory of custom and third-party software, which SBOMs directly support.

The regulatory trend is clear: SBOM will become a baseline requirement across industries. Starting now avoids a scramble later.

How to generate an SBOM

Generating an SBOM is not a one-time activity. It should be automated as part of your CI/CD pipeline.

Step 1: Choose your format. CycloneDX for security-focused workflows, SPDX for compliance-focused workflows, or both if you need to serve multiple stakeholders.

Step 2: Integrate into your build. Add SBOM generation as a build step in your CI/CD pipeline. Tools like Syft, Trivy, and the CycloneDX Maven/Gradle/NPM plugins generate SBOMs directly from your project’s dependency manifest (package.json, pom.xml, go.mod, requirements.txt, etc.).

Step 3: Include transitive dependencies. Ensure your tool resolves the full dependency tree, not just direct dependencies. Most vulnerabilities hide in transitive dependencies.

Step 4: Store and version SBOMs. Treat SBOMs as release artifacts. Store them alongside build outputs in your artifact repository. Version them with each release so you can trace any deployed version back to its component list.

Step 5: Monitor continuously. New vulnerabilities are disclosed daily. An SBOM generated last month is already stale from a vulnerability perspective. Use an SCA tool or SBOM management platform to continuously scan your stored SBOMs against updated vulnerability databases.

SBOM tools

Several tools generate, manage, and analyze SBOMs:

Generation tools:

Management and analysis platforms:

• Anchore — Enterprise SBOM management with policy enforcement, continuous monitoring, and compliance reporting. Anchore Enterprise builds on the open-source Syft and Grype tools.

• Chainguard — Provides hardened container images with built-in SBOMs and minimal attack surface. Their images ship with SBOM attestations, making compliance straightforward for containerized workloads.

• Snyk Open Source — SCA tool that identifies vulnerable dependencies and can generate CycloneDX SBOMs. Strong developer workflow integration with IDE, CLI, and CI/CD support.

• FOSSA — License compliance and SBOM platform. Particularly strong for organizations that need to track open-source license obligations alongside security vulnerabilities.

FAQ

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 129 AppSec tools across 10 categories on AppSec Santa. Learn more.