Not every vulnerability in your SBOM requires a patch. The FDA's 2016 postmarket guidance is clear that the question is whether a vulnerability is actually exploitable and whether it presents uncontrolled risk to safety, not whether it exists in a component somewhere.
The mistake manufacturers make is treating a CVSS base score as a patch trigger. A network-scored 9.8 can be a local 2.4 on your device once TLS blocks the path or the component sits behind a trust boundary the attacker never reaches. Patching all of them is expensive, destabilizing, and, ironically, harder to defend than a well-evidenced no-fix.
The defensible answer is not "we patched everything." It is "here is why this one did not need it."
What the FDA wants is a controlled, documented decision. If a vulnerability is not exploitable in your product, say so, show the reasoning, and monitor it. That is compliance without unnecessary patching.
Start with one device. We build the twin from documentation your quality system already produces, run AI discovery remotely, and show you the graph: the handful to fix, and the evidence for everything else.
One issue a month on AI, exploitability, and FDA cybersecurity review. No spam, unsubscribe anytime.
No. The FDA's 2016 postmarket guidance is clear that the question is whether a vulnerability is actually exploitable and whether it presents uncontrolled risk to safety, not whether it exists in a component somewhere. Presence in the SBOM starts an assessment. It does not by itself create a patching obligation.
No, and treating it as one is the common mistake. A network-scored 9.8 can be a local 2.4 on your device once TLS blocks the path or the component sits behind a trust boundary the attacker never reaches. The base score describes the vulnerability in the abstract, not in your product.
No. Patching all of them is expensive, destabilizing and, ironically, harder to defend than a well-evidenced no-fix. The defensible answer is not that you patched everything. It is that you can show why a particular vulnerability did not need it.
A controlled, documented decision. If a vulnerability is not exploitable in your product, say so, show the reasoning and keep monitoring it. That is compliance without unnecessary patching, and it holds up better than a fix applied to make a scanner go quiet.
Most exit at not reachable or not exploitable, with the reasoning captured at the point of decision. Only the remainder needs a code change. That is why the number of CVEs in an SBOM and the number of patches a manufacturer ships are never the same figure.