SBOM Diffing and CVE Correlation: The Postmarket Workflow the FDA Expects

Published June 3, 2026

Key takeaways

• An SBOM submitted at clearance is a single frame. Postmarket cybersecurity is the film. Diffing turns the SBOM into a living artifact.
• The Feb 3, 2026 premarket guidance and Section 524B require a documented postmarket plan for monitoring, identifying, and addressing cybersecurity vulnerabilities. SBOM diff + CVE correlation is the operational mechanism.
• A defensible workflow has six steps: generate, diff, correlate, triage, decide (patch, mitigate, or VEX), and disclose.
• Correlation must use multiple sources. NVD alone misses CISA KEV adds, EPSS exploitation likelihood, GHSA ecosystem advisories, and vendor-specific notices that often land first.
• The most common failure mode is treating every new CVE as exploitable. The second-most-common is treating every old CVE as not exploitable. Both produce indefensible VEX statements.
• Tooling helps, but the FDA expects a documented decision trail with a named owner - not just a dashboard.

What "SBOM diff" actually means

A Software Bill of Materials (CycloneDX or SPDX) lists every component shipped in a medical device build: open-source libraries, third-party SDKs, OS packages, firmware blobs, container layers, and their versions, licenses, suppliers, and (ideally) cryptographic hashes.

An SBOM diff is the structured comparison of two SBOMs - typically release N vs release N+1, or today's production firmware vs last quarter's baseline. A useful diff distinguishes:

• Added components (new dependency, new transitive dependency, new container layer)
• Removed components (deprecated module, library swap, refactor)
• Upgraded components (semver bump, security patch, major version)
• Downgraded components (rare, almost always a regression signal worth flagging)
• Re-pinned components (same version string, different hash - supply chain alarm)
• Metadata-only changes (license change, supplier change, PURL correction)

What the diff is not: a list of vulnerabilities. The vulnerability picture only appears once you correlate the diff against CVE feeds. A diff with zero added components can still produce new CVEs - because the world publishes new CVEs against the components you already shipped, every day.

What "CVE correlation" actually means

CVE correlation is the process of taking each component-version pair in your SBOM (or in the SBOM diff) and asking, across multiple authoritative sources:

• Is there a known CVE against this exact version, or against a version range that includes it?
• Is it in CISA's Known Exploited Vulnerabilities (KEV) catalog?
• What is the EPSS score (likelihood of exploitation in the wild within 30 days)?
• Has the upstream vendor issued an advisory, security note, or fix?
• Is the affected function or code path actually reachable from your device's attack surface?

The output is not "list of CVEs." It is a triaged, prioritized, decision-ready view: which vulnerabilities require a VEX statement justifying non-exploitability, which require a coordinated disclosure, which require a patch, and which can be deferred with documented rationale.

This is the moment most postmarket programs break. Either the team drowns in raw NVD output, or they suppress everything by hand without a defensible trail. Both fail FDA scrutiny.

Why the FDA cares

The Feb 3, 2026 premarket cybersecurity guidance is explicit that the cybersecurity story does not end at clearance. Submissions are expected to include:

• A plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits
• A process for the timely identification and remediation of new vulnerabilities affecting the device
• SBOM maintenance with mechanisms to update it as the device evolves
• Coordinated vulnerability disclosure (CVD) processes consistent with ISO/IEC 30111 and ISO/IEC 29147

Section 524B of the FD&C Act makes this binding for cyber devices. The guidance ties postmarket obligations back to the SBOM as the connective tissue. If your SBOM is not diffed and correlated on a defined cadence, you do not have a postmarket monitoring program; you have an artifact in a folder.

For the broader postmarket context, see our companion piece on the postmarket cybersecurity roadmap, and how EOL/EOS components specifically interact with Section 524B in SBOM, End-of-Support, and Section 524B.

The six-step workflow

A defensible postmarket SBOM monitoring program collapses to six repeatable steps. Each step has a deliverable, a named owner, and a documented decision trail.

Where teams go wrong: three failure patterns

1. Diffing without re-correlating the steady state

Most pipelines correlate only the added components in a diff. That misses the most important class of postmarket vulnerability: a CVE published this week against a component you shipped last year. The components in your SBOM did not change; the threat landscape did. Correlation must run on the full SBOM on a fixed cadence (weekly is a defensible minimum), not just on the delta.

2. Treating NVD as the source of truth

