SBOM vs VEX: What's the Difference? (Medical Device Guide)

An SBOM lists what's in your software. A VEX explains which of those things actually matter from a security standpoint. Both are required for a modern FDA submission — but they answer different questions, and confusing them is the fastest way to a cybersecurity deficiency.

If you've spent any time reading the FDA's February 2026 premarket cybersecurity guidance, you've seen "SBOM" and "VEX" used together so often that they blur. They are not the same document and they don't serve the same purpose. This guide breaks down the difference in plain English, with the level of detail an FDA reviewer actually uses when reading your package.

TL;DR — at a glance

	SBOM	VEX
Stands for	Software Bill of Materials	Vulnerability Exploitability eXchange
Question it answers	What components are in this device?	Which CVEs against those components actually affect us?
Format	SPDX or CycloneDX	CSAF 2.0, CycloneDX VEX, or OpenVEX
Refresh cadence	Per build / per release	Monthly minimum during FDA review
FDA expectation	Required under Section 524B(b)(3)	Effectively required to answer SBOM-driven CVEs
Without it	The reviewer can't see what's in your device	The reviewer sees unanswered CVEs and asks why

What an SBOM actually is

An SBOM is an inventory. For every piece of software shipping on or with your medical device — firmware libraries, OS packages, application dependencies, container images — the SBOM records:

• Component name and version (openssl 3.0.7)
• A globally unique identifier (PURL or CPE)
• License
• Supplier
• Cryptographic hash
• Dependency relationships (what depends on what)

That's it. An SBOM is a list. It does not say anything about whether any of those components have known vulnerabilities. That's the next step.

The FDA expects the SBOM to be machine-readable — either SPDX or CycloneDX — so a reviewer can run automated tools against it. If you're choosing between the two, our CycloneDX vs SPDX comparison covers the tradeoffs.

What a VEX actually is

A VEX is an assessment. It takes the list of CVEs that fall out of running a vulnerability scanner against your SBOM and tells the reviewer, for each CVE:

