SBOMs in 2026: CycloneDX vs SPDX, VEX, and CISA's New Minimum Elements

A Software Bill of Materials (SBOM) is, at its simplest, a structured inventory of every component — open-source library, third-party dependency, internal module — that makes up a piece of software. The idea is old; what changed in 2026 is that CISA published the first full update to the baseline definition since 2021, and the tooling ecosystem has matured enough that generating one is no longer the hard part. Knowing which format to generate, and what to do with it once vulnerabilities are found, is.

What CISA's 2026 update actually changed

The National Telecommunications and Information Administration (NTIA) defined the original SBOM "minimum elements" in 2021 under Executive Order 14028. On July 29, 2026, CISA and a coalition of international cybersecurity agencies published the 2026 Minimum Elements for a Software Bill of Materials, the first full revision of that baseline (RunSafe Security).

The 2026 update defines 23 elements across three groups: nine SBOM metadata fields, eight component data fields, and six practices/processes fields — and explicitly applies to all software, including open-source, AI software, and SaaS, not just traditional shipped applications (CISA). CISA's update explicitly names the two formats that satisfy these elements: SPDX and CycloneDX (RunSafe Security).

CycloneDX vs. SPDX: pick based on what you're optimizing for

These are the two industry-standard formats, and they were built with different primary purposes in mind. CycloneDX, developed by OWASP, is security-focused — a compact model with native vulnerability support built in. SPDX, developed by the Linux Foundation, is compliance-focused, with deep license documentation as its core strength (Kiuwan).

Source: Kiuwan, RunSafe Security

In practice, most teams don't have to choose exclusively — modern SBOM tools generate and consume both formats, allowing you to produce whichever one a specific stakeholder or customer requires (RunSafe Security). If you're starting from zero and have no specific customer mandate pulling you toward SPDX, CycloneDX's native vulnerability and VEX support make it the more practical default for a security-driven SBOM program.

Generating one: the tooling is no longer the bottleneck

Major software composition analysis (SCA) scanners — Snyk, Trivy, Grype, Anchore, and most commercial platforms — generate CycloneDX natively, and it's the default SBOM output format for CI integrations across GitHub, GitLab, and Azure DevOps (Kiuwan).

Minimal CI-integrated SBOM generation (example, using Trivy):

# Generate CycloneDX SBOM for a container image
trivy image --format cyclonedx --output sbom.cdx.json myapp:latest

# Generate SPDX SBOM instead
trivy image --format spdx-json --output sbom.spdx.json myapp:latest

# Scan the generated SBOM against known vulnerabilities
trivy sbom sbom.cdx.json

The practical implication: generating a baseline SBOM is now close to a solved problem — a single CI step. The remaining work is what CISA's "practices and processes" fields point at: keeping the SBOM current as dependencies change, distributing it to the parties who need it, and — critically — pairing it with vulnerability context so it's actionable rather than just an inventory.

Why an SBOM alone isn't enough: enter VEX

A raw SBOM lists every component and, cross-referenced against a vulnerability database, every theoretically applicable CVE — which in a modern application can mean hundreds of flagged vulnerabilities, most of which are not actually exploitable in that specific deployment context (unused code paths, mitigated by configuration, etc.). This is the noise problem that VEX (Vulnerability Exploitability eXchange) solves.

VEX is a framework for software producers to publish clear, structured statements about which vulnerabilities do and do not actually apply to their specific product — a "companion artifact" to the SBOM, functioning as a security advisory rather than a component inventory (Revenera). By pairing VEX statements with an SBOM, a team can distinguish "this library has a known CVE" from "this library has a known CVE that is actually reachable and exploitable in how we use it" — reducing the alert volume security teams have to triage (StateTech).

As of 2026, the combination of CycloneDX plus CSAF VEX has become the de facto industry default for "here is our SBOM, and here is our position on the vulnerabilities that affect it" (RunSafe Security).

A practical SBOM program, in order

1. Pick CycloneDX as your primary format unless a specific customer or regulatory requirement mandates SPDX (e.g., license-compliance-heavy government or enterprise procurement).
2. Automate generation in CI, not as a manual pre-release step — Trivy, Snyk, Grype, and similar tools make this a single pipeline stage.
3. Cover the CISA 2026 element set explicitly — verify your generated SBOMs include all nine metadata fields, eight component fields, and six practices/processes fields, not just a bare component list.
4. Pair with VEX statements for any component with a known CVE, so recipients aren't left triaging hundreds of theoretical vulnerabilities.
5. Version and distribute SBOMs per release, not as a single static document — a stale SBOM from six releases ago actively misleads anyone relying on it.

Actionable takeaway

If you don't have an SBOM program yet, start with a single CI-integrated generation step using an existing SCA scanner (Trivy or Snyk are the lowest-friction entry points) producing CycloneDX output, then layer VEX statements on top for any flagged CVE that isn't actually exploitable in your deployment. Don't wait for a specific customer or regulatory mandate to force this — CISA's 2026 minimum elements already explicitly cover SaaS and AI software, and the tooling cost of generating an SBOM today is a single pipeline step, not a project.

Sources: CISA — 2026 Minimum Elements, RunSafe Security, Kiuwan, Revenera, StateTech Magazine, OpenSSF