SBOM-to-VEX Vulnerability Triage Workflow for Medical Devices: From CVE Intake to Field Action Decision

What This Article Covers / Does Not Cover

This article covers one workflow: the postmarket SBOM-to-VEX vulnerability triage process. It describes how to intake new CVEs, match them to SBOM components, assess exploitability in the context of a specific medical device, author VEX justifications, make PSIRT and CAPA and FSCA decisions, and communicate with customers. It includes decision trees, RACI tables, timelines, and evidence record requirements.

It does not cover how to generate SBOMs, how to establish a PSIRT from scratch, general cybersecurity program design, or premarket submission requirements. For broader context on those topics, see Medical Device Cybersecurity, SBOM for Medical Devices, and Coordinated Vulnerability Disclosure / PSIRT.

Why This Workflow Matters in 2026

Several converging regulatory and industry developments have made the SBOM-to-VEX triage workflow a core operational capability for medical device manufacturers:

• Section 524B of the FD&C Act requires manufacturers of cyber devices to submit SBOMs to FDA and to maintain processes for postmarket vulnerability management. This is now law, not guidance.
• FDA's February 2026 revised cybersecurity guidance (aligned with the Quality Management System Regulation and ISO 13485) treats postmarket vulnerability management as a QMS-controlled process. Vulnerability triage decisions are quality records subject to design control and CAPA linkage.
• 2026 industry data paints a stark picture: 24% of healthcare organizations experienced cyberattacks directly targeting medical devices (RunSafe 2026 Medical Device Cybersecurity Index), and 80% of those organizations reported measurable impact on patient care.
• 35% of healthcare procurement decision-makers will not evaluate a device that lacks an SBOM (RunSafe 2026). SBOM availability is becoming a market access requirement, not just a regulatory one.
• FDA now expects VEX alongside SBOMs in premarket submissions. The SBOM/VEX workflow is both a premarket deliverable and a postmarket operational process. A Medcrypt 2026 deficiency analysis found that incomplete vulnerability exploitation analysis was among the top cybersecurity-related refusal-to-accept reasons.
• The operational challenge: high-volume scanner findings lack device-specific context, creating "vulnerability noise." A single device SBOM may contain 200+ components, each potentially matching dozens of CVEs. Without a structured triage workflow, PSIRT teams drown in false positives and cannot distinguish a cosmetic library vulnerability from a remotely exploitable patient safety risk.

For context on how this workflow fits into the broader premarket picture, see FDA Cybersecurity Premarket Deficiencies.

Workflow Overview: Seven-Stage Pipeline

The SBOM-to-VEX vulnerability triage process is a seven-stage pipeline. Each stage produces specific evidence records and feeds the next:

1. CVE Intake and Correlation — Monitor vulnerability sources, ingest new CVEs, enrich with threat intelligence.
2. SBOM Component Matching — Match CVEs to components in the device SBOM, flag candidates for analysis.
3. Exploitability Analysis — Determine whether each matched CVE is actually exploitable in the device's deployed configuration and operating environment.
4. VEX Justification Authoring — Document the exploitability determination in a machine-readable VEX statement.
5. PSIRT Severity Scoring and Decision — Score the vulnerability for device-specific severity (combining exploitability with patient safety impact) and assign response actions.
6. Customer Communication Trigger Assessment — Determine whether and when to issue a customer advisory.
7. CAPA / Field Safety Corrective Action Trigger Assessment — Determine whether the vulnerability triggers a CAPA, an FSCA, or both.

Each stage has defined inputs, outputs, decision criteria, and evidence requirements. The sections below detail every stage.

Stage 1: CVE Intake and Correlation

Sources

Effective vulnerability triage starts with comprehensive intake. The following sources should be monitored continuously:

