Product Security & Medical Device Cybersecurity Glossary
Understand the key terms and concepts in medical device cybersecurity, compliance, and product security management. From SBOM to threat modeling to regulatory frameworks.
AAMI TIR57
Association for the Advancement of Medical Instrumentation Technical Information Report 57. Establishes principles for Secure-by-Design medical device software development, emphasizing security must be built in from the start, not bolted on later.
Architecture Views
Visual diagrams of your product's system design, showing components, interfaces, and data flows. Used in threat modeling to identify attack surfaces and in compliance evidence to demonstrate thoughtful design.
CVSS (Common Vulnerability Scoring System)
Industry-standard method for rating vulnerability severity on a scale of 0-10. CVSS v3 and v4 are the current standards. Helps prioritize which vulnerabilities to fix first based on attack complexity, impact, and exploitability.
CWE (Common Weakness Enumeration)
Standardized list of common software weaknesses and vulnerabilities (e.g., SQL Injection, Buffer Overflow). Medical device threat catalogs map threats to CWEs to ensure comprehensive coverage of known weakness patterns.
CVE (Common Vulnerabilities and Exposures)
Unique identifier for publicly disclosed security vulnerabilities. Format: CVE-YYYY-NNNNN. Used to track specific, known vulnerabilities affecting your components (e.g., CVE-2024-12345 in OpenSSL).
Component
An individual piece of your product: a library, framework, module, or third-party dependency. Tracked in your SBOM. A vulnerability in one component can affect your entire product.
Compliance Evidence
Documentation proving your product meets regulatory requirements (FDA, EU MDR, IEC 62304, etc.). Includes threat models, risk analyses, security requirements, mitigations, and test results. Must be auditable and traceable.
Cybersecurity Guidance (FDA)
FDA's Premarket and Postmarket Guidance for medical device cybersecurity. Requires threat modeling, risk management, secure development, vulnerability handling, and post-market surveillance. Compliance is expected for medical device submissions.
EU MDR (In-Vitro Diagnostic Regulation)
European regulation for in-vitro diagnostic devices and medical devices. Requires security risk assessment and post-market surveillance. Stricter than predecessor directive (MDD). Requires demonstrable secure design and design controls.
IEC 62304
International standard for medical device software lifecycle. Defines requirements for software development, configuration management, documentation, and change control. Often combined with IEC 62443-4-1 for security requirements.
Post-Market Surveillance
Ongoing monitoring of your product after release to detect new vulnerabilities, security issues, or emerging threats. Required by FDA and EU MDR. Requires ability to quickly identify affected versions and communicate with customers.
Quality Management System (QMS)
Organizational processes and documentation proving compliance with regulatory requirements. Medical device QMS typically lives in a database (like MasterControl, Veracode, or custom systems). Product Security Hub integrates with QMS by providing auditable compliance evidence.
Residual Risk
Risk that remains after you've applied mitigations. Example: You identify a high-risk threat, implement a fix, but some risk remains due to design constraints. Residual risk must be documented and accepted (with justification) for compliance.
Risk Assessment
Process of identifying threats, analyzing their likelihood and impact, and deciding whether to mitigate or accept. In medical devices, risk assessments must follow ISO 14971 methodology and be documented for regulators.
SBOM (Software Bill of Materials)
Complete inventory of all software components, libraries, and dependencies in your product. Formats include CycloneDX (XML/JSON) and SPDX (standardized). Required by FDA and EU MDR. Used for vulnerability tracking and supply chain risk management.
SCA (Software Composition Analysis)
Automated scanning of your codebase or SBOM against vulnerability databases (like Google OSV, NVD). Identifies known vulnerabilities in your components so you can prioritize patching and risk mitigation.
Secure-by-Design
Design philosophy where security is considered from the start of development, not added as an afterthought. AAMI TIR57 principle. Includes threat modeling, secure architecture, secure coding, and security testing.
Security Requirements
Specific requirements your product must meet to be secure. Examples: 'All data in transit must be encrypted using TLS 1.2+', 'User authentication must use MFA', 'Security patches must be released within 30 days'. Derived from threat models and regulatory frameworks.
Threat
A potential attack or vulnerability that could harm your product. Example: 'Attacker intercepts unencrypted network traffic' or 'Malicious update delivers malware'. Threats are identified through threat modeling and documented in threat catalogs.
Threat Catalog
Pre-built list of common threats relevant to your industry and architecture. Medical device threat catalogs map to OWASP Top 10, CWEs, and regulatory frameworks. Threat modeling starts with catalog threats, then customizes for your architecture.
Threat Modeling
Systematic process of identifying and analyzing potential security threats to your product. Output: documented threats, their likelihood/impact, and mitigations. Required evidence for FDA, EU MDR, and IEC 62304 compliance.
Traceability
Ability to connect requirements → design → implementation → testing → risk mitigation. 'Complete traceability' means: vulnerabilities trace to components (SBOM) → components trace to architecture → architecture addresses threats → threats map to security requirements.
Vulnerability
A security weakness or flaw in your software that could be exploited by attackers. Examples: unpatched library with known CVE, weak encryption, hardcoded credentials. Tracked via SBOM scanning, security testing, or vendor notifications.
Vulnerability Management
Process of discovering, prioritizing, and remediating vulnerabilities. Steps: (1) Find vulnerabilities (SBOM scan, pen test, reports), (2) Assess severity (CVSS score), (3) Remediate or mitigate, (4) Verify and document. Continuous process, especially for post-market.
Want to dive deeper?
Check out our comprehensive resource library with guides, best practices, and how-to articles on SBOM management, threat modeling, compliance, and more.