• Are we affected by this CVE?
• Are we not affected? If so, why? (Vulnerable code not present? Not in the execute path? Mitigated by configuration?)
• Has it been fixed? (In which version, by what means?)
• Is it under investigation? (Who owns it, when's the close date?)

A VEX is the document that turns a noisy CVE list into a reviewer-readable narrative. Without one, the FDA sees 47 open CVEs in your dependencies and has no way to know which ones you've already addressed.

For the full mechanics — fields, formats, justification codes — read our VEX document guide for medical devices.

How they work together

Think of it as a two-step pipeline the FDA reviewer mentally runs:

  SBOM ──▶ Vulnerability scan ──▶ CVE list ──▶ VEX ──▶ "Closed for review"

1. Your SBOM lists every component.
2. A vulnerability scanner (NVD, OSV, Snyk, etc.) maps each component to known CVEs.
3. The VEX answers, for each CVE, whether your device is actually affected.
4. The reviewer marks the cybersecurity section as adequately addressed.

If any step in that chain breaks, the reviewer writes a deficiency. The most common break point is step 3 — the VEX is missing, stale, or vague. We covered the failure modes in detail in 5 VEX mistakes that trigger FDA deficiencies.

Why you can't substitute one for the other

The single most common misconception we see: "We have an SBOM, so we don't need a VEX."

That is the same as saying "we have a parts list, so we don't need a safety analysis." The SBOM is raw material. The VEX is the reasoning the reviewer needs. A submission with only an SBOM forces the reviewer to do the VEX work themselves — and they won't. They'll issue a deficiency and hand it back.

The reverse mistake — submitting a VEX without an SBOM — never happens because the VEX references SBOM components by PURL or CPE. Without the SBOM as ground truth, the VEX has nothing to reference.

How the FDA actually reads your SBOM and VEX

A reviewer's workflow is roughly this:

1. Open the SBOM. Confirm it's machine-readable, has NTIA minimum elements (supplier, component, version, unique identifier, dependency relationship, author, timestamp), and matches the device's stated software architecture.
2. Run a CVE scan against the SBOM's components.
3. Open the VEX. Cross-reference every CVE the scan produced against the VEX entries. Sort by CVSS, highest first.
4. Read every not_affected justification — especially on CVSS ≥ 7.0 entries.
5. Check for SBOM/VEX drift — component versions, generation dates, build hashes.

Anywhere this workflow stalls (missing entry, stale timestamp, vague justification, format mismatch), you get a finding. Anywhere it flows cleanly, the reviewer moves on.

Refresh cadence — the silent killer

Sponsors often treat SBOM and VEX as deliverables they generate once at submission. Both should regenerate continuously:

• SBOM: every build. Tie it into CI so it's never more than one commit out of date.
• VEX: monthly minimum during active FDA review, plus immediately when a new high-CVSS CVE drops against any component in your SBOM.

Why? Because the FDA reviewer reads the document on the day they pick up the file, not the day you submitted it. A VEX generated five months before review is almost certainly out of sync with the current CVE landscape, and reviewers know it.

The three SBOM formats and the three VEX formats

You'll see a lot of acronyms. Here's the practical map:

Document	Format options	When to choose which
SBOM	CycloneDX	Best when you also need VEX, SaaSBOM, or HBOM — broadest tool support in MedTech CI/CD
SBOM	SPDX	Fine for OS/firmware-heavy devices; mandated in some non-FDA contexts
VEX	CycloneDX VEX	Pair with CycloneDX SBOM. Embed inline plus ship standalone
VEX	CSAF 2.0 VEX	Pair with SPDX SBOM. Best when coordinating with CISA / ICS-CERT
VEX	OpenVEX	Lightweight, schema-simple, good for high-volume automation

The FDA accepts all combinations. The deciding factor is operational fit with your build pipeline, not the FDA's preference.

Decision aid — which document fixes which problem?

Reviewer concern	Document that addresses it
"What's in this device?"	SBOM
"Are you tracking your dependencies?"	SBOM
"Why is this CVE in your software not addressed?"	VEX
"Is this CVE actually exploitable on this device?"	VEX
"How do you know your SBOM is current?"	SBOM regeneration policy + cover letter
"How do you know your VEX is current?"	VEX regeneration policy + cover letter

If a reviewer's question maps to the wrong column in your response, that's a sign your team is still treating these two documents as one.

Frequently asked questions

Do I need both an SBOM and a VEX for the FDA?

Effectively yes. Section 524B(b)(3) requires an SBOM. The February 2026 final premarket guidance requires you to assess every component for known vulnerabilities — and a VEX is the only practical way to deliver that assessment in machine-readable form. Submissions that include only an SBOM are routinely flagged with cybersecurity deficiencies.

Can VEX statements live inside my SBOM?

CycloneDX supports embedding VEX statements directly in the SBOM. That's allowed and convenient. But reviewers also want a standalone, schema-valid VEX file for independent parsing — so ship both. SPDX SBOMs cannot embed VEX statements; you pair them with a separate CSAF or OpenVEX file.

Is a vulnerability scan report the same as a VEX?

No. A scan report is the raw output — every CVE matched against your SBOM. A VEX is the curated assessment of those CVEs that tells the reviewer which ones matter and which ones don't, with justifications. The scan is input; the VEX is output.

What happens if a new CVE lands after I submit?

It depends on severity and timing. For a high-CVSS CVE landing during FDA review, the right move is to regenerate the VEX, add the new entry with affected or not_affected status and a justification, and send an unsolicited amendment to the reviewer. Doing nothing and hoping is how you end up with a hold letter — see our breakdown of deficiency vs RTA vs hold letters.

Does this apply to non-FDA submissions like EU MDR?

The same logic applies. EU MDR Annex I requires evidence of cybersecurity risk management, and a current SBOM + VEX is the cleanest way to provide it. The format expectations are similar — CycloneDX or SPDX for SBOM, any major VEX format for the assessment.

Need help building this?

If you're standing up SBOM and VEX from scratch — or your current pair just got flagged in an FDA deficiency letter — we can help. We've shipped clean SBOM + VEX pairs on 250+ submissions and can triage your current package under NDA in 24 hours.

• Read the VEX document guide for the full format reference
• Read 5 VEX mistakes that trigger FDA deficiencies for the failure modes to avoid
• Choosing between SBOM formats? See CycloneDX vs SPDX for medical devices
• Already received an FDA cybersecurity letter? Start with which letter you got, then book a response call