FDA Deficiency: Missing CVE / CWE Mapping

What FDA reviewer language looks like

Paraphrased patterns from real deficiency letters. Not verbatim FDA quotes.

• Pattern 1

  The submission does not include a mapping of known CVEs against the components in the Software Bill of Materials. Provide an analysis of each component identifying applicable CVEs and the manufacturer's evaluation of exploitability for each.

• Pattern 2

  The penetration testing findings and threat model entries do not include CWE classifications. Provide CWE identifiers for each finding to support post-market trend analysis.

• Pattern 3

  It is unclear how vulnerabilities identified in the SBOM analysis flow into the vulnerability management plan and the cybersecurity risk assessment. Provide traceability from SBOM CVEs to risk evaluation and remediation status.

Why this happens

• Teams generate the SBOM in one tool and the CVE list in another, with no integration step.
• Exploitability evaluation is performed informally and not captured in writing per CVE.
• CWE classifications are skipped because the team does not realize they are expected on internally discovered findings, not just public CVEs.
• VEX (Vulnerability Exploitability eXchange) is not produced, so 'not affected' verdicts are claimed in prose with no machine-readable backing.

How to fix it

• Produce a CVE-to-component table covering every SBOM component with at least one known CVE: CVE ID, CVSS, exploitability-in-this-device verdict, rationale, mitigation, residual risk.
• Where 'not affected' is claimed, back it with a VEX document (CSAF or CycloneDX VEX) referencing the SBOM.
• Apply CWE identifiers to threat model entries, pen test findings, and risk assessment items.
• Connect each open CVE to the vulnerability management plan: who owns it, what the triage decision was, and when the next review is.

VEX is the artifact that turns a long CVE list into a clean response

Most devices that ship modern software stacks have hundreds of CVEs against their dependencies. Listing them all in prose is unmanageable, and listing only the ones you fixed leaves the reviewer wondering about the rest. The Vulnerability Exploitability eXchange (VEX) format exists for exactly this case: a machine-readable document that, for each CVE against an SBOM component, declares the device's status (affected, not affected, fixed, under investigation) with a justification. Submissions that include a VEX alongside the SBOM almost never draw a CVE-mapping deficiency — the reviewer can run the same tooling they would use post-market.

CWE is the post-market signal FDA is building

CWE classifications on internal findings (pen test results, threat model entries) feel like overhead during a submission, but they are the signal FDA uses to identify systemic weaknesses across manufacturers. Skipping CWE labels is a low-effort deficiency to draw and a low-effort deficiency to close. Pick the most specific CWE for each finding, document the rationale in a sentence, and move on.

Reachability is the difference between a 200-CVE problem and a 12-CVE problem

Most modern device codebases pull in dependencies that carry hundreds of CVEs the device itself never reaches at runtime — code paths in unused submodules, optional features that were never compiled in, or transitive packages that load only on platforms the device does not support. A submission that lists all of those CVEs as 'open' invites a deficiency. A submission that includes a reachability analysis — a documented determination, per CVE, of whether the vulnerable code path is actually reachable in the device build — turns the same list into a small set of genuinely affected items plus a defensible 'not affected' verdict on the rest. The combination of an SBOM, a VEX, and a short reachability methodology is the gold standard reviewers respond to. Tools (SCA platforms with reachability features, manual code-path tracing for high-severity items) can carry most of this load, but the methodology itself must be documented in the cybersecurity package.

Standards involved

• SBOMSoftware Bill of Materials (SPDX or CycloneDX)
• FDA 2026FDA Premarket Cybersecurity Guidance (Feb 3, 2026)
• ANSI/AAMI SW96ANSI/AAMI SW96:2023 - Standard for Medical Device Security - Security Risk Management
• IEC 81001-5-1IEC 81001-5-1:2021 - Health Software and Health IT Systems Safety, Effectiveness and Security

Already responding to this deficiency?

Our deficiency response engagement rebuilds the underlying artifact and produces a reviewer-ready response narrative.