1. 医疗器械漏洞管理工程导论
医疗器械漏洞管理工程，是把“漏洞”当作一类需要被持续识别、评估、处置和验证的工程对象，嵌入到医疗器械从概念、设计、生产、上市、运维到退役的全生命周期之中。它既不是单纯的网络安全扫描，也不是一次性的合规文档工作，而是一套贯穿产品与组织、技术与流程、法规与证据的系统性工程活动。理解这一章，关键要抓住三件事：漏洞管理在生命周期中的位置、核心术语的准确含义，以及法规背景所要求的责任边界。
一、课程目标：从“发现漏洞”到“管理风险”
本课程的目标不是教会读者使用某一款扫描工具，而是建立一套可落地的方法论：能够识别医疗器械中与漏洞相关的资产与接口，能够对漏洞进行分级与风险评价，能够制定并执行处置策略，能够形成可追溯的证据链，并能够在产品上市后持续监测与响应。换句话说，课程关注的是“管理”而非“检测”，是“工程闭环”而非“单点动作”。
在实际工作中，一个常见的误区是把漏洞管理等同于“打补丁”。但医疗器械的特殊性在于：软件更新可能影响安全有效性，网络接口可能连接生命支持设备，第三方组件可能无法直接修改，而监管要求又要求变更受控。因此，漏洞管理的核心是风险决策：在给定临床用途、使用环境和法规约束下，决定哪些漏洞必须立即处置、哪些可以缓解、哪些可以接受并持续监控。
二、漏洞管理在全生命周期中的定位
医疗器械全生命周期通常包括概念、设计开发、验证确认、生产与上市、上市后运维、退役等阶段。漏洞管理并非只在上市后出现，而是从设计阶段就应介入。例如，在架构设计时选择安全的通信协议、在软件物料清单中记录第三方组件版本、在风险分析中考虑可被利用的漏洞场景，这些都属于前置的漏洞管理活动。
下面这张图展示了漏洞管理活动与医疗器械全生命周期的对应关系，以及各阶段的关键输入与输出。它帮助读者看清：漏洞管理是一条贯穿始终的“纵向主线”，而不是某个阶段的附属任务。
从图中可以看出，漏洞管理主线在各阶段都有不同的活动重点，但最终都汇聚为可追溯的证据。这些证据既是工程决策的依据，也是法规符合性的证明。
三、核心术语：准确理解才能正确执行
漏洞管理涉及多个容易混淆的术语，必须明确其含义与边界。
- 漏洞（Vulnerability）：系统、组件或协议中存在的弱点，可能被威胁源利用并造成损害。漏洞本身是“可能性”，不等于已经发生安全事件。
- 威胁（Threat）：可能利用漏洞的外部或内部因素，如攻击者、恶意软件、误操作等。
- 风险（Risk）：漏洞被利用的可能性和造成后果严重程度的组合。医疗器械语境下，后果不仅包括数据泄露，还包括患者伤害、治疗中断、诊断错误。
- SBOM（软件物料清单）：记录产品中所有软件组件及其版本、来源、依赖关系的清单。没有SBOM，漏洞监测就无从谈起。
- 漏洞披露（Disclosure）：将漏洞信息告知相关方（监管机构、用户、公众）的过程，需要平衡透明性与被利用风险。
- 补丁（Patch）：用于修复漏洞的软件更新。在医疗器械中，补丁必须经过变更控制和验证，不能随意推送。
这些术语之间的关系可以用一句话概括：威胁利用漏洞，漏洞带来风险，风险管理依赖SBOM和补丁，而披露与监测贯穿始终。
四、法规背景：责任不是可选项
医疗器械漏洞管理的法规背景主要由三类要求构成。第一类是医疗器械质量管理体系要求，例如ISO 13485和我国《医疗器械生产质量管理规范》，要求对设计变更、软件确认、风险管理和上市后监督进行控制。第二类是网络安全与软件专项要求，例如FDA的上市前网络安全指南、上市后网络安全指南，以及我国《医疗器械网络安全注册审查指导原则》，明确要求提供SBOM、漏洞管理计划、安全更新机制等。第三类是数据与隐私法规，如《个人信息保护法》和《数据安全法》，对患者数据的收集、传输和存储提出约束。
这些法规的共同指向是：制造商不能只关注产品出厂时的状态，而必须对产品在整个使用周期内的安全性负责。漏洞管理计划、漏洞监测能力、补丁发布流程、用户沟通机制，都是监管审查中可能被要求提供的证据。
五、一个简化的教学示例：从SBOM到处置决策
假设某输液泵软件使用了开源组件OpenSSL 1.1.1，SBOM中记录了该组件及其版本。上市后监测发现OpenSSL 1.1.1存在一个高危漏洞，攻击者可能通过特制网络包导致设备通信中断。此时漏洞管理过程如下：
- 确认受影响产品与版本：通过SBOM定位所有使用该组件的型号和软件版本。
- 评价风险：结合输液泵的临床用途，判断通信中断是否会导致治疗延迟或剂量错误。若设备在通信中断时仍能按本地设置继续输液，则后果可控；若依赖网络指令，则后果严重。
- 制定处置策略：若组件可升级，则开发补丁并验证；若无法升级，则考虑网络隔离、访问控制等缓解措施。
- 验证与发布：补丁需经过回归测试和网络安全验证，确认不引入新问题后，按变更控制流程发布。
- 记录与沟通：更新漏洞清单、风险评价记录，并向用户和监管机构提供必要信息。
这个示例说明，漏洞管理的每一步都需要工程判断和证据支撑，而不是简单地“升级到最新版本”。