From SBOM to VEX: managing medical device vulnerabilities without drowning the team

Your SBOM is in place: generated on every release, in the right format, compliant with FDA and CRA requirements. Then you run your first vulnerability scan, and the report lands: dozens, sometimes hundreds of CVEs. The team cannot fix them all — and the regulator expects a documented decision on every single one. Between the inventory and compliance, one piece is missing: the scan → triage → VEX pipeline that turns a flood of alerts into defensible impact analyses.

Why does an SBOM alone protect nothing?

Definition: vulnerability monitoring means continuously matching the SBOM against public databases (NVD, GitHub Advisories, OSV) to detect CVEs published after the product reached the market. The SBOM is a snapshot; the threat landscape changes daily. A component that was healthy on release day can become the weakest link in your installed base six months later — Log4Shell reminded everyone of that.

This is exactly what the regulations require. Section 524B(b)(1) of the FD&C Act mandates a plan to “monitor, identify, and address” post-market vulnerabilities, coordinated disclosure included — the heart of the cybersecurity plan the FDA expects. IEC 81001-5-1 requires a vulnerability monitoring and handling process across the whole life cycle — one of the five workstreams when catching up on an existing codebase. The MDR (Art. 83) extends post-market surveillance to software. The CRA adds a deadline: notify any actively exploited vulnerability within 24 hours.

Here is the point teams coming from classic DevSecOps often miss: in medical devices, it is not the main branch you need to watch — it is the fleet in the field. A CVE hitting the version installed in forty hospitals matters more than a CVE fixed on the next release.

What does the pipeline look like?

Three stages, all automatable:

• Generate an SBOM on every release (Syft, or your ecosystem’s CycloneDX plugin) — and archive it as a quality system record: one version, one SBOM.
• Scheduled scanning: Grype, Trivy or OSV-Scanner replay the archived SBOMs of every version still in the field, daily. No rebuild needed — you scan the file, not the repository:

grype sbom:./releases/v2.3.1.cdx.json

• Diff against the previous run: the useful output is not the full list, it is the delta — CVEs that appeared since yesterday on fielded versions.

This pipeline slots naturally into a CI that already produces documentation from sources of truth — the same logic as for IEC 62304 docs: the regulatory artefact is born from the build, not from a hand-maintained Word document.

The real problem: noise

A scanner is deliberately paranoid: it flags every match between a component and a CVE, without knowing whether the vulnerable code is ever called, whether the affected function is exposed, or whether an architectural control already neutralises the attack. A large share of the alerts concern code your product never executes.

In classic DevSecOps, you “mute” those false positives in the scanner config and move on. In medical devices, that option does not exist: every alert must end in a documented decision — fixed, or dismissed with a justification. Without tooling, only two bad options remain: ignore silently (indefensible at audit) or analyse every CVE by hand (the team sinks within a few sprints).

VEX: the machine-readable impact analysis

Definition: a VEX document (Vulnerability Exploitability eXchange) states, for a given product, the status of a vulnerability — affected, not_affected, fixed or under_investigation — together with a justification. It is the SBOM’s companion: one says what the product contains, the other says what actually affects it.

For the not_affected status, CISA defines five machine-readable justifications: component not present in the final product, vulnerable code not present, vulnerable code not in the execute path, vulnerable code not controllable by an adversary, inline mitigations already in place. Three formats coexist — OpenVEX, CycloneDX VEX and CSAF — and scanners consume them directly: feed your VEX file to Grype or Trivy, and the documented not_affected entries disappear from the output. The daily report only shows what is new and untriaged.

The medical convergence is immediate: a VEX statement is precisely the impact analysis your post-market process already requires — timestamped, versioned, auditable. And it is the tooled answer to the question a hospital customer will ask you one day: “are you affected by the CVE in the news?”

In a regulated context, dismissing a CVE is not forbidden. What is indefensible is dismissing it without a trace. VEX turns silence into a signed decision.

Which stage covers which requirement?

FAQ

How often should you scan?

On every build for code under development — that reflex everyone already has. The scan that matters post-market is the other one: scheduled, daily or weekly, against the SBOMs of fielded versions. A CVE is, by definition, born after your release; only a recurring scan will see it.

Is VEX mandatory?

No text names it explicitly. What is required — by the FDA as by IEC 81001-5-1 — is the documented analysis of every vulnerability affecting the product. VEX is its standardised, tool-consumable form: it turns a process obligation into an artefact your CI produces and your scanner consumes.

Can you declare “not_affected” without patching?

Yes — under three conditions: the justification matches one of the recognised categories, it is verified by someone who knows the code, and it is re-evaluated whenever the product changes (a function not called today may be called in the next version). It is a quality system record like any other: dated, signed, revisable.