• NVD (National Vulnerability Database) — Primary CVE repository, updated daily. API access enables automated ingestion.
• CISA KEV (Known Exploited Vulnerabilities) Catalog — Catalog of vulnerabilities with confirmed active exploitation. Inclusion here elevates urgency regardless of CVSS score.
• Vendor security advisories — Third-party component vendors (e.g., OpenSSL, Linux kernel distributions, Qt, Apache) publish their own advisories that may precede NVD publication.
• EPSS (Exploitation Prediction Scoring System) — Data-driven probability score estimating the likelihood that a CVE will be exploited in the wild within 30 days.
• Exploit-DB and public exploit repositories — Confirmed proof-of-concept exploit code availability.
• Internal penetration test findings — Vulnerabilities discovered during the manufacturer's own security testing.
• Commercial vulnerability intelligence services — Services such as Tenable, Qualys, or Black Duck provide enriched CVE data with device-relevant context.

Automated Ingestion

Daily automated feeds from the NVD API, CISA API, and commercial intelligence services should be the baseline. Manual monitoring supplements automated feeds for vendor-specific advisory sources that lack structured APIs.

Intake Record Data Fields

Each ingested CVE should be stored in an intake record with the following fields:

Output of Stage 1: Enriched CVE intake list ready for SBOM matching.

Stage 2: SBOM Component Matching

Matching Process

The SBOM (CycloneDX or SPDX format) contains an inventory of all software components in the device, including version numbers. Automated matching compares each component name and version against the CVE intake list:

• CycloneDX SBOM: component name + version fields matched against CVE affected component and version range.
• SPDX SBOM: package name + versionInfo fields matched similarly.

Handling False Positives

Component matching generates many false positives that must be filtered before exploitability analysis:

• Component name collisions: A component named "utils" in the SBOM may match a CVE for a different "utils" library. Matching should include vendor/namespace, package URL (purl), or CPE where available.
• Version range mismatches: A CVE may affect "OpenSSL 1.1.1 to 1.1.1l" while the SBOM lists "OpenSSL 1.1.1m." Automated range comparison must account for semantic versioning.
• Transitive dependency resolution: A vulnerable component may be a transitive dependency pulled in by a direct dependency. The SBOM must include nested dependencies, and the matching process must traverse the full dependency tree.

Matching Accuracy Classification

Output of Stage 2: Matched CVE list per device/software version, with match confidence classification.

Evidence Record

• SBOM version and generation date
• Matching date
• Matching tool name and version
• List of matched components with CVE IDs and match types
• List of excluded components with exclusion rationale

Stage 3: Exploitability Analysis

This is the critical stage. Not every CVE present in an SBOM component affects the device. A vulnerable library included in a build but never called, or a vulnerable code path behind a disabled feature flag, is not an exploitable risk. Exploitability analysis is what separates signal from noise.

Analysis Factors

Exploitability Decision Tree

Apply the following decision tree sequentially. Stop at the first definitive "Not Affected" determination.

Step 1: Is the vulnerable code path reachable in the device?

• NO → VEX Status = Not Affected. Justification = vulnerable_code_not_in_execute_path. Record the analysis that demonstrated unreachable code. Stop.
• YES → Continue to Step 2.

Step 2: Is the vulnerable feature enabled in the device's configuration?

• NO → VEX Status = Not Affected. Justification = vulnerable_code_not_present (if the code is compiled out) or vulnerable_code_not_in_execute_path (if the code is present but the feature is disabled at runtime). Document the configuration that disables the feature. Stop.
• YES → Continue to Step 3.

Step 3: Is the component exposed to the network or attack surface?

• NO → VEX Status = Not Affected. Justification = attack_requires_local_access or equivalent. Document the network architecture that isolates the component. Stop.
• YES → Continue to Step 4.

Step 4: Are there compensating controls that mitigate the vulnerability?

• YES → VEX Status = Not Affected. Justification = inline_mitigations_already_exist. Document each compensating control and how it addresses the specific vulnerability. Stop.
• NO → VEX Status = Affected. Proceed to Stage 5 for PSIRT severity scoring.

