SBOM and Threat Modelling
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
Confusing SBOMs and threat models weakens both records. A component inventory can reveal exposure to known vulnerabilities, but it does not show whether an attacker can reach a safety-relevant function. A threat model can show attack paths and controls, but it does not replace component-level software transparency.
NTIA's SBOM framing describes an SBOM as a formal, machine-readable inventory of software components and dependency relationships. That makes it a transparency and vulnerability-management record, not an attack-path analysis by itself.
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.
The premarket file becomes much stronger when the SBOM is not a detached spreadsheet. It should be traceable to the threat model, security architecture, vulnerability analysis, testing scope, labelling and cybersecurity management plan.
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.
A component CVE does not automatically mean the device has uncontrolled risk. The manufacturer must assess version, configuration, reachability, exploitability, compensating controls, safety impact, support status and fielded-device distribution.
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 information can help explain whether a known vulnerability affects a product. It should be used with evidence, not as a blanket statement. Customers need enough information to apply compensating controls, plan updates and understand residual risk.
Quality check
A useful SBOM and threat model are specific enough to support decisions. They should be machine-usable, version-aware, maintained after release and connected to the risk-management file.
NTIA's baseline framing 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.
A medical-device threat model should include the intended function, assets, actors, data flows, trust boundaries, update flows, interfaces, external services, third-party dependencies, assumptions, abuse cases, threats, mitigations and open residual-risk decisions.
- The device is not internet-connected, so cybersecurity is not relevant.
- The SBOM has no known critical CVEs, so the threat model is complete.
- The penetration test passed, so architecture and lifecycle controls do not need explanation.
- The customer network controls all remaining risk, so no device labelling or validation evidence is needed.