Demystifying SBOMs: The Backbone of Modern Software Security

When the Log4Shell vulnerability (CVE-2021-44228) was disclosed in December 2021, organizations around the world scrambled to answer a simple question: does our software use Log4j? For most, the answer took days or weeks of manual investigation across thousands of applications. For the few that maintained Software Bills of Materials, the answer took seconds.

An SBOM (Software Bill of Materials) is a machine-readable inventory of every component in a piece of software — every library, framework, and transitive dependency, along with version numbers, suppliers, and relationships. Think of it as a nutritional label for software: it tells you exactly what is inside. And just as food labels transformed public health by making ingredients transparent, SBOMs are transforming software security by making the software supply chain visible.

What Is Inside an SBOM?

A well-formed SBOM contains structured information about each component in your software:

• Component name and version — The specific library or package and its exact version (e.g., log4j-core 2.14.1)
• Supplier — Who authored or published the component
• Package URL (purl) — A universal identifier for the component (e.g., pkg:maven/org.apache.logging.log4j/[email protected])
• Dependency relationships — How components relate to each other (direct dependency, transitive dependency, dev dependency)
• Licenses — The license terms governing each component
• Hashes — Cryptographic digests for integrity verification

This information enables automated tooling to match components against vulnerability databases, verify license compliance, and detect supply chain anomalies.

SBOM Formats

Three formats dominate the SBOM landscape. For a detailed comparison, see our SBOM formats guide.

SPDX (Software Package Data Exchange)

SPDX is maintained by the Linux Foundation and is an ISO/IEC 5962 international standard. Originally designed for license compliance, SPDX has evolved to support security use cases with SPDX 3.0’s security profile. It supports JSON, XML, RDF, tag-value, and YAML serialization formats.

CycloneDX

CycloneDX is maintained by OWASP and was designed from the start for security and supply chain use cases. It supports JSON and XML, and has specialized capabilities including vulnerability disclosure (VEX), cryptographic BOMs (CBOM), and service dependency mapping. CycloneDX is an ECMA standard (ECMA-424).

SWID Tags

SWID (Software Identification) Tags are an ISO/IEC 19770-2 standard primarily used for identifying installed software in enterprise asset management. SWID tags are less common in the development-focused SBOM ecosystem but are referenced in some government procurement requirements.

For most organizations, the choice is between SPDX and CycloneDX. Both are mature, well-tooled, and accepted by regulatory frameworks. Many organizations generate both.

How SBOMs Are Generated

SBOMs can be generated at different points in the software lifecycle, with trade-offs in accuracy and completeness.

Build-Time Generation

The most accurate SBOMs are generated during the build process, when the full dependency tree has been resolved and lock files are available. Build-time tools include:

• sbomify GitHub Action — A multi-ecosystem SBOM generator that automatically selects the best generation tool for your stack, enriches the output with package metadata, and optionally augments it with business information
• Syft — Generates SBOMs from container images, file systems, and archives in both SPDX and CycloneDX formats
• Trivy — Aqua Security’s scanner that generates SBOMs alongside vulnerability reports
• CycloneDX CLI tools — Language-specific plugins for npm, Maven, Gradle, pip, Go, and more

Analysis-Time Generation

Post-hoc tools analyze compiled binaries or container images to infer components. These are useful when source code or build systems are not available but may miss components that are statically linked or vendored without metadata.

The Accuracy Problem

An SBOM is only as useful as it is accurate. Lock file drift — where the dependency manifest and lock file fall out of sync — is one of the most common causes of inaccurate SBOMs. If your lock file doesn’t reflect what’s actually installed, neither will your SBOM.

Why SBOMs Matter

Rapid Vulnerability Response

The primary security value of an SBOM is speed. When a new CVE is disclosed — especially one confirmed as actively exploited in the CISA KEV catalog — you need to know immediately whether your software is affected. Without an SBOM, this means manually investigating each application’s dependencies. With an SBOM, you query a database and get the answer in seconds.

This is not a hypothetical benefit. During Log4Shell, organizations with SBOMs identified affected applications within hours. Those without SBOMs spent weeks.

