Medical device SBOM and vulnerability management for FDA
Ingest SBOMs from your build pipeline, match every component against known software in the NVD, and see each advisory ranked by whether it is genuinely being exploited. Then export the FDA-ready evidence in a click.
Features
Most SBOM tools give you volume. You need the short list.
The alert count is not the problem. The wrong alerts are.
Most tools match components loosely, and one bad match cascades. In independent testing a competitor mapped a single npm package to unrelated Adobe software and produced 31 irrelevant alerts from that one error. Matching every component against known software in the NVD, with alias rules for the ambiguous ones, is what keeps the queue worth reading.
An SBOM is never reviewed once
New advisories land against the SBOM you already have, and the dispositions you set import forward into the next version rather than being retyped. Alias and lifecycle rules apply themselves to every SBOM you have already uploaded and every one you upload later, so a new release means reviewing a short diff rather than the whole bill of materials.
Measured against the open-source and commercial SBOM tools teams commonly use
In three head-to-head tests against widely used open-source and commercial SBOM tools, Medcrypt averaged 96% accuracy where those tools ranged from 63% to 92%, and matched all 117 components in the test SBOM. The platform is tuned by former FDA reviewers, so what it reports is what a reviewer expects to see.
How it runs
From SBOM to FDA submission.
Three steps. Importing an SBOM and generating a report are the easy parts. The hard part is sorting hundreds of vulnerabilities down to the handful that actually need your attention. That's where we focus.
However your SBOM is produced, it lands here.
Push CycloneDX or SPDX from your build pipeline through the Helm API, a GitHub action, or the Azure DevOps extension, or upload one by hand. Every component is then matched against known software in the NVD, and alias rules resolve the ambiguous ones automatically across existing and future SBOMs. That matching step is where accuracy is won or lost: one component mapped to the wrong package is what turns into dozens of irrelevant alerts downstream.
Components
ComponentMatch statusopensslMatched to NVDbusyboxMatched to aliaszlibMatched to CPElibwebpSelect matchCycloneDX 1.3–1.5 and SPDX 2.2–2.3Exploitability evidence first, then your call.
Every advisory arrives scored against EPSS, the CISA KEV list, the Exploit Database, Metasploit and the CWE Top 25, so you can see what is genuinely being exploited rather than sorting by CVSS alone. Impacted tech stacks narrow it further. Your team then sets the disposition, and marking something not affected asks for the justification that makes it defensible later.
Vulnerabilities
Vuln IDCVSSTech stackStatusCVE-2022-3602openssl7.5AffectedExploitableCVE-2023-4863libwebp8.8Not impactedNot affectedCVE-2023-38545curl7.5AffectedIn triageCVE-2023-44487nghttp27.5Not impactedNot affectedCVE-2024-2961glibc5.9Not impactedResolved214 advisories matched12 need actionThe submission artifact is a byproduct, not a project.
Export the FDA-ready SBOM alongside VEX and VDR reports, for one product version or several at once. Each report is a snapshot in time kept in your report history, so an auditor asking what you knew last March gets an answer rather than a reconstruction. And as exploit maturity and fix availability change upstream, findings rescore themselves so the next report reflects it.
Reports
FDA-ready SBOMCycloneDX SBOMSPDX SBOMCycloneDX VEXExploitability statementsCycloneDX VDRVulnerability disclosure reportReport historyGenerate reports
What you get
What lands in your hands.
A component inventory that stays current
- Every component across every product version, with license data, corrected CPEs and PURLs, and end-of-support metadata applied by rule rather than by hand.
A queue ranked by real risk
- Advisories filtered by EPSS score, KEV listing and known exploit code, each carrying suggested short-term mitigations and specific upgrade recommendations, so triage starts with what is being exploited instead of with row one.
A hook into the build you already run
- The Helm API, a GitHub action, and a Microsoft Azure DevOps extension, so a new build produces a new SBOM analysis without anyone remembering to start one.
Submission-ready reports on demand
- The FDA-ready SBOM, CycloneDX and SPDX exports, VEX and VDR reports, for a single product or a whole portfolio, with a retained history for audits.
FDA requirements
What FDA expects in a medical device SBOM
Required by law
Section 524B requires an SBOM covering commercial, open-source and off-the-shelf software for cyber devices.
Machine-readable
FDA asks for a machine-readable format such as SPDX or CycloneDX.
End-of-support dates
Each component needs its support level and end-of-support date.
Every vulnerability assessed
Every known vulnerability needs an assessment of its impact on safety and effectiveness.
How Medcrypt helps
Medcrypt keeps each of these current from design through postmarket, so the SBOM in your submission matches the device you ship.
Medical device SBOM FAQs
Yes, for cyber devices. Section 524B of the FD&C Act requires an SBOM as part of the premarket submission.
FDA asks for a machine-readable format, such as SPDX or CycloneDX.
So reviewers can see whether each component will keep receiving security updates over the device's life. Generic statements such as "supported by the vendor" are not enough.
FDA expects a machine-readable SBOM, and the common formats are SPDX and CycloneDX. For each component, include the supplier, version, support level and end-of-support date.
A VEX (Vulnerability Exploitability eXchange) statement records whether a known vulnerability actually affects your device, with a justification such as 'component not present' or 'vulnerable code not reachable'. It lets you show FDA you've assessed every CVE match without patching ones that can't be exploited.
Start with each supplier's published lifecycle or support policy. If a supplier doesn't publish one, document how you determined the date and how you'll monitor it. FDA has not accepted generic statements like 'supported by the vendor'.
With every software release or build change, and keep it current after launch so vulnerability monitoring always runs against what's actually in the field.