NVD is necessary and insufficient. CISA's KEV catalog is the FDA's clearest signal on exploitation; if a CVE in your SBOM lands on KEV, it is no longer a paper risk. EPSS gives a probability-weighted view that makes triage tractable when NVD throws hundreds of CVSS 7+ items at you in a release. GHSA catches ecosystem-specific issues (npm, PyPI, Maven, Go) that often appear before NVD. Vendor advisories - Microsoft, Red Hat, Wind River, NXP, ST, Nordic, Qualcomm - frequently land first and contain the exploit-context detail you need. A correlation pipeline that only hits NVD will miss and over-call simultaneously.

3. VEX statements without reachability evidence

A VEX statement marking a CVE as not_affected with justification vulnerable_code_not_in_execute_path is a defensible answer - if you can show how you determined it. A pile of not_affected VEX entries with one-line justifications and no underlying call-graph, configuration, or threat-model reference is the exact pattern that triggers the FDA's most common SBOM deficiency: "Sponsor's VEX assertions are not substantiated." We've covered the specific patterns to avoid in VEX Mistakes That Trigger FDA Deficiencies.

Diff-and-correlate cadences that hold up

There is no single "right" cadence, but reviewers expect to see a defined one tied to risk class. A workable baseline:

What a defensible VEX decision looks like

For each correlated CVE that lands in triage, a defensible decision record contains:

• Component and version (with PURL or CPE)
• CVE ID and source (NVD, KEV, EPSS score, vendor advisory)
• Reachability assessment: is the vulnerable function called from the device's actual code paths and configurations?
• Attack-surface exposure: is the affected interface exposed (network-reachable, user-facing, peripheral)?
• Patient-safety impact referenced back to the device risk file
• Decision: affected, not_affected, fixed, under_investigation
• Justification using the standard VEX vocabulary (component_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_not_present, vulnerable_code_cannot_be_controlled_by_adversary, inline_mitigations_already_exist)
• Named owner and date
• Evidence link - call-graph, threat-model artifact, test result, or compensating control reference

When you can produce this record per CVE in your SBOM on demand, you have a postmarket monitoring program. When you can't, you have a list.

For the deeper distinction between the SBOM artifact and the VEX layer, see SBOM vs VEX: What's the Difference?.

Tooling: what to look for

The market has converged on a few categories. None of them, by themselves, deliver a 524B-defensible workflow - but the right combination does.

• SBOM generators built into the build pipeline (Syft, CycloneDX-CLI, language-native tools, container scanners). Same tool every time, hash-pinned outputs.
• SBOM diff tools that understand semver, transitive vs direct dependencies, and PURL equivalence (CycloneDX cyclonedx diff, Anchore Grype/Syft, Snyk SBOM compare, in-house scripts on top of spdx-tools).
• Vulnerability correlation engines that pull NVD, KEV, EPSS, GHSA, and vendor advisories (Grype, Trivy, OSV-Scanner, Dependency-Track, commercial platforms). Multi-source is non-negotiable.
• VEX authoring and publishing (CycloneDX VEX, OpenVEX, CSAF). Whatever format you choose, publish it on a stable URL and version it.
• Workflow / decision tracking - a ticket queue, a vulnerability management platform, or a structured spreadsheet with revision history. The reviewer cares about the trail, not the tool.

Two practical notes. First, the FDA does not require any specific vendor. Second, "we use [platform X]" is not a postmarket program - the program is the documented cadence, the named owners, the decision records, and the disclosure path.

How Blue Goat Cyber runs this

Postmarket SBOM monitoring is one of the workstreams in our postmarket retainer model. We run SBOM generation and diffing on the manufacturer's build pipeline (or instrument it if it isn't there), correlate weekly against NVD, CISA KEV, EPSS, GHSA, and the upstream advisories that matter for your stack, and produce a triaged decision queue with named owners and evidence links. VEX statements are authored against the device's actual reachability and threat model, not generic library metadata. The deliverable each quarter is an FDA-defensible postmarket cybersecurity record: SBOM, VEX, decision log, CVD activity, and an audit-ready trail back to Section 524B and the Feb 2026 guidance.

If your SBOM stops at clearance and your postmarket program is "we'll respond if someone reports something," that's the gap to close before the next inspection or AI/NN letter.

Frequently asked questions

What is SBOM diffing?

SBOM diffing is the structured comparison of two Software Bills of Materials for the same medical device - typically between releases, builds, or fixed time points - to identify which components have been added, removed, upgraded, downgraded, or re-pinned (same version, different hash). The diff is the foundation for postmarket vulnerability monitoring: it tells you what changed in your supply chain so you can ask what new exposures changed with it.