Continuous Monitoring

SBOMs enable continuous vulnerability monitoring, not just point-in-time audits. By ingesting SBOMs into a management platform like sbomify or OWASP Dependency-Track, you can automatically cross-reference your components against vulnerability databases (like Google OSV) as new vulnerabilities are disclosed. For details on building this pipeline, see our guide on SBOM scanning for vulnerability detection.

Supply Chain Visibility

Modern software is overwhelmingly composed of third-party code. Studies consistently show that 70-90% of a typical application consists of open-source components. An SBOM makes this composition visible, enabling informed decisions about which dependencies to adopt, which to replace, and which pose unacceptable risk. For more on the role of SBOMs in cybersecurity, see our dedicated guide.

Compliance

SBOMs are increasingly required — not just recommended — by regulators and procurement frameworks:

• Executive Order 14028 requires SBOMs for software sold to the U.S. federal government
• EU Cyber Resilience Act requires manufacturers of products with digital elements to document components and dependencies
• FDA requires SBOMs for pre-market submissions of medical device software
• CISA minimum elements define what an SBOM must contain to be useful for cross-organizational sharing
• NIST SP 800-161 recommends SBOMs as part of supply chain risk management

SBOMs in Practice: The Lifecycle

Generating an SBOM is not a one-time event. SBOMs are most valuable when treated as living documents managed throughout the software lifecycle.

1. Generate — Produce SBOMs as part of your CI/CD pipeline, at every build
2. Sign — Wrap SBOMs in in-toto attestations signed via Sigstore for integrity and provenance
3. Store — Ingest SBOMs into a management platform (sbomify) for centralized visibility
4. Monitor — Continuously scan SBOMs against vulnerability databases as new CVEs are published
5. Share — Provide SBOMs to customers, regulators, and partners as required by contracts or regulations
6. Update — Regenerate SBOMs whenever dependencies change, and retire SBOMs for decommissioned software

Getting Started

The fastest path to SBOM adoption:

1. Pick a format. CycloneDX is the simplest starting point for security-focused use cases. SPDX is a good choice if license compliance is a primary driver. See our format comparison.
2. Add SBOM generation to CI. Use the sbomify GitHub Action, Syft, Trivy, or a CycloneDX plugin for your language. Generate the SBOM alongside your build artifacts.
3. Ingest into a management platform. sbomify provides centralized SBOM storage, vulnerability analysis via Google OSV, and sharing capabilities.
4. Monitor continuously. Set up alerts for new vulnerabilities affecting your components.

For step-by-step generation guides across different ecosystems, see our SBOM generation guides.

Frequently Asked Questions

What is an SBOM?

An SBOM (Software Bill of Materials) is a machine-readable inventory that lists every component in a piece of software, including direct dependencies, transitive dependencies, their versions, suppliers, and licenses. It is often compared to a nutritional label for food — it tells you exactly what is inside. See What is an SBOM? for a deeper overview.

What are the main SBOM formats?

The two dominant SBOM formats are SPDX (Software Package Data Exchange), maintained by the Linux Foundation, and CycloneDX, maintained by OWASP. Both support JSON and XML serialization. SPDX has deeper roots in license compliance, while CycloneDX was designed for security and supply chain use cases. For a detailed comparison, see our format guide.

Why are SBOMs important for security?

SBOMs enable rapid vulnerability response. When a new CVE is disclosed, an SBOM lets you determine in seconds whether your software contains the affected component — without manually auditing source code or build systems. This is critical for monitoring against databases like the CISA KEV catalog and for meeting regulatory compliance requirements.

How do I generate an SBOM?

SBOMs can be generated using tools like the sbomify GitHub Action, Syft, Trivy, or CycloneDX CLI plugins. The most accurate SBOMs are generated at build time, when the full dependency tree is resolved.

Are SBOMs required by law?

Increasingly, yes. U.S. Executive Order 14028 requires SBOMs for software sold to the federal government. The EU Cyber Resilience Act requires manufacturers of products with digital elements to identify and document components. The FDA requires SBOMs for medical device software. Many procurement contracts now include SBOM requirements as well.