Two devices can ship the same vulnerable library and deserve two different ratings. On one, the flaw sits three hops behind an authenticated service and a signed-update check. On the other, it parses traffic from an open port. A scanner reports the identical CVE on both, and nothing in the finding itself tells you which one is the problem.
That's the context gap, and it's the piece most vulnerability programs are missing. Static code analysis, binary reverse engineering, and runtime instrumentation are all reasonable at detecting that a vulnerable function or dependency exists. What they rarely explain is how an attacker could actually reach it in a real threat scenario. So teams end up holding long lists of issues with no clear sense of which ones matter or where remediation effort should go.
Flagging that a library is outdated leaves the operative question unanswered: how would a threat actor get there? Without the access vector or the privilege chain behind it, development teams are guessing. Replace the library? Rewrite the legacy code that carries it, or redesign around it?
The rating problem is the same problem wearing different clothes. A CVSS base score describes a vulnerability in the abstract, so every device containing the component inherits the same number. Your device isn't abstract. It has a specific attack surface and a specific set of controls in front of the flaw, and the honest rating can swing from critical to negligible depending on both.
Those calls are hard enough on supported software. They get worse when the vulnerable component is no longer maintained, or when it does a job the device can't function without. I've watched teams spend a quarter debating a patch that, once the actual path was inspected, never needed to happen.
We built ELTON to answer the reachability question directly. The platform runs end-to-end reachability and exploitability analysis against a digital twin of the product, assembled from SBOMs, architecture diagrams, testing data, and documented security controls. Every confirmed exploitable vulnerability comes with a mapped attack path from an exposed surface to the affected component. The path records which mitigations were bypassed, which other vulnerabilities were chained in, and where trust zones were escalated.
None of this is modeling for its own sake. The twin exists so the analysis reflects the product you actually ship, and the same evidence that justifies a fix also justifies the decision not to fix. The rating follows from the path: not a generic CVSS base score written for a hypothetical deployment, but what's actually reachable in this device as configured. Same CVE, different device, different answer. That isn't inconsistency. That's the model working.
Path context changes the remediation math too. In many cases the most effective fix isn't patching or replacing the vulnerable component at all. It's adding a control earlier in the path, or fixing the low-severity issue that enables the escalation in the first place. Sever the path once and every finding behind it drops with it. Smaller engineering effort, larger security impact.
This is also where the approach separates from reverse-engineering-heavy programs. Those produce disconnected vulnerability flags in volume. A path produces a rationale you can defend: why this one is exploitable and where the effort should land. It mirrors how attackers actually work rather than how static scanners operate.
The severity of a vulnerability is not a property of the CVE. It's a property of the CVE inside your device.
This matters more for medical devices than for almost anything else that ships software. Patching is slow and demands verification testing; a fix can take months to reach the field. Regulators don't expect blanket patching of every CVE; they expect defensible, risk-based decisions. A mapped path with documented bypassed mitigations is exactly that defense, whether the conclusion is fix now or no fix, with evidence.
Attackers don't read findings lists. They walk paths. A program that rates the path instead of the finding is describing the same reality attackers already operate in, and that's the only version of vulnerability management I'd put my name on.
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.
Because severity is a property of the CVE inside your device, not of the CVE. On one device the flaw sits three hops behind an authenticated service and a signed-update check. On the other it parses traffic from an open port. A scanner reports the identical finding on both.
Static code analysis, binary reverse engineering and runtime instrumentation are reasonable at detecting that a vulnerable function or dependency exists. What they rarely explain is how an attacker could reach it in a real threat scenario, so teams hold long lists of issues with no sense of which ones matter.
An attack path runs from an exposed surface to the affected component, and it records which mitigations were bypassed, which other vulnerabilities were chained in, and where trust zones were escalated. It answers the question a findings list leaves open: how would a threat actor actually get there.
Often it is not. The most effective fix is frequently a control added earlier in the path, or the low-severity issue that enables the escalation in the first place. Sever the path once and every finding behind it drops with it. Smaller engineering effort, larger security impact.
Patching is slow and demands verification testing, so a fix can take months to reach the field. Regulators do not expect blanket patching of every CVE, they expect defensible, risk-based decisions. A mapped path with documented bypassed mitigations is that defense, whether the conclusion is fix now or no fix.