SBOM Explained: CycloneDX vs SPDX, VEX and Why Buyers Ask

Modern software is mostly assembled, not written. A typical application pulls in hundreds of open-source packages, each with its own dependencies, plus a base container image, system libraries and, increasingly, AI models. When a new critical vulnerability lands in a popular library, the first question is always the same: "Are we using it, and where?" Teams without an answer spend days grepping repositories and asking around.

A Software Bill of Materials (SBOM) is the answer prepared in advance. This guide explains what an SBOM contains, how CycloneDX and SPDX differ, why customers and regulators now ask for one, and how to keep SBOMs useful instead of letting them become compliance paperwork.

What an SBOM is

An SBOM is a formal, machine-readable inventory of the components that make up a piece of software and the relationships between them. Think of it as the ingredients list on a food label, but for code.

In the United States, the NTIA published a widely referenced set of minimum elements for an SBOM. In plain terms, each component should be described with:

• Supplier — who created or maintains it.
• Component name and version.
• Unique identifiers — such as a Package URL (purl) or CPE, so tools can match the component to vulnerability databases.
• Dependency relationships — what includes what, so you can see direct versus transitive dependencies.
• Author of the SBOM data and a timestamp.

Richer SBOMs also include licenses, cryptographic hashes, download locations and build information. Licenses matter for legal review; hashes matter for integrity and for detecting tampered or substituted packages.

CycloneDX vs SPDX

Two formats dominate, and most tooling supports both.

SPDX (Software Package Data Exchange) is a Linux Foundation project that began with a focus on license compliance and is published as an international standard (ISO/IEC 5962). It is strong at describing packages, files, licenses and copyright, and it has expanded over time to cover security use cases.

CycloneDX is an OWASP project designed from the start for security and supply-chain risk use cases. It has since been standardized through Ecma International. Beyond software components, it can describe services, hardware, vulnerabilities, VEX statements, and machine-learning models and datasets.

Which should you pick? In practice:

• If your main driver is license compliance or a customer explicitly requests SPDX, use SPDX.
• If your main driver is vulnerability management and supply-chain security, CycloneDX is often the more natural fit.
• Many organizations generate both, since conversion between them is well supported for the core fields.

The format matters much less than completeness, accuracy and freshness. A perfectly formatted SBOM that misses transitive dependencies or is six months old is not much use.

Why buyers and regulators now ask for SBOMs

Several forces turned SBOMs from a niche practice into a procurement checkbox:

• US Executive Order 14028 (May 2021) on improving the nation's cybersecurity directed federal agencies to strengthen software supply-chain security, including providing SBOMs for software sold to the government. That pushed SBOM expectations into vendor contracts and, from there, into the wider market.
• The EU Cyber Resilience Act (CRA) sets cybersecurity requirements for products with digital elements placed on the EU market. Among other obligations, manufacturers must identify and document the components in their products, including by drawing up an SBOM, and handle vulnerabilities throughout the product's support period. Its obligations phase in over several years, so now is the time to build the capability.
• Enterprise buyers increasingly include SBOM requests in security questionnaires and contracts, especially in regulated sectors where frameworks like NIS2 and DORA put weight on supply-chain and third-party risk. See our overview of NIS2 and DORA for vulnerability management.

The common thread: if something in your product is vulnerable, your customers want to know quickly and with evidence, not after a week of investigation.

Keeping SBOMs useful: VEX and continuous generation

An SBOM on its own lists components. Matched against vulnerability databases, it can produce a long list of CVEs, many of which do not actually affect the product because the vulnerable function is never called or the affected configuration is not used. Sending that raw list to customers creates noise and alarm.

VEX (Vulnerability Exploitability eXchange) solves this. A VEX statement declares, for a given product and vulnerability, whether the product is not affected, affected, fixed or under investigation, with a justification. VEX can be expressed in CycloneDX, in CSAF or in lightweight formats such as OpenVEX. Combined with reachability analysis, it lets you say "yes, that library is present, but the vulnerable code is not reachable" and back it up.

The second requirement is continuous generation. Dependencies change with every merge. An SBOM should be produced automatically in the build pipeline for every release, versioned alongside the artifact, and re-evaluated against new vulnerability data even when the code has not changed, because new CVEs are published every day against components you already ship.

A practical checklist:

1. Generate SBOMs in CI for every build, not by hand before an audit.
2. Include transitive dependencies and container base-image packages.
3. Use stable identifiers (purl) so matching against vulnerability data is reliable.
4. Store SBOMs per release so you can answer "which versions are affected?"
5. Continuously match against new vulnerabilities and malicious-package intelligence.
6. Publish VEX for the vulnerabilities customers will ask about.

AI-BOM: the next inventory

Applications that use large language models add new components: the models themselves, their providers, datasets, prompts, agent tools and MCP servers. An AI-BOM extends the SBOM idea to these elements so you know which models and AI integrations each application depends on. CycloneDX already supports describing machine-learning models and datasets. As AI features spread, expect the same "are we using it, and where?" question to be asked about models, and see our guide to LLM application security for the related risks.

Frequently asked questions

Is an SBOM a security control by itself? No. It is an inventory. Its value comes from continuously matching it against vulnerability and threat data and acting on the results.

Should I share my SBOM with customers? Increasingly, customers expect it. Many organizations share SBOMs on request under NDA, together with VEX to explain which findings do not apply.

CycloneDX or SPDX? Either is acceptable for most purposes. Choose based on what your customers request and whether your focus is license compliance or security; generating both is common.

How priorIQ.ai helps

CodeIQ generates SBOMs in CycloneDX and SPDX from your repositories and containers as part of its SCA, with reachability analysis to separate reachable vulnerabilities from noise, malicious-package detection, and an AI-BOM for applications that use LLMs. Its pipeline gate keeps new risky dependencies out of releases, and AI auto-fix can open verified pull requests to upgrade them. Findings flow into PriorIQ Core, where they are prioritized with CVSS, EPSS, CISA KEV and business context alongside the rest of your exposure.

Learn more about how CodeIQ fits with SAST, SCA, secrets and IaC scanning. Request a demo.