What is CVE correlation?

CVE correlation is the process of matching each component-version pair in your SBOM against vulnerability data sources - NVD, CISA KEV, EPSS, GHSA, and vendor advisories - to determine which Common Vulnerabilities and Exposures apply, how exploitable they are, and which require a VEX statement, patch, mitigation, or coordinated disclosure. Correlation must run on the full SBOM on a cadence, not just on what changed in the latest diff.

How often should a medical device manufacturer diff its SBOM and correlate CVEs?

A defensible cadence has multiple triggers. Diff on every build (gate releases on CISA KEV hits). Re-correlate the full SBOM on every release and weekly in steady state. Re-correlate immediately when a KEV entry or material vendor advisory lands. Run a full year-over-year diff and correlation as part of the annual postmarket cybersecurity review for the Section 524B evidence package.

What's the difference between an SBOM diff and a CVE diff?

An SBOM diff compares software inventories - what components are in the device. A CVE diff compares vulnerability findings - what CVEs were known last week versus this week, given the same SBOM. Both matter. Components change because you ship new builds; CVEs change because the rest of the world discovers and publishes new vulnerabilities against the components you already shipped. You need both.

Why isn't NVD enough for CVE correlation?

NVD is the canonical CVE catalog, but it lags upstream advisories, lacks exploitation context, and is missing many ecosystem-specific issues that GHSA captures. CISA KEV tells you what's actually being exploited. EPSS gives you a probability of near-term exploitation that makes large CVSS lists tractable. Vendor advisories from Microsoft, Red Hat, Wind River, Nordic, ST, NXP, Qualcomm, and others often land before NVD and contain the call-path detail you need. A pipeline that only consults NVD will both miss real risk and over-flag low-priority noise.

How does SBOM diffing tie into VEX?

The diff identifies new components. CVE correlation identifies new vulnerabilities - both from the diff and from the world publishing new CVEs against the unchanged components. VEX is how you communicate, per CVE, whether your device is affected, not_affected, fixed, or under_investigation, with a structured justification. Every change to the underlying SBOM or vulnerability picture is a potential trigger to update the VEX statement and republish it.

Does the FDA require SBOM diffing specifically?

The Feb 3, 2026 premarket cybersecurity guidance and Section 524B require a documented postmarket plan to monitor, identify, and address cybersecurity vulnerabilities over the supported life of the device, and they require the SBOM to be maintained. The guidance does not prescribe a particular tool or use the phrase "SBOM diffing." It does, in practice, require what SBOM diffing plus CVE correlation produces: a continuous, evidence-backed process that identifies new vulnerabilities and drives patch, mitigation, VEX, or disclosure decisions. A submission that says "we maintain the SBOM" without a documented diff-and-correlate cadence is the pattern that draws reviewer questions.

What's the most common SBOM monitoring deficiency the FDA cites?

Three patterns recur. First, VEX statements marked not_affected without underlying reachability evidence. Second, postmarket "plans" that describe the SBOM artifact but not the cadence, owners, or decision trail. Third, EOL or EOS components that were defensible at clearance but became indefensible when their support window closed, with no diff-driven review catching it. We've covered the EOL pattern in detail in SBOM, End-of-Support, and Section 524B.

Can SBOM diff and CVE correlation be fully automated?

Generation, diffing, and correlation can and should be automated. Triage, reachability analysis, VEX authoring, and the decision to patch, mitigate, or disclose cannot. An automated pipeline that emits VEX statements without human reachability judgment will produce defensible-looking JSON that does not survive a reviewer asking "show me how you determined this code is unreachable." Treat the tools as accelerators for the steps that benefit and as feeders for the human-owned decision queue.

How does SBOM diffing interact with coordinated vulnerability disclosure?

The diff and correlation pipeline is the trigger source for CVD. When a high-severity, reachable, exposed CVE lands in your triage queue - whether through a new component, a new advisory against an old component, or a researcher report - the CVD process (consistent with ISO/IEC 30111 and ISO/IEC 29147) is how you communicate, remediate, and notify affected customers and CISA. A postmarket monitoring program without a CVD process is incomplete; a CVD process without an underlying SBOM monitoring pipeline cannot scale beyond the reports that happen to walk in the door.

Related reading

• SBOM vs VEX: What's the Difference?
• SBOM, End-of-Support, and Section 524B
• VEX Mistakes That Trigger FDA Deficiencies
• Postmarket Cybersecurity for Medical Devices: The FDA Roadmap
• Medical Device SBOM: FDA Requirements and Submission Guide