A CVE/CWE mapping deficiency means the reviewer cannot trace from a known vulnerability database back to your device's components and weaknesses. They want to see, for every SBOM component with known CVEs, how the team evaluated each CVE - exploitable in this device, not exploitable, exploitable but mitigated by a control. They also want CWE classifications applied to the threat model and pen test findings so cross-submission patterns can be tracked.
Paraphrased patterns from real deficiency letters. Not verbatim FDA quotes.
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.
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.
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.
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 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.
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.
Already responding to this deficiency?
Our deficiency response engagement rebuilds the underlying artifact and produces a reviewer-ready response narrative.
FDA Cybersecurity Deficiency Response serviceBring us the letter. We will map a clean response and rebuild the underlying artifact to FDA 2026 expectations.