Output of Stage 3: Exploitability determination for each matched CVE, with documented rationale.

Stage 4: VEX Justification Authoring

VEX (Vulnerability Exploitability eXchange) is a companion document to the SBOM. While the SBOM says "here is what is in the device," VEX says "here is the status of each known vulnerability in those components." The CISA Minimum Requirements for Vulnerability Exploitability eXchange (April 2023) define the baseline structure. The CycloneDX VEX specification (ECMA-424) provides the canonical machine-readable format.

CISA VEX Minimum Elements

Every VEX statement must contain:

1. VEX status — The exploitability determination.
2. VEX justification — The reason for the status determination.
3. Impact statement — A description of the impact (or lack thereof) on the product.
4. Action statement — What the manufacturer recommends or plans to do.

VEX Status Values

Per CISA/CycloneDX, the standard VEX status values are:

VEX Justification Codes

VEX Document Formats

Three formats are in active use:

• CycloneDX VEX (ECMA-424) — JSON or XML. Aligns directly with CycloneDX SBOM format. Recommended for manufacturers already using CycloneDX SBOMs.
• CSAF VEX (Common Security Advisory Framework) — JSON. Aligns with the CSAF standard used by enterprise software vendors.
• OpenVEX — Minimal, signed, machine-readable format developed in the open-source community. Growing adoption in cloud-native ecosystems.

Sample VEX Statements

The following table illustrates VEX statements for different triage outcomes:

Evidence Record for Each VEX Statement

• CVE ID
• SBOM component name and version
• Analysis performed (reachability analysis, configuration review, penetration test, etc.)
• Analyst name
• Analysis date
• Supporting evidence links (code review results, configuration screenshots, test reports)
• VEX statement version (VEX documents must be versioned and re-evaluated as new information emerges)

Stage 5: PSIRT Severity Scoring and Decision

PSIRT severity is not the same as CVSS severity. CVSS measures the technical characteristics of a vulnerability. PSIRT severity combines exploitability with patient safety impact specific to the device. A CVSS 9.8 vulnerability in a non-reachable code path has a PSIRT severity of zero. A CVSS 6.5 vulnerability in a life-sustaining device with remote exploit potential may have a PSIRT severity of Critical.

For broader PSIRT operational context, see Coordinated Vulnerability Disclosure / PSIRT.

PSIRT Severity Matrix

"Patient impact" is assessed through the clinical risk analysis process described in ISO 14971 Risk Management. It considers the device's intended use, the clinical consequences of a cybersecurity breach (delayed treatment, incorrect dosage, loss of monitoring), and the severity of harm.

PSIRT Decision Table

PSIRT Owner RACI Table

Stage 6: Customer Communication Trigger Assessment

Not every vulnerability requires a customer advisory. Over-communication erodes trust and creates alert fatigue. Under-communication violates regulatory expectations and exposes patients to risk. The decision must be deliberate and documented.

FDA Cybersecurity Management Plan Expectations

FDA's cybersecurity guidance expects manufacturers to include customer communication procedures in their Cybersecurity Management Plan. The plan should define:

• Criteria for when a customer advisory is issued versus a silent patch
• The content and format of customer advisories
• The timeline for advisory issuance relative to vulnerability discovery
• The communication channels (direct letter, email, safety portal posting, software update notification)

Communication Trigger Criteria

Customer Advisory Template Fields

Every customer advisory should include:

1. Vulnerability description — Clear, non-technical summary of what the vulnerability is and how it could be exploited.
2. Affected devices and versions — Specific model numbers, software versions, and hardware revisions.
3. Clinical impact — What could happen to the patient if the vulnerability were exploited, stated in clinical terms.
4. Compensating controls — Actions the customer can take immediately to reduce risk (e.g., network segmentation, disabling a feature, applying a configuration change).
5. Patch availability timeline — When a fix will be available, or confirmation that a fix is already available.
6. Workaround instructions — Step-by-step instructions for any interim mitigations.
7. Contact information — How to reach the manufacturer for questions or support.
8. CVSS and PSIRT severity — Both the technical CVSS score and the device-specific PSIRT severity.

