Medical-device SBOMs and threat modelling
Sytance · Updated
An SBOM and a threat model answer different questions. The SBOM identifies software components and dependency relationships. The threat model explains how a device, software system, user, environment or update path can be attacked and how that attack could affect safety, performance or security.
Different records
A component vulnerability becomes a device-specific question when the component’s role is understood. A network parser may receive untrusted input directly; the same library compiled without the affected function may present a different exposure. The SBOM identifies the component, and the threat model supplies the architecture needed to investigate that difference.
NTIA defines an SBOM as a machine-readable inventory of software components and their relationships. For a device assessment, this helps establish which software is present and where to look for supplier or vulnerability information.
SBOM
Records component names, suppliers, versions, identifiers, hashes, dependencies and authorship information so the manufacturer and customer can track component exposure and support status.
Threat model
Records assets, actors, trust boundaries, data flows, interfaces, attack paths, threats, mitigations, assumptions and residual risk decisions.
Security architecture
Shows how controls such as authentication, authorisation, encryption, logging, update protection and recovery are placed across the system and related services.
Risk management
Decides whether the remaining risk is acceptable and how cybersecurity findings affect safety, performance, labelling, postmarket surveillance and remediation.
Premarket link
FDA's current premarket guidance expects SBOM, threat modelling, cybersecurity risk assessment, architecture and testing evidence to work together. For a cyber device under section 524B, the SBOM is a statutory submission element and must include commercial, open-source and off-the-shelf software components.
- The threat model should cover the device system, external entities, deployment, interoperability, maintenance, updates, supply-chain assumptions and decommissioning.
- The SBOM should include manufacturer-developed and third-party components, upstream dependencies, support status and information needed to evaluate known vulnerabilities.
- Architecture views should explain interfaces, protocols, trust boundaries, users, controls, related systems and update paths.
- Testing should show that selected security controls and threat mitigations work, including vulnerability testing and penetration testing when relevant.
An SBOM entry should be traceable to the component's place in the architecture and to the relevant vulnerability analysis. Those links connect the inventory to threat modelling, testing, labelling and postmarket management.
Postmarket link
After release, the SBOM and threat model become operating records. The SBOM helps identify exposure when a supplier, open-source package, commercial component or operating-system dependency changes. The threat model helps decide whether that exposure can produce patient harm in the actual device architecture and use environment.
Check whether the affected version and code are present in the device, then determine how an attacker could reach them. Assess the existing controls and the possible harm to patients. The result applies to the configurations analysed; other versions still in use may need a separate assessment.
The threat model should be updated when a new vulnerability, new attack technique, changed deployment assumption, new interface, new cloud service or altered update path changes the risk picture.
Vulnerability Exploitability eXchange (VEX) communicates an impact assessment for a named vulnerability and product. Identify the version and configuration covered, and explain any conditions the recipient needs to maintain. If remediation is needed, state the update or other action available to the user.
Maintaining usable records
The SBOM and threat model should identify the product version they describe and remain current after release. The SBOM also needs a machine-readable format. Both records should link to the risk-management file.
NTIA's 2021 baseline identifies data elements such as supplier name, component name, version string, component identifier, dependency relationship, author name and timestamp. FDA adds device-specific expectations such as software support status, known vulnerabilities and the relationship to device risk controls.
The model should explain how an attacker could reach a device function and what protection prevents or limits that action. Describe the device and connected systems, then link each attack scenario to its conditions, selected controls and remaining risk.
- An offline device can still receive malicious input through an update or maintenance interface. Include those paths in the threat model.
- An SBOM with no known critical CVEs says little about design flaws or missing access controls. Assess those threats against the architecture.
- A penetration test report applies to its stated scope and configuration. Use the results alongside the design analysis and planned maintenance controls.
- If protection depends on the customer’s network, state the required controls and check that they address the threat. Communicate the conditions the customer needs to maintain.