The FDA-Compliant SBOM + VEX Playbook

Why this matters

Under the FDA's 2026 final premarket guidance, every cyber device submission must include a machine-readable SBOM in SPDX 2.3+ or CycloneDX 1.4+ format, plus an ongoing process for monitoring vulnerabilities in those components. PDF SBOMs and spreadsheets are no longer acceptable as the SBOM itself.

Key takeaway: An SBOM without VEX is noise. VEX is what turns 'this CVE matched a component' into 'and here's whether it's actually exploitable in our device' - which is the question reviewers and customers actually ask.

SPDX vs. CycloneDX - pick one

• SPDX 2.3+ - Linux Foundation standard. Strong on license metadata. Widely accepted.
• CycloneDX 1.5 - OWASP standard. First-class VEX, ML-BOM, SaaS-BOM. Our default for medical devices.
• If your downstream tooling needs SPDX, generate both - but keep CycloneDX as source of truth.

What MUST be in your SBOM

• Every third-party dependency (direct + transitive)
• OS / RTOS, kernel, bootloader, signed firmware blobs
• Statically linked open-source libraries in firmware
• Container base images and layers (for cloud back-ends)
• PURL identifiers for every component (reviewers use these to map CVEs)
• Cryptographic hashes (SHA-256 minimum) and SPDX license identifiers

VEX status values (CycloneDX)

• not_affected - vulnerable code present but cannot be exploited (must include justification)
• affected - device is exploitable; triage and patch
• fixed - was affected; patch shipped in version X
• under_investigation - triage in progress (escalate if >30 days)

What's in the full PDF

• Generation strategy table per device type (SaMD, mobile, embedded, hybrid)
• All five acceptable not_affected justifications with examples
• 30-day operating cadence: build → daily → weekly → monthly → quarterly
• What FDA reviewers specifically look for in your SBOM section