Stage 7: CAPA / Field Safety Corrective Action Trigger Assessment

The final stage determines whether the vulnerability triggers formal quality system actions: a CAPA, a Field Safety Corrective Action (FSCA), or both. This determination is a QMS-controlled decision and must be documented in the quality record.

For background on the CAPA process, see CAPA for Medical Devices. For post-market surveillance obligations, see Post-Market Surveillance.

CAPA and FSCA Trigger Thresholds

FSCA: Required vs. Voluntary

An FSCA is required when:

• The vulnerability has caused or could cause death or serious injury.
• The vulnerability requires a field action (patch, recall, software update) to correct.
• Regulatory authorities (FDA, EU Competent Authority, TGA, etc.) would expect notification under their adverse event reporting frameworks.

A voluntary field safety notice is appropriate when:

• The vulnerability is mitigated by compensating controls but the manufacturer chooses to proactively inform customers.
• A patch is available but the risk does not meet the threshold for a mandatory field action.
• The manufacturer wants to demonstrate proactive risk management to customers and regulators.

Evidence Records for CAPA/FSCA Decisions

• PSIRT severity score and rationale
• Patient impact assessment from Clinical/Safety Officer
• Regulatory impact assessment from Regulatory Affairs
• Compensating control effectiveness evaluation
• Decision rationale: why CAPA was or was not initiated, why FSCA was or was not triggered
• Linkage to the manufacturer's Post-Market Surveillance plan
• For EU MDR devices: linkage to PSUR/PMSR reporting schedule. Vulnerability trends and FSCA decisions must be reflected in the Periodic Safety Update Report.

Timeline and SLA Summary

The following table defines target durations for each stage of the triage pipeline, from CVE publication to closure:

Total elapsed time from CVE publication to customer advisory for a Critical severity finding: target is 5–7 business days. For Low severity findings: target is 30–60 days, with remediation in the next scheduled release.

Pre-Triage Validation Checklist

Before a vulnerability triage event occurs, confirm the following operational readiness items. Gaps in any of these will slow or compromise the triage process.

• SBOM is current and accurately covers every deployed device software version (including legacy/fielded versions)
• SBOM includes transitive dependencies, not just direct dependencies
• Automated CVE feeds (NVD API, CISA API) are active, monitored, and logging ingestion status
• Commercial vulnerability intelligence feeds are configured if used
• Component matching tool is validated for accuracy — spot-check against known CVE/component pairs quarterly
• Component matching handles name collisions via purl, CPE, or vendor namespace
• Reachability analysis tooling is configured for the device software architecture
• Device threat model is current and documents the attack surface, trust boundaries, and network exposure for each component
• VEX justification codes are pre-approved by the security team and legal review
• VEX document template is established in CycloneDX VEX, CSAF VEX, or OpenVEX format
• PSIRT severity scoring rubric is documented, agreed by cross-functional stakeholders, and version-controlled
• PSIRT RACI matrix is current and escalation paths are tested
• Customer communication templates are pre-approved by Legal, Regulatory, and Communications
• CAPA trigger criteria are documented in the QMS and linked to the PSIRT process
• FSCA decision criteria are documented, including regulatory notification requirements by market (FDA, EU, TGA, etc.)
• Evidence records template is ready and includes all required fields (analyst, date, rationale, supporting evidence)
• Escalation path to Clinical/Safety Officer is defined with contact information and response time expectations
• PSIRT after-action review process is defined for continuous improvement
• Quarterly tabletop exercise schedule is established to validate the triage workflow end-to-end
• VEX document re-evaluation schedule is defined — VEX is a living document, not a one-time deliverable

