What is an SBOM?
A software bill of materials (SBOM) is a machine-readable nested inventory of every component, library, and dependency in your software. Visibility into these layers empowers teams to track active installations across the environment, identify known vulnerabilities, and ensure license compliance. Operating without an SBOM creates blind spots in your software supply chain risk posture.
Standard SBOM reports capture the name, version, and license for each component in your software. Comprehensive SBOMs also include supplier data, dependency relationships, and cryptographic hashes for integrity verification.
SBOMs are foundational to software supply chain security. They enable automated vulnerability scanning across your entire inventory and provide the licensing data required for compliance audits.
Pro tip: Wiz delivers complete visibility via agentless SBOM generation of your applications' components, including packages, open-source libraries, and nested dependencies.
Catch code risks before you deploy
Learn how Wiz Code scans IaC, containers, and pipelines to stop misconfigurations and vulnerabilities before they hit your cloud.
What are popular SBOM formats?
Three formats frequently appear in SBOM discussions, though two formats dominate the SBOM ecosystem: Software Package Data Exchange (SPDX) and CycloneDX (CDX). SPDX acts as the standard for managing license compliance across supply chains. CycloneDX offers a lightweight, security-focused alternative built for rapid vulnerability identification. The third format, Software Identification (SWID) tags, tracks installed software versions. Most organizations prioritize SPDX or CycloneDX to satisfy regulatory requirements and ensure interoperability.
Software Package Data Exchange
The Linux Foundation developed SPDX to track open-source licenses. It now holds ISO-standardization (ISO/IEC 5962:2021), offering a rigorous framework for file integrity verification, vulnerability references, and component relationships. This formal ISO recognition makes SPDX the preferred choice for enterprises prioritizing standardized documentation and license compliance.
CycloneDX
The OWASP Foundation created CycloneDX to prioritize security and vulnerability tracking. Its lightweight, extension-based architecture allows teams to add capabilities incrementally, bypassing monolithic schemas upfront. This design suits DevSecOps teams that value speed, agility, and vulnerability management over license compliance.
Software Identification tags
Software Identification (SWID) tags standardize software product identification, similar to ISBNs for books. While they capture basic metadata, including version, creator, and licensor, these tags don’t provide a dependency inventory. Organizations often reference SWID tags during SBOM discussions, but they function as identifiers distinct from true inventory SBOM formats.
How do SPDX and CDX differ?
Choosing between SPDX and CycloneDX depends on your organization's primary goals. The following comparison covers the dimensions that drive format selection.
Format
SPDX and CycloneDX support JSON and XML serialization. SPDX also supports YAML and a tag-value plain text format to simplify reading manual reviews. Choosing the SPDX plain text option reduces friction for teams that perform frequent manual SBOM file inspections.
Real-World Example: Transitive Dependencies
Rather than looking at overly simplistic, flat applications, let's look at how modern SBOM formats handle the real challenge: nested, or "transitive," dependencies.
In the real world, the most critical vulnerabilities are often transitive—pulled in by a secondary library you didn't explicitly install. Here is how a modern CycloneDX JSON document structures a nested dependency, mapping exactly how library-B relies on the vulnerable library-C:
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"components": [
{
"type": "library",
"bom-ref": "pkg:maven/com.example/library-B@2.0.0",
"name": "library-B",
"version": "2.0.0"
},
{
"type": "library",
"bom-ref": "pkg:maven/com.vulnerable/library-C@1.0.4",
"name": "library-C",
"version": "1.0.4"
}
],
"dependencies": [
{
"ref": "pkg:maven/com.example/library-B@2.0.0",
"dependsOn": [
"pkg:maven/com.vulnerable/library-C@1.0.4"
]
}
]
}
Note the use of Package URLs (PURLs) in the bom-ref. PURLs are the modern standard for identifying software components, heavily reducing the false-positive mismatches associated with legacy CPEs.
Specification scope
The Linux Foundation originally built SPDX to manage the complexities of open-source licensing, including the GNU General Public License (GPL). To satisfy source code attribution and source sharing requirements, SPDX captures granular data, including software licenses, individual files, and code snippets, to ensure legal safety.
The OWASP Foundation developed CDX with a security-first focus. While its core function covers code and binaries, CycloneDX also uses CDX extensions for web services to map API dependencies and track software vulnerabilities across the application.
While their origins differ, SPDX and CDX have converged to support comprehensive vulnerability tracking and license management.
Adoption
SPDX commands broader industry adoption and tooling support due to its ISO standardization (ISO/IEC 5962:2021). Enterprises that require formal standards documentation often default to SPDX to guarantee compliance.
CycloneDX adoption is growing rapidly, driven by its lightweight design and OWASP backing. Smaller organizations often find CycloneDX easier to implement because it doesn't require the full specification overhead typical of ISO-standardized formats.
Both ecosystems now converge as SPDX 3.0 adds security profiles, while CycloneDX expands to cover AI and machine learning models.
Specification approach
The SPDX specification follows a monolithic approach, defining required standard fields and identifiers for describing software packages and licenses upfront. While this ensures strict consistency, it can increase initial implementation complexity for new tooling.
CDX specifications offer greater flexibility by using an extensible schema. This design requires only minimal information initially, and allows teams to add other features as their security needs evolve. Because CycloneDX prioritizes JSON and XML, it integrates seamlessly with modern web-based security scanners.
License identification
SPDX leads in licensing clarity by using a standardized license list with short, universally recognized identifiers for common licenses. Its license expression syntax enables teams to map complex scenarios.
CDX supports licensing data but focuses on offering more detailed license information, including custom license names and texts. While both formats manage attribution, SPDX remains the stronger option for automated legal vetting and compliance reporting.
Vulnerability mapping
Generating an SBOM inevitably creates a massive spike in vulnerability noise. A companion VEX (Vulnerability Exploitability eXchange) document solves this by asserting whether a vulnerability is actually exploitable in your specific context.
Instead of manually triaging hundreds of CVEs, VEX allows you to automate suppression—for example, flagging a library as not_affected because the specific vulnerable function is never called by your code. When evaluating SBOM tools, native VEX support isn't just a nice-to-have; it's a mandatory requirement to prevent alert fatigue.
Tooling and ecosystem
SPDX is a much more mature, widely used format, with an extensive ecosystem of tools, libraries, and services. Because every major security provider and software package manager supports SPDX license tags, organizations rely on standard options like Syft and SPDX to generate and parse compliant SBOMs.
The CDX ecosystem is growing rapidly with compatibility across over 260 tools, bolstered by CycloneDX CLI and Trivy. While SPDX holds the historical edge, most modern security platforms support both formats, removing vendor lock-in concerns.
To explore open-source SBOM tools for either format, check out this guide.
Governance
The Linux Foundation governs SPDX through its SPDX Workgroup, which meets regularly online to discuss the maintenance of its ISO-standardized documentation.
The OWASP Foundation manages CDX via the CycloneDX Core Working Group. As a community-driven model, this group meets online once a month to discuss the software supply chain.
Granularity
Both formats define software at the application level.
SPDX offers the highest precision for source code by mapping licenses to individual code snippets within a single file. If you can't isolate code with unique licensing, SPDX can still capture the details required for legal compliance.
CDX prioritizes operational granularity through its API extensions. This structure enables teams to define security profiles for each interaction an API provides. By isolating vulnerable endpoints, developers can safely maintain connections to secure parts of the service.
How to choose an SBOM format
Your format choice must align with your organization's primary SBOM use case. If license compliance is your main concern, SPDX's mature license expression syntax and ISO standardization make it the stronger choice. If vulnerability tracking drives your SBOM program, CycloneDX's native VEX support and security-first design offer a more direct path.
For organizations subject to U.S. federal requirements such as Executive Order 14028, both formats satisfy the NTIA minimum elements. The executive order doesn’t mandate a specific format, so regulatory compliance alone shouldn't dictate your strategy.
Many teams don't stick to one format. Modern SBOM tools generate and consume both SPDX and CycloneDX, allowing you to produce whichever format a stakeholder or customer requires. If you're starting fresh, adopt the format that matches your primary use case and expand tooling later if needed.
Where to generate your SBOM: Build-Time vs. Runtime
How Wiz supports SBOMs
Both SPDX and CycloneDX are production-ready SBOM formats that satisfy current regulatory requirements. SPDX remains the stronger choice for enterprises that need ISO-standardized documentation and have established compliance workflows. CycloneDX is often easier for smaller teams to adopt, particularly those focused on vulnerability tracking rather than license compliance.
The good news is that you don't have to commit to one format exclusively. Wiz features an agentless SBOM generator that supports both SPDX and CycloneDX, letting you produce the format your stakeholders need without modifying your infrastructure. Because it scans your running infrastructure, you always know which software is active. This agentless approach means you don’t have to install anything on your cloud resources to generate a complete inventory.
Plus, the platform supports Go, Java, Python, and Node.js, and can automatically store the generated SBOM files in S3. To see how Wiz simplifies SBOM generation across your cloud environment, request a demo.
Agentless SBOM Generation
Gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots.
