TL;DR: Three SBOM standards serve different purposes. CycloneDX prioritizes vulnerability tracking with native VEX support. SPDX focuses on licensing compliance and has broader tool adoption. SWID comes from IT asset management and sees limited use outside specific federal requirements. Most teams need CycloneDX for security work and SPDX for legal review.
There are three unique Software Bill of Materials (SBOM) standards:
The format your team chooses determines whether your SBOM becomes a security tool or sits unused in an artifact repository. FDA reviewers have rejected submissions over format mismatches, and federal contractors often receive format specifications without a clear rationale. This gap between compliance and utility is where most SBOM initiatives fail.
Most teams can generate SBOMs, but without processes to interpret and apply that data, the output rarely delivers real security value.
In this guide, you’ll see what each standard captures, which tools generate clean output versus SBOMs that technically validate but lack meaningful data, and how to use SBOM data for dependency risk management.
SBOM standards define how you document the components, dependencies, and metadata in a software product. The standards specify which fields are required and how relationships get structured, including the formats tools should output.
The main problem: three competing standards exist, each with different strengths, and most tools implement them inconsistently. Your build pipeline might generate an SBOM that validates against the schema but lists every component as “NOASSERTION” for licensing or omits the CPE identifiers that vulnerability scanners need.
Schema validation alone proves nothing about data quality. An SBOM can pass every validation check while containing zero actionable information because the generator filled the required fields with placeholder values.
The three primary SBOM standards are:CycloneDX: Built by the Open Worldwide Application Security Project (OWASP) community specifically for security use cases, with strong support for vulnerability data and dependencies
SPDX: Created by the Linux Foundation for open source licensing compliance, now used for broader supply chain transparency
WID: Developed by the National Institute of Standards and Technology (NIST) for IT asset management, required for some federal systems but rarely used elsewhere
Each standard made different design choices about what matters most, which affects what you can actually do with the SBOM after you generate it.
Additionally, White House Executive Order 14028 on cybersecurity required SBOMs but didn’t mandate a specific standard. Different federal agencies made different choices, leading to medical device manufacturers seeing FDA 510(k) submissions bounced because they generated SPDX in JSON format when FDA’s tools only parsed tag-value format. Six weeks get lost to format conversion that adds no technical value.
CycloneDX was purpose-built for application security. When you need to track whether CVE-2024-1234 affects your production services, CycloneDX makes that correlation straightforward because the standard was designed with that workflow in mind.
The architecture reflects security priorities. Where SPDX evolved from licensing concerns and added security fields later, CycloneDX started with vulnerability tracking as the primary use case.
Component inventory with versions, hashes, and package URLs (PURLs) that precisely identify what you’re using. The PURL specification standardizes how packages are named across ecosystems, ensuring tools recognize that “jackson-databind” in your Maven build is the same component in vulnerability databases.
Dependency graphs show which components rely on others, important when a vulnerable transitive dependency sits five layers deep. The graph structure lets you trace exactly which direct dependencies pulled in the problematic component.
VEX data is embedded directly in the SBOM documents, indicating whether your code actually calls the vulnerable function. This separates theoretical exposure from operational risk. VEX documents that analysis and prevents false-positive alerts.
Service definitions for microarchitectures track external APIs and data flows, extending beyond traditional dependency tracking.
CycloneDX outputs in JSON or XML. JSON is more common in modern toolchains.
The schema versions matter:
Using an older version might mean being stuck on 1.4 for six months because upgrading to 1.6 could break existing vulnerability correlation steps. The reason would be the schema changes weren’t backward compatible. You’ll see it when a scan shows “0 components detected” for container images built with an outdated plugin. The SBOM technically validates, but the missing container-layer metadata makes every image look empty to the scanner.
To avoid that mismatch, use the current generation plugins that natively support CycloneDX across major build tools:
The dependency graph and PURL identifiers let vulnerability scanners automatically match CVEs to your deployments instead of requiring manual lookups.
Choose CycloneDX when you need operational SBOMs that feed into security workflows:
Container registries like Harbor, Amazon ECR, and GitHub Container Registry now accept SBOM uploads directly, but most only support CycloneDX or SPDX in JSON format. SWID is rarely accepted because it lacks container-layer metadata. Using CycloneDX ensures registries can automatically associate SBOMs with stored images for vulnerability scanning.
SPDX was developed nearly a decade before CycloneDX to identify which open-source licenses apply to components inside a product. Legal teams encounter the problem regularly: a library marked “MIT” contains a single GPL file deep in its tree. SPDX lets legal see that file before it becomes a compliance issue.
Originally focused purely on licensing and open-source compliance, SPDX has expanded significantly with versions 2.3 and 3.0 to include vulnerability tracking and security use cases.
Despite these additions, the standard’s core strength remains licensing clarity.
Detailed license information, including SPDX license identifiers, custom license text, and license expression parsing. The SPDX License List provides standardized identifiers for hundreds of open-source licenses.
File-level analysis documents which licenses apply to which source files, key for legal review. This granularity catches edge cases where a primarily MIT-licensed project includes GPL-licensed test utilities.
Package relationships identify which packages include or depend on others, modeling relationships like “CONTAINS,” “DEPENDS_ON,” and “BUILD_TOOL_OF.”
Security identifiers (CPEs, PURLs) were added in versions 2.3 and 3.0 to support vulnerability tracking, though not always populated by tools.
When legal reviews your software, they need to know whether the MIT-licensed library you’re using actually contains files under the GNU General Public License (GPL) that trigger copyleft requirements. SPDX documents this at file granularity.
SPDX supports multiple formats: RDF/XML, JSON, YAML, tag-value, and spreadsheets. This flexibility causes practical problems because every format requires different parsing code.
Version differences also matter significantly:
SPDX 2.2: Widely adopted, stable, focuses exclusively on licensing with limited security metadata
SPDX 2.3: Added external references for security identifiers, bridging licensing and vulnerability tracking
SPDX 3.0: Complete redesign with expanded security capabilities, making it more competitive with CycloneDX for vulnerability management, but limited tool adoption as of 2024
Version fragmentation creates practical issues. Teams generate SPDX 2.3 but find their legal team’s review tools only parse 2.2, requiring conversion that strips security fields.
You would use SPDX when your legal department requires SBOMs for open source license compliance and already has workflows built around the SPDX format. Changing to CycloneDX or another SBOM standard means retraining and potentially new tooling.
Another instance is when you’re shipping software to customers who specifically request SPDX, common in automotive and industrial sectors where SPDX adoption happened early.
SWID tags were designed for IT asset management, tracking what software is installed on enterprise devices. The standard came from NIST and gained traction in federal systems.
The use case differs fundamentally: SWID answers “what software is on these 10,000 endpoints” while CycloneDX and SPDX answer “what components are in this application.” SWID rarely shows up in development workflows but appears in federal requirements where compliance tracking needs to match installed software against approved baselines.
Use SWID when your organization already uses SWID tags for IT asset management, you’re selling software to federal agencies that mandate SWID tags per NIST guidelines, or your IT operations team needs software inventory data for thousands of endpoints.
SWID uses XML following the ISO/IEC 19770-2 standard. The format is verbose and primarily consumed by enterprise asset management tools rather than security scanners or vulnerability databases.
For organizations with existing ITAM infrastructure, SWID integration is often already in place through tools like ServiceNow, Flexera, or Snow Software.
Few development tools generate SWID natively, which creates a gap between DevOps workflows and enterprise asset management. Organizations that need SWID for compliance typically use specialized software to create tags from existing package manifests, adding manual overhead compared to automated SPDX or CycloneDX generation during builds.
You would use SWID when:
For modern DevSecOps workflows focused on vulnerability management and dependency tracking, CycloneDX or SPDX are more practical choices. SWID’s limited adoption in security tooling and CI/CD pipelines makes it less suitable for development-centric SBOM use cases.
Generating accurate SBOMs requires integration across your build pipeline. They must be generated as part of the build process and validated to ensure they contain usable, complete data.
These modern build tools include SBOM generation as a feature:
These native integrations are more accurate than external scanning tools because they understand the build system’s dependency resolution logic. When Maven resolves version conflicts through dependency management, the SBOM reflects what actually got compiled, not what the original pom.xml requested.
The limitation is that each build tool outputs one format, typically CycloneDX. Organizations needing SPDX for legal review must run separate tooling or convert formats, risking inconsistency.
Tools like Syft and Trivy scan built artifacts to extract component information. Artifact scanning catches components that build tools miss, particularly OS packages in container-based images. The tradeoff is accuracy. Scanners make educated guesses about versions based on file signatures.
For production use, combine both approaches: generate SBOMs during build with native tools, then re-scan final artifacts to catch anything the build process didn’t document.
SBOM generation belongs to continuous integration and continuous delivery CI/CD, running automatically on every build.
A practical implementation flow looks like this:
SBOM generation adds 2-3 minutes per build. This is time well spent for the visibility you gain. Teams running 50+ builds daily invest about 2.5 hours in pipeline time, but that’s far less than the hours spent manually hunting affected services when the next CVE drops
You’ll see the impact immediately once SBOM generation runs in CI. Every build starts producing a CycloneDX file alongside the artifact, and those SBOMs feed straight into your vulnerability management platform. The next morning, the system compares yesterday’s SBOMs to today’s and flags new CVEs introduced through dependency updates. The deployment pipeline blocks the build until the issue clears. Over time, you’ll stop dozens of vulnerable components before they ever reach production.
A schema-valid SBOM isn’t necessarily a usable one. Data quality matters more than format compliance.
Common issues include component names missing ecosystem identifiers, versions listed as “latest” instead of fixed values, license fields set to “NOASSERTION,” missing PURL or CPE identifiers breaking vulnerability matching, and no dependency relationships, leaving a flat list instead of a graph.
A complete SBOM covers declared and transitive dependencies, OS packages in container images, statically linked libraries, and vendored code. Your package.json lists 20 packages, but npm installed 500. A complete SBOM documents all 500.
Accuracy drifts when the SBOM no longer matches what’s deployed. Regenerate SBOMs on every build, compare against runtime scans, and audit artifact repositories to confirm SBOM-to-artifact mappings.
Most organizations generate SBOMs because procurement requires them. The SBOM data starts to become part of your security workflow when the data begins to block vulnerable builds and flags outdated components.
When a supply chain compromise hits, like the xz backdoor or log4shell, SBOMs tell you immediately whether you’re affected and where. Query all SBOMs for the compromised component and get a list of every service that needs patching. Without SBOMs, teams spend days searching code repositories. With SBOMs, the answer is a database query that runs in seconds.
Use CycloneDX when your primary need is vulnerability management and security scanning, you’re building security automation that ingests SBOM data, or container images and dependency graphs are core to your architecture.
Opt for SPDX when legal teams require detailed license compliance documentation, you’re shipping software where copyleft obligations need file-level analysis, or your industry has already standardized on SPDX.
Pick SWID when federal procurement explicitly requires SWID tags per NIST guidelines or your organization already has asset management infrastructure consuming SWID.
| Feature / Focus | CycloneDX | SPDX | SWID |
| Primary Purpose | Application security and vulnerability management | Open-source license compliance and supply chain transparency | IT asset management and software inventory tracking |
| Maintained By | OWASP Foundation | Linux Foundation | NIST / ISO (ISO/IEC 19770-2) |
| Typical Use Case | Security scanning, DevSecOps pipelines, CVE correlation | Legal audits, open-source compliance documentation | Enterprise IT inventory, federal procurement |
| Key Data Fields | Components, versions, PURLs, VEX data, dependency graph | Licenses, copyrights, file-level metadata, package relationships | Vendor, product, version, installation metadata |
| File Formats Supported | JSON, XML | JSON, YAML, RDF/XML, tag-value, spreadsheet | XML only |
| Tooling Support | Strong in modern build tools and container registries | Broad legal/compliance tool adoption | Supported by enterprise ITAM tools |
| Best For | Security teams automating vulnerability detection | Legal teams managing license risk | IT operations managing installed software |
| Common Limitations | Less file-level license granularity | Weaker vulnerability correlation (unless 3.0) | Not suited for development or CI/CD pipelines |
Generating both CycloneDX and SPDX
Most teams end up generating more than one SBOM format because security tools, legal teams, and federal partners consume data through different systems. Syft and similar tools output multiple formats from a single scan, keeping formats synchronized.
You would generate both SBOM standards when:
Multi-format generation is straightforward when build tools support it. Syft and similar tools output multiple formats from a single scan. This keeps formats synchronized and prevents version skew between the CycloneDX your security team uses and the SPDX legal reviews.
SBOM generation starts making sense when it fits naturally into existing workflows instead of requiring separate processes.
Kiuwan Insights generates complete SBOMs as part of continuous software composition analysis. When you scan third-party components for vulnerabilities and license compliance, the platform simultaneously builds accurate component inventories with the metadata that vulnerability matching and legal review actually need.
You get one-click SBOM export in CycloneDX or SPDX formats, with confidence that component versions, licenses, and identifiers reflect what’s actually in your code. The scanning happens automatically across your development lifecycle, so SBOMs stay current without manual regeneration.
Ready to see how Kiuwan easily generates an SBOM?
Schedule a free trial and discover how SBOM standards support security operations instead of just checking compliance boxes.
An SBOM standard defines the format and required fields for documenting software components, dependencies, and metadata. The three primary standards each serve different purposes: CycloneDX, SPDX, and SWID. CycloneDX prioritizes security and vulnerability tracking, SPDX focuses on licensing compliance, and SWID handles IT asset management. Standards ensure SBOMs can be generated by different tools and consumed by vulnerability scanners, legal review platforms, and compliance systems.
Kiuwan produces SBOMs directly from dependency resolution data instead of inferring components from post-build scans. This eliminates common issues like missing transitive dependencies or “NOASSERTION” license fields. The platform continuously updates SBOMs as code changes, tracks component age and obsolescence, and ensures identifiers such as PURL and CPE are populated for reliable vulnerability matching. The result is SBOM output that’s both schema-compliant and operationally useful for security and compliance teams.
Use CycloneDX for security operations, vulnerability management, and DevSecOps workflows. Use SPDX when legal teams need file-level license analysis or when partners specifically require SPDX format. Use SWID only if federal procurement explicitly mandates it. Many organizations generate both CycloneDX and SPDX from the same build, using CycloneDX for security scanning and SPDX for legal review.
CycloneDX supports JSON and XML. SPDX supports JSON, YAML, RDF/XML, tag-value text format, and spreadsheets. SWID uses XML only. JSON is most common for automated processing. Format choice affects tool compatibility. Some vulnerability scanners only parse specific formats, and conversion between formats can lose information.
Maven CycloneDX plugin, Gradle CycloneDX plugin, npm @cyclonedx/cyclonedx-npm, .NET built-in SBOM generation, Syft for container and filesystem scanning, and Tern for container layer analysis all generate SBOMs automatically. Kiuwan Insights generates CycloneDX or SPDX SBOMs during software composition analysis. Native build tool integration is more accurate than post-build scanning because build tools know exactly what the dependency manager resolved.
NTIA defined minimum elements required for an SBOM: supplier name, component name, version, unique identifier, dependency relationships, SBOM author, and timestamp. These elements can be satisfied by CycloneDX, SPDX, or SWID formats. However, minimum elements represent baseline compliance. Useful SBOMs include additional metadata like license information, vulnerability references, and component hashes that the minimum elements don’t require.
CycloneDX and SPDX both include fields for vulnerability identifiers (CVE, CPE, PURL) that enable automated correlation against vulnerability databases. CycloneDX’s dependency graph shows which components are transitive dependencies, helping prioritize direct dependencies for updates. VEX data in CycloneDX documents whether vulnerable code is actually exploitable in your context. Automated SBOM generation feeds vulnerability platforms with current component inventories, replacing manual tracking with continuous monitoring.