Common Failure Modes

The following failure patterns recur across medical device vulnerability triage operations:

Treating all CVEs in the SBOM as "affected" without reachability analysis. This is the most common and most damaging failure mode. A device with 200 SBOM components may have 1,000+ CVE matches. Declaring all of them "affected" creates vulnerability noise, panics customers, overwhelms the PSIRT team, and erodes credibility with regulators. The exploitability analysis in Stage 3 exists specifically to prevent this. Every "Not Affected" VEX statement must still be documented with rationale — but the operational burden of documenting "not affected" is far less than the burden of patching and communicating about vulnerabilities that do not actually affect the device.

Using CVSS score alone for triage without patient safety context. A CVSS 9.8 in a non-reachable code path has zero device impact. A CVSS 6.5 in a life-sustaining device with remote attack surface may be life-threatening. The PSIRT severity matrix in Stage 5 exists to combine technical severity with clinical context. Teams that triage by CVSS alone will over-index on technically severe but operationally irrelevant findings and under-index on clinically significant risks.

Not maintaining VEX as a living document. VEX is not a snapshot — it is a living document that must be re-evaluated as new exploit information emerges. A CVE initially assessed as "Not Affected" because no exploit existed may need to be re-assessed if a public exploit is published or the CVE is added to CISA KEV. VEX documents must be versioned and re-issued when determinations change.

Failing to document the analysis trail. FDA inspectors and EU auditors want to see the decision rationale for every vulnerability triage outcome. An undocumented "we looked at this and decided it was not a problem" is insufficient. The evidence records defined in each stage are the quality trail. Missing evidence is a CAPA finding in itself.

Not linking PSIRT decisions to the CAPA system. Vulnerability management is a quality process. If the PSIRT identifies a recurring vulnerability trend in a third-party component but never initiates a CAPA to address the systemic procurement or architecture issue, the quality system has a gap. PSIRT outcomes must feed the CAPA system when trigger criteria are met.

Slow intake from CISA KEV. CISA KEV lists vulnerabilities with confirmed active exploitation. Delayed intake means deployed devices remain exposed to actively exploited vulnerabilities. The RunSafe 2026 Cybersecurity Index found that 28% of healthcare organizations operate devices past end-of-support, and 44% report using devices with known, unpatched vulnerabilities — figures that reflect both delayed intake and delayed remediation.

How to Remediate Process Gaps

If your organization has identified gaps in the SBOM-to-VEX triage workflow, follow this structured remediation process:

1. Identify the gap. Map the current process against the seven-stage pipeline and the pre-triage validation checklist. Document each gap with a specific description of what is missing or inadequate.

2. Update the SOP. Revise the applicable standard operating procedure to address the gap. If no SOP exists for the triage workflow, create one. The SOP should reference the stages, decision criteria, evidence records, and SLAs defined in this article.

3. Train the team. Conduct role-specific training for every RACI participant. Security engineers need training on reachability analysis and VEX authoring. Regulatory Affairs needs training on FSCA trigger criteria. Clinical/Safety Officers need training on cybersecurity-to-clinical-impact translation.

4. Validate with a tabletop exercise. Run a simulated vulnerability triage event end-to-end. Inject a realistic CVE scenario (e.g., a CVSS 8.1 vulnerability in OpenSSL affecting a networked infusion pump) and walk the team through all seven stages. Identify where the process breaks, where evidence records are incomplete, and where SLAs are missed.

5. Update QMS records. Document the gap remediation in the quality management system. This is itself a quality record — it demonstrates to auditors that the organization identified a process weakness, corrected it, and validated the correction.

For organizations building or formalizing their PSIRT, see Coordinated Vulnerability Disclosure / PSIRT. For the broader cybersecurity compliance framework, see Medical Device Cybersecurity. For SBOM generation and management, see SBOM for Medical Devices.