The SBOM + VEX Playbook for FDA Premarket Submissions

Why this matters

Section 524B(b)(3) requires an SBOM for covered cyber-device submissions. The FDA recommends machine-readable industry-accepted formats without a minimum format version. Assess vulnerability monitoring under applicable duties and device-specific facts.

Key takeaway: Document device-specific vulnerability applicability and risk. VEX is an optional communication format; it does not replace the assessment or manufacturer approval.

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.

Our recommended SBOM coverage and metadata

• 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 component matching (company practice, not an FDA-prescribed field)
• Cryptographic hashes and SPDX license identifiers (company metadata choices, not FDA-prescribed minimums)

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