Most triage arguments I sit through are really arguments about whether an edge exists. Can an attacker reach the vulnerable function? Does anything authenticate that path? Does the data cross a trust boundary before it hits the parser? Each question is a graph query asked in English.
Because the product is a graph, the security lives in the relationships. The paperwork describes components one at a time, even though incidents travel along the connections. Graph views close that gap.
List what a connected device holds: a processor, an RTOS, a network stack, a BLE radio, a USB port, an update client, a web UI, an interface to the EHR. Congress already requires the list; section 524B put the SBOM into premarket submissions. An SBOM names the nodes, at best with a dependency tree. The runtime edges, which component talks to which, over what protocol, with what authentication, appear nowhere in it. Frankly, the mandate lets teams feel finished once they've named the nodes.
Almost every security failure I have worked on lived between components. Think of a default password on a management port, or a parser that trusts whatever length field the radio hands it. Both problems live on an edge, and a parts list holds neither.
A base CVSS score rates a component as if it floated in space. Exploitability is a path property. The same buffer overflow rates critical on a device that exposes the vulnerable service to the hospital network. On a device where the only path to it runs through signed firmware, it drops to a footnote. One CVE, two devices, and the difference sits entirely in the edges.
Threat modeling has reached for this shape for decades. Schneier popularized attack trees in 1999, and STRIDE workshops still fill whiteboards with data-flow diagrams, boxes, arrows, and trust-boundary lines. Each artifact is a graph drawn by hand, frozen on the day the workshop ended. A month later the firmware updates, a supplier swaps a component, the diagram quietly stops being true, and nobody redraws it. A manual threat model is a snapshot of a thing that moves.
The alternative is a threat model that lives as a graph: components, interfaces, data flows, and trust boundaries, maintained so the model moves when the product moves. Digital twins of devices already take this form. With the model in that shape, the workshop questions become queries. Show every path from the BLE radio to the dosing logic. List the edges that carry data without authentication. Diff the whole graph against the last release. The answers arrive in minutes and stay current between audits.
The testing side lands in the same place. The AI fleets now doing security testing organize as graphs too, wider versions of the loops and CI/CD pipelines I covered in earlier issues. A fleet pointed at a device walks the product graph, fans out across the interfaces, and verifies which paths an attacker can actually travel. A finding that survives comes back with its path attached, and the evidence becomes a path anyone can retrace.
Regulators already ask for the graph, in prose form. FDA's premarket cybersecurity guidance wants architecture views, data flows, and an accounting of how updates reach the device. Most teams answer with static diagrams that age out before the review closes. The teams that keep a living graph of each product will answer on demand and triage new CVEs by path instead of by raw score. They will hand the next auditor a graph that matches the shipping firmware. Graph views are where medical device security is heading, because the products were graphs all along. The threat model has been waiting for permission to become one.
Jason
---
Sources: Bruce Schneier, "Attack Trees," Dr. Dobb's Journal, Dec 1999. FD&C Act section 524B(b)(3), SBOM requirement for cyber devices. FDA, "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," final guidance, updated 2025.