Question 1

What exactly does FDA require in an SBOM for a 510(k) or PMA submission?

Accepted Answer

FDA's Section 524B premarket cybersecurity guidance and the 2023 RTA policy expect a machine-readable SBOM (CycloneDX or SPDX) covering all software components in the device - first-party code, third-party libraries, open-source dependencies, operating system, and bootloader. Each component needs name, version, supplier, license, cryptographic hash, and known vulnerabilities. The SBOM must be accompanied by a description of the SBOM-generation methodology, a policy for vulnerability monitoring, and a plan for postmarket SBOM updates. We deliver all of these as a packaged appendix to the cybersecurity submission.

Question 2

CycloneDX or SPDX - which format does FDA prefer?

Accepted Answer

Both are accepted. FDA does not mandate a specific format - they require a machine-readable SBOM that can be parsed and matched against vulnerability databases. CycloneDX (OWASP) tends to have richer security metadata (vulnerabilities, VEX, services); SPDX (Linux Foundation) has stronger licensing metadata and is the standard most legal teams already use. Most of our MedTech clients use CycloneDX for the security workflow and produce an SPDX export when legal asks. We support both natively and convert between them automatically as part of the monitoring pipeline.

Question 3

How do you handle false-positive CVEs that don't actually affect the device?

Accepted Answer

Vulnerability scanners match by component name and version, which produces a high false-positive rate - the CVE may exist in the library but the vulnerable function is never called, the affected feature is disabled, or the device's deployment context makes the vulnerability unreachable. We triage every match against your device-specific context (call graph, configuration, network exposure, threat model) and document the disposition in a VEX (Vulnerability Exploitability eXchange) document. The VEX is the same evidence FDA expects to see for unaffected determinations - it's not optional triage hygiene, it's the regulatory artifact.

Question 4

How often does the SBOM need to be regenerated and the CVE matching refreshed?

Accepted Answer

SBOM regeneration: every release that changes any software component, period. CVE matching: continuously, with a daily run minimum, because new vulnerabilities are published every day and the time-to-exploit gap is narrowing. Our managed monitoring runs daily matching against NVD, OSV, GitHub Security Advisories, and supplier-specific feeds; surfaces only the CVEs that survive device-context triage; and produces monthly evidence summaries for the postmarket cybersecurity record. The cadence is non-negotiable for Section 524B compliance.

Question 5

Can you integrate SBOM generation into our existing CI/CD pipeline?

Accepted Answer

Yes. We add SBOM generation as a build-time step in your existing pipeline (GitHub Actions, GitLab CI, Jenkins, Azure DevOps, Bitbucket) using Syft, CycloneDX-CLI, or your build tool's native SBOM emitter. The pipeline produces a signed SBOM artifact attached to every build, pushes it to your SBOM repository (Dependency-Track, GUAC, or our hosted vault), and triggers vulnerability matching on every change. The integration takes 1-2 weeks for a typical MedTech CI/CD setup. We provide the templates, do the integration work, and hand off operational runbooks to your engineering team.

Question 6

What about firmware and embedded components - how do you SBOM those?

Accepted Answer

Firmware SBOMs are produced through a combination of build-time emission (when you control the build) and binary analysis (when you don't - third-party RTOS, bootloader, vendor blobs). For build-time, we integrate with Yocto, Buildroot, or your toolchain to emit SBOMs at compile time. For binary analysis, we extract firmware images, identify components by hash, signature, and string analysis, and produce a SPDX/CycloneDX SBOM with provenance notes. Both paths produce FDA-acceptable evidence; binary analysis is documented as such so reviewers understand which entries are derived versus declared.

Question 7

How do we handle SBOMs for components from suppliers who won't share theirs?

Accepted Answer

More common than it should be. Three options. (1) Contractual: amend supplier agreements to require SBOM delivery on every release - we provide the contract language. (2) Reconstruction: do binary analysis of the supplier-provided component and produce an inferred SBOM with documented provenance. (3) Substitution: if neither works for a critical component, we identify alternatives and help with the supplier transition. FDA accepts inferred SBOMs as long as the methodology is documented and the limits are stated clearly - 'unknown' is acceptable in specific entries; an unexplained gap is not.

Question 8

What's the relationship between the SBOM, the threat model, and the risk file?

Accepted Answer

These three artifacts have to be linked, not produced in isolation. The SBOM identifies what's in the device; the threat model describes how those components could be attacked; the safety-risk file (ISO 14971) translates exploitable threats into clinical safety consequences. We deliver them as a linked artifact set so a single critical CVE can be traced from SBOM entry → threat model node → risk-control mitigation → verification evidence → residual risk decision. FDA reviewers explicitly look for this traceability; submissions that produce these artifacts in silos generate AIRs.

Question 9

Can you respond to a specific FDA SBOM deficiency on an active submission?

Accepted Answer

Yes - rapid SBOM remediation is a routine engagement. Common deficiencies include: missing SBOM, non-machine-readable SBOM (PDF tables don't count), no vulnerability monitoring policy, missing VEX for matched CVEs, no postmarket update plan. We've turned around full SBOM packages in 2-4 weeks against the 180-day FDA response window, including binary-analysis SBOM reconstruction where the original was incomplete. Send us the AIR and we'll scope a fixed-fee response on the 30-min call.

Question 10

Do we own the SBOM tooling and data, or is it locked in your platform?

Accepted Answer

You own everything. The SBOMs themselves are standard CycloneDX/SPDX files in your repository. The vulnerability matching, VEX, and triage records are exported in standard formats on demand. If you use our hosted monitoring vault, the export is one click; if you prefer a self-hosted setup (Dependency-Track, GUAC, or your own GRC tool) we'll deploy and operate that instead. The portability is intentional - you should never feel locked into a security vendor for an obligation you have to maintain across a 10-year device lifecycle.

Stay Ahead of CVEs. Audit-Ready Always.

Surfaces a reviewer-grade SBOM must cover

Reviewer-ready deliverables in one engagement

Public premarket cybersecurity history

Log4Shell (CVE-2021-44228) in medical devices

Curl + libcurl high-severity disclosure (CVE-2023-38545)

Urgent/11 IPnet TCP/IP stack vulnerabilities

FDA-Compliant SBOM Services for these segments

Resources on this topic

Guides

Articles

Try the free tool first.

SBOM Readiness

SBOM Diff & VEX Drafter

Third-Party Component Risk Scorecard

Postmarket Cadence Calculator

FDA-compliant SBOM FAQs

SBOMs FDA reviewers can parse - not spreadsheets renamed .json.