On this page
Key Takeaways
- SBOM is a living document. Section 524B(b)(2) requires postmarket monitoring; reviewers expect SBOM regeneration on every build and continuous vulnerability re-scan.
- VEX (Vulnerability Exploitability eXchange) is what prevents 1,000-CVE noise from drowning real risk. Treat it as a required companion to SBOM.
- End-of-support (EOS) tracking belongs in the SBOM workflow, not a side spreadsheet.
- Patch deployment cadence and triage SLAs live in the postmarket cybersecurity management plan, referenced from the SBOM process.
Pillar Guide · Updated 2026 · 15 min read
Talk to a MedTech cybersecurity expert
What postmarket SBOM maintenance actually requires
The 2026 final premarket cybersecurity guidance and the 2017 postmarket guidance together expect a continuous loop: regenerate SBOM on every build, scan it against fresh vulnerability data continuously, triage exploitable vulnerabilities against patient-safety risk, deploy patches per the postmarket plan, document it all.
The maintenance loop
- Build - SBOM generated automatically in CI/CD on every release candidate.
- Diff - new SBOM compared against last released SBOM; new components flagged for supplier evaluation.
- Scan - SBOM scanned against NVD, OSV, GitHub Security Advisories, and supplier feeds at least daily.
- Triage - each finding evaluated for exploitability in your specific configuration. VEX statement produced.
- Decide - exploitable findings enter the patch deployment queue; non-exploitable findings get a documented VEX rationale.
- Deploy - patches released per postmarket cadence; SBOM regenerated post-patch.
- Communicate - hospital customers and FDA notified per CVD policy and reporting obligations.
Cadence expectations
- SBOM regeneration: every build (typically nightly + on every release).
- Vulnerability scan: at least daily; ideally continuous via webhook from CVE feeds.
- Triage: within 5 business days for any new finding above informational severity.
- Critical-severity patch deployment: within 30 days of triage decision (more aggressive if patient-safety-impacting).
- End-of-support review: quarterly across all SBOM components.
VEX in detail
VEX (Vulnerability Exploitability eXchange) annotates each CVE affecting your SBOM with one of four statuses: not_affected, affected, fixed, or under_investigation. For not_affected, you state a justification (e.g., vulnerable function not invoked, configuration prevents exploitation). VEX is the artifact that turns a 1,000-CVE noise stream into a 50-CVE actionable queue. Reviewers and hospital customers both increasingly expect it.
VEX justification examples
- vulnerable_code_not_present - the affected function is not compiled into our binary.
- vulnerable_code_not_in_execute_path - the function exists but is unreachable from any input we accept.
- vulnerable_code_cannot_be_controlled_by_adversary - the function executes but inputs are constrained by a control we own.
- inline_mitigations_already_exist - a higher-layer control (WAF, kernel hardening) blocks the path.
End-of-support tracking
Every component in the SBOM should carry an end-of-support date. When a component approaches EOS (typically within 12 months), a migration plan enters the engineering backlog. End-of-support is a frequent reviewer question for postmarket follow-up: "what is your plan for [component X] when [supplier Y] stops patching it?" The answer needs to be documented before they ask.
Tooling stack we recommend
- SBOM generation: Syft, cdxgen, or language-native CycloneDX plugins.
- SBOM management: Dependency-Track or similar for storage, diff, and continuous scan.
- Vulnerability data: OSV, NVD, GitHub Security Advisories, supplier feeds.
- VEX format: OpenVEX or CycloneDX VEX.
- Hospital exchange: SBOM exchange via secure portal with versioning.
Reporting obligations
Section 524B(b)(2) and the postmarket guidance create reporting expectations for vulnerabilities that affect device safety or essential performance. The MAUDE / MDR pathway applies for vulnerabilities meeting the reportable-event threshold. Coordinated vulnerability disclosure (CVD) program intake is the entry point for many vulnerabilities reported by external researchers; CISA Coordinated Vulnerability Disclosure is the typical coordination partner for medical devices.
