An SBOM file is a structured document that lists every component, library, and dependency inside a piece of software, along with metadata like version, supplier, and license. The catch is that "structured" can mean several different things depending on which format generated it. The three formats you will run into in practice are CycloneDX, SPDX, and SWID, and each one encodes that inventory a little differently — which matters the moment you try to feed an SBOM into a scanner, a compliance tool, or a customer's intake pipeline that expects a specific schema.
What Does an SBOM File Actually Contain?
At minimum, a usable SBOM lists component name, version, supplier, and a unique identifier (usually a package URL, or purl) for every piece of software that ends up in the build — direct dependencies and transitive ones. Beyond that floor, most SBOM files also carry license identifiers, cryptographic hashes, and relationship data describing which component depends on which. The National Telecommunications and Information Administration's (NTIA) minimum elements guidance is the closest thing to an industry baseline for what fields should be present, and most modern SBOM tooling targets it by default.
The file itself is usually JSON or XML, sized anywhere from a few kilobytes for a small service to tens of megabytes for a monorepo with a deep dependency tree.
CycloneDX: Built for Security Tooling
CycloneDX started life inside the OWASP ecosystem and its bias shows: it is optimized for vulnerability and risk workflows. A CycloneDX SBOM file supports first-class fields for vulnerability data (VEX), pedigree (how a component was built or modified), and service definitions for describing microservice architectures, not just packages. It is JSON-first, which makes it easy to generate and parse programmatically, and it has become the format most SCA and container scanners emit by default because the schema was designed with scanning in mind from day one.
If your primary use case is feeding an SBOM into a vulnerability scanner or a runtime monitoring tool, CycloneDX is usually the path of least friction.
SPDX: Built for Licensing and Provenance
SPDX (Software Package Data Exchange) predates CycloneDX and grew out of the Linux Foundation's work on license compliance. It is an ISO/IEC standard (ISO/IEC 5962:2021), which matters for organizations that need a formally recognized standard for procurement or regulatory purposes. SPDX's strength is license and provenance data — it has a rich vocabulary for expressing license concluded vs. license declared, copyright notices, and file-level relationships. Government and defense contracts, along with the U.S. Executive Order 14028 SBOM requirements, frequently reference SPDX by name.
SPDX 3.0 narrowed some of the historical gaps with CycloneDX by adding AI/ML component profiles and better security-relevant fields, but the format's center of gravity is still licensing clarity.
SWID: The Legacy Enterprise Format
SWID (Software Identification) tags come from ISO/IEC 19770-2 and predate both of the above. They are XML tags typically embedded by installers to identify installed software for IT asset management, not dependency-level scanning. You will still encounter SWID in enterprise asset management and some government contexts, but it is rarely the format teams choose when building a new SBOM pipeline today — it describes installed products more than granular component graphs.
Which SBOM File Format Should You Generate?
For most application security teams, the practical answer is: generate CycloneDX for anything feeding a scanner or SCA tool, and keep SPDX available if a customer, regulator, or procurement contract specifically asks for it. Tools like Syft and Trivy can emit both from the same scan, so this is rarely an either/or decision — it's a matter of exporting the right format for the consumer. A software composition analysis platform that ingests both formats natively saves you from maintaining separate conversion scripts.
Whatever format you choose, the format itself does not make the SBOM useful — the completeness and freshness of the data inside it does. A CycloneDX file missing half your transitive dependencies is worse than no SBOM at all, because it creates false confidence.
FAQ
Is CycloneDX better than SPDX?
Neither is objectively better — they optimize for different consumers. CycloneDX leans toward vulnerability and security tooling; SPDX leans toward licensing and provenance, and carries ISO standardization that some procurement processes require by name.
Can I convert between SBOM formats?
Yes, generally. Tools like the SPDX/CycloneDX converters and some SCA platforms support round-tripping between formats, though fidelity loss can occur for fields one format supports and the other doesn't (VEX data, for example, doesn't map cleanly into older SPDX versions).
What file extension does an SBOM use?
Most commonly .json for CycloneDX and SPDX (JSON is the dominant serialization for both now), though .xml and .spdx (tag-value format) still appear, particularly for SPDX in legacy pipelines.
Do I need more than one SBOM file format?
Only if you have consumers with different requirements — for example, a security team wanting CycloneDX for scanning and a legal team or government customer wanting SPDX for compliance. Generating both from a single source scan is standard practice and adds negligible overhead.