An SBOM format is the standardized structure that makes a software bill of materials machine-readable — a shared grammar so that the tool which generates your inventory and the tool which consumes it agree on what every field means. An SBOM listing your components is only valuable if other systems can parse it reliably, and that requires a common format. Two open standards dominate in 2026: SPDX and CycloneDX. Understanding what each captures and where they diverge lets you produce inventories that flow cleanly through scanners, registries, and compliance workflows instead of becoming a file nobody can use.
Why It Matters
Regulators and customers increasingly ask organizations to produce an SBOM on demand — the US Executive Order on cybersecurity, the NIST Secure Software Development Framework, and the EU Cyber Resilience Act all point in this direction. But an SBOM written in an ad hoc, home-grown structure fails the moment someone else's tool has to read it. Format is what makes the inventory portable.
Format also determines what questions you can answer. A bare list of package names is far less useful than one that records versions, cryptographic hashes, license identifiers, and the relationships between components. When a new vulnerability is disclosed, the richness of your SBOM decides whether you can say "we are affected, here, in this version" in seconds, or whether you are back to guessing.
The Core Concepts
- SBOM. A machine-readable inventory of the components in a piece of software, with metadata about each.
- SPDX. The Software Package Data Exchange, an ISO-standardized format originally focused on license compliance and now widely used for full inventories.
- CycloneDX. A format created by the OWASP community with a security-first design, strong support for vulnerability and dependency data, and extensions for services and machine-learning models.
- Component identity. How a package is uniquely named — commonly a Package URL (purl) or, for vulnerability matching, a Common Platform Enumeration (CPE).
- Relationships. How the format expresses that one component depends on, contains, or was generated from another.
How It Works End to End
Both formats describe the same underlying reality but emphasize different things. The comparison below covers the practical points beginners ask about most.
| Aspect | SPDX | CycloneDX |
|---|---|---|
| Steward | Linux Foundation, ISO/IEC 5962 standard | OWASP Foundation |
| Original focus | License compliance | Security and risk |
| Encodings | Tag-value, JSON, YAML, RDF | JSON, XML, Protobuf |
| Component IDs | SPDX IDs, purl, CPE | purl, CPE |
| Vulnerability data | Supported, historically lighter | First-class, richly modeled |
| Beyond software | Broad metadata | Services, ML models, and more |
A concrete walkthrough: your build pipeline finishes assembling an application. A generator inspects the resolved dependency tree and emits an SBOM in, say, CycloneDX JSON. Each component entry carries a name, version, a purl for precise identity, one or more hashes for integrity, and its declared license. Relationship entries record which component depends on which. That file is then handed to a vulnerability scanner, which matches every purl against known-vulnerability databases, and to a registry that stores it alongside the artifact. Weeks later a serious flaw is disclosed. Because the identity fields are precise and standardized, a query across every stored SBOM instantly returns which builds contain the affected version — no rebuild, no manual audit.
Best Practices
- Pick a format and produce it consistently. The value compounds when every build emits the same structure. CycloneDX is a common default for security-driven programs; SPDX is common where license compliance leads.
- Include precise identity. A name and version alone can be ambiguous. Populate purls and, where relevant, CPEs so vulnerability matching is accurate.
- Capture hashes. Cryptographic hashes let a consumer verify that a component has not been tampered with since the SBOM was made.
- Record relationships, not just a flat list. Dependency relationships let you trace a vulnerable transitive package back to what you control.
- Generate automatically at build time. An SBOM created by hand goes stale immediately. Make it a pipeline artifact tied to each build.
- Keep every SBOM. Retaining historical inventories is what lets you answer "were we ever exposed?" for a flaw disclosed long after release.
How Safeguard Helps
Format decisions get much easier when tooling handles them for you. SBOM Studio generates a bill of materials for every build, emits both SPDX and CycloneDX so you can satisfy whatever a customer or regulator asks for, and version-controls each one so you always have the historical snapshots that make disclosures answerable in seconds.
Producing the inventory is only half the story. Software Composition Analysis reads the resolved tree behind the SBOM, matches components against known vulnerabilities using their precise identifiers, and feeds findings to Griffin AI, which prioritizes them by reachability so you act on what matters first. If a term in this guide is unfamiliar, the concepts library defines the surrounding vocabulary.
To generate and read your first standards-based SBOM, follow the guided lessons in Safeguard Academy or create a free account and produce one from a real project in minutes.
Frequently Asked Questions
Should I choose SPDX or CycloneDX?
Choose the one that matches your primary driver, and know that good tooling can emit both. SPDX has deep roots in license compliance and is an ISO standard, which some procurement processes prefer. CycloneDX was designed with security and vulnerability data as first-class concerns and is a natural fit for AppSec workflows. Many teams generate both from the same build to avoid ever being asked for a format they cannot produce.
What is the minimum an SBOM should contain?
At a baseline, each component needs a name, a version, a unique identifier such as a purl, and the supplier or origin where known. Adding cryptographic hashes and license identifiers makes the inventory far more useful, and recording dependency relationships lets you trace and fix transitive issues. Both major formats support all of this.
Can I convert between SBOM formats?
Yes, in most cases. Because SPDX and CycloneDX describe the same underlying facts, conversion tools can translate between them, though some format-specific fields may not map perfectly. The safest approach is to generate each format natively from the build rather than relying solely on conversion, which is what most SBOM tooling supports.
Is generating an SBOM the same as scanning for vulnerabilities?
No. An SBOM is an inventory — it records what components are present regardless of whether any are flawed. A vulnerability scan is an assessment that compares those components against databases of known issues. They work together: the SBOM tells you what you have, the scan tells you which of those things are currently dangerous, and keeping the SBOM lets you re-run that assessment every time a new flaw is disclosed.