SBOM standards and formats compared (SPDX vs CycloneDX vs...

If you've generated a software bill of materials in the last two years, you've almost certainly run into three names: SPDX, CycloneDX, and Syft JSON. Teams evaluating Anchore's open-source Syft tool often assume these are interchangeable outputs of the same process. They aren't. SPDX is an ISO-standardized format governed by the Linux Foundation, originally built for license compliance and now extended for security use cases. CycloneDX is an OWASP-governed standard designed security-first, with native support for vulnerability data and VEX. Syft JSON is neither — it's Anchore's own internal representation, used as Syft's default output before conversion to a standard format. Picking the wrong one, or assuming your tooling produces a "standard" SBOM when it doesn't, creates real problems at audit time, in vendor SBOM exchanges, and in regulatory submissions. This post breaks down what each format actually is, how Safeguard and Anchore's tooling handle them, and how to decide which one to standardize on.

What Are SPDX, CycloneDX, and Syft JSON, Exactly?

SPDX (Software Package Data Exchange) started at the Linux Foundation in 2010 as a way to communicate open-source license and component data between organizations. It became ISO/IEC 5962:2021, which matters for procurement teams that require ISO-recognized formats in contracts. SPDX 2.3 and the newer SPDX 3.0 spec added security-relevant fields (vulnerability references, relationship types), but its data model still reflects its licensing-and-provenance origins.

CycloneDX was created by OWASP in 2017 specifically for application security use cases. Its schema was security-first from day one: it has first-class support for vulnerabilities, exploitability statements (VEX), pedigree/provenance, and — more recently — cryptographic bill of materials (CBOM) for tracking algorithms and key usage. CycloneDX is not yet an ISO standard, but it's an official OWASP flagship project and is widely adopted in the vulnerability-management tooling ecosystem.

Syft JSON is different in kind, not just in schema. It's Anchore's own internal document format for the Syft CLI tool — the structure Syft uses natively before exporting to SPDX or CycloneDX. It is not a publicly governed standard, has no ISO or OWASP backing, and isn't intended for cross-organization exchange. Its purpose is internal fidelity: capturing every detail Syft extracted, some of which doesn't map cleanly onto SPDX or CycloneDX fields, before an optional conversion step.

SPDX vs CycloneDX: Which Standard Actually Wins Where?

There isn't a single winner — the two standards optimize for different consumers, and this is the core of the "spdx vs cyclonedx" question most teams are actually asking.

• Governance and legal recognition: SPDX's ISO/IEC 5962:2021 status gives it an edge in contexts where procurement or legal teams specifically require an ISO-recognized format. CycloneDX's governance sits with OWASP, which carries strong credibility in the security community but isn't an ISO body.
• Security expressiveness: CycloneDX's schema was built around vulnerability and exploitability data from the start, including native VEX documents that let you state "this component is present but not exploitable in this context." SPDX added comparable security fields later (2.3 and 3.0), so older SPDX 2.2 documents you may still encounter in the wild lack this expressiveness entirely.
• Regulatory acceptance: US federal guidance (the NTIA's 2021 minimum elements document and subsequent CISA guidance) explicitly names both SPDX and CycloneDX as acceptable formats — neither is mandated over the other for US compliance purposes. If you're selling into a specific regulatory or contractual context, check that document's required format rather than assuming.

Neither format is fabricated as "the" answer here — the honest takeaway is that most security-tooling vendors (including Anchore's own Grype and Anchore Enterprise) accept both as input, which is itself a sign the market hasn't consolidated on one.

Where Does Syft JSON Fit In, and Why Does Anchore Default To It?

Syft's documented default output format is its own syft-json, not SPDX or CycloneDX. Users have to explicitly pass a -o spdx-json or -o cyclonedx-json flag to get a standardized document. This is a reasonable engineering choice for a scanning tool — Syft's native format preserves scanner-specific detail (like exact catalogers used, file-level evidence, and confidence metadata) that doesn't have a clean home in either public schema. But it means two things worth flagging for anyone evaluating Anchore's tooling:

1. If your pipeline calls syft without an explicit output flag, you get a document that other SBOM consumers, VEX tools, and most vulnerability databases cannot parse without a conversion step.
2. Round-tripping through Syft JSON to SPDX or CycloneDX is a lossy conversion in either direction — fields native to Syft JSON don't map onto the standard schemas, and vice versa.

This isn't a criticism of Syft as a generator — it's a widely used, capable open-source scanner, and Anchore deserves credit for supporting export to both major standards. It's simply a detail that gets lost when teams assume "Syft output" and "SBOM standard" are synonyms.

Format Support: Safeguard vs Anchore's Tooling

Two concrete, checkable dimensions distinguish how Safeguard and Anchore's Syft/Grype stack approach this:

Default output format. Safeguard's SBOM generation targets SPDX and CycloneDX as first-class outputs directly — there is no intermediate proprietary schema you need to explicitly opt out of. Anchore's Syft, by contrast, defaults to its native syft-json and requires an explicit flag to emit a standardized document, as documented in Syft's own CLI reference.

Format-agnostic ingestion. Because supply-chain security work usually means consuming SBOMs from vendors and open-source projects you don't control — not just generating your own — the more consequential question is often ingestion, not generation. Safeguard is built to ingest and normalize both SPDX and CycloneDX documents (across their respective JSON, tag-value, and XML serializations where applicable) into a common internal model, so that downstream vulnerability correlation and policy checks work the same way regardless of which standard a given upstream vendor shipped. We're not asserting specifics about Anchore Enterprise's ingestion pipeline here since that's not something we can verify independently — if format-agnostic ingestion matters for your vendor SBOM workflows, it's worth confirming directly with any vendor, Anchore included, which formats their ingestion path accepts and whether conversion between them is lossless.

If your organization already has a strong opinion on SPDX vs CycloneDX — driven by a customer contract, a regulatory submission, or an internal standard — the practical question to ask any tool, Safeguard or otherwise, is: does it produce that format natively, or does it require a conversion step from something else?

Which Format Should You Standardize On?

A few decision points that hold regardless of vendor:

• If you sell to the US federal government or its supply chain, either SPDX or CycloneDX satisfies current NTIA/CISA minimum-elements guidance — check the specific contract language rather than assuming one is required.
• If VEX and exploitability triage are central to your workflow, CycloneDX's native VEX support is more mature today and has broader tooling adoption for that specific use case.
• If license compliance and legal review are the primary driver, SPDX's longer history and ISO status make it the more conservative choice for legal teams.
• If you're consuming SBOMs from many third parties, plan for both formats regardless of which one you generate — you won't get to choose what your vendors ship you.
• Avoid standardizing on a scanner's native internal format (like Syft JSON) as your organization's canonical SBOM format, since it limits interoperability with any tool outside that scanner's own ecosystem.

How Safeguard Helps

Safeguard treats SBOM format diversity as a given, not an edge case. On the generation side, Safeguard produces SPDX and CycloneDX documents directly as first-class outputs, so you're not stuck converting from a proprietary intermediate schema before you can hand an SBOM to a customer, auditor, or regulator. On the ingestion side, Safeguard normalizes incoming SPDX and CycloneDX documents from vendors and upstream projects into a single internal model, so vulnerability correlation, policy enforcement, and reporting behave consistently no matter which standard a given supplier used to produce their SBOM.

That combination matters most in the situation every supply-chain security team eventually hits: you generate SBOMs in one format for your own compliance needs, receive them in a different format from dozens of vendors, and need a single, coherent view of your exposure across all of it. If you're currently untangling a mix of SPDX, CycloneDX, and scanner-native formats across your vendor SBOMs, Safeguard's SBOM platform is built to collapse that into one normalized inventory — reach out to see how it fits into your existing pipeline.