医疗器械网络安全：十个让你睡不着觉的 Corner Case

基于 FDA 2026 年 2 月发布的《Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions》的个人解读。 以下所有案例均来自实际开发或医院部署中可能遇到的真实场景，回答仅代表对指南条款的理解，不构成法律或合规建议。

写在前面

前面三篇我们聊了 FDA 为什么要发这份新指南、SPDF 和 ISO 13485 到底是什么、以及安全控制和 524B 合规怎么做。这一篇我们不讲理论，直接上干货：十个你在设计、开发、部署医疗器械时，极有可能撞到墙的问题。

这些问题没有标准答案，但 FDA 的指南给出了判断的框架。每个 case 我都会标注指南里对应的依据，方便你回头查原文。

P1：Python 包绑死旧版本，升级就炸

场景：设备软件依赖某个开源 Python 包，这个包只支持 Python 3.8。Python 3.8 官方停止安全支持后，这个包出现漏洞，但升级 Python 会导致整个框架不兼容。

这算什么？

这是 SBOM + 供应链生命周期管理 + 安全更新三角冲突的典型困境。

指南 Section V.A.4（第三方软件组件）和 Section VII.C.3（SBOM）要求提交 Software Bill of Materials，而且不只是列清单，还要包含 component support information。也就是说，你得告诉 FDA：这个包现在维护状态如何？依赖树有多深？如果它停止维护，你的设备会不会被拖下水？

厂商能走的路：

1. 事前预防（设计阶段）：选组件时优先选活跃维护、社区大、版本兼容性好的。在威胁建模里把"Python 版本升级导致依赖断裂"识别为供应链风险。在 SBOM 里标明支持截止日期和替代方案。
2. 事后补救（上市后）：Python 3.8 EOL 后，如果包有漏洞，要么自己 fork 维护（成本爆炸），要么换组件（要重新验证，等于小重做），要么把 Python 3.8 运行时打包在设备里并物理隔离（补偿控制）。

FDA 的态度：不管你怎么选，必须在上市前就写出来。SBOM 里要列清楚每个组件的 end-of-support 日期，以及你打算怎么处理。

P2：医院还在用 WinXP，厂商软件跑不了

场景：医院 IT 基础设施老旧，很多电脑还在跑 Windows XP。厂商的软件不支持 XP，但医院说"我们用了十年了，换不了"。

这算什么？

这是"环境假设"和"第三方组件生命周期"碰撞的最极端场景。

先分清责任：WinXP 本身微软 2014 年就停止支持了，属于 end-of-life 操作系统，这不是厂商的锅。但厂商如果明知道客户群里有大量 WinXP 用户，却没有任何风险评估，那就有问题。

指南 Section IV.B 要求厂商考虑 worst-case environments of use，包括 least secure expected network configuration(s)。Section V.A.4 要求 SBOM 包含 component support information，操作系统也算组件。

厂商实际能走的路：

最现实的处理：在标签里写清楚"本软件不支持 Windows XP 及更早版本"，然后在威胁建模里记录"我们假设医院使用受支持的操作系统"。如果医院硬要跑在 XP 上，那是医院偏离了 intended use environment。

但反过来：如果厂商为了拿订单，嘴上不说支持 XP、实际上默许甚至暗示"XP 也能跑"——这就是虚假的环境假设，出事就是厂商的责任。

P3：知道零日漏洞，但排期太满先不修

场景：内部安全测试或第三方披露了一个零日漏洞，修复需要改动核心模块，验证周期至少三个月。产品上市排期已经定了，团队说"反正还没人利用，先上再说"。

这算什么？

算已知但未缓解的漏洞，必须当作合理可预见风险处理。

指南 Section V.A 明确说了：

When any known vulnerabilities are only partially mitigated or unmitigated by the device design, they should be assessed as reasonably foreseeable risks in the risk assessment and be assessed for additional control measures or risk transfer to the user/operator.

FDA 不认"我们知道但懒得修"这个选项。你有三条路：

1. 修好它（设计缓解）
2. 如果修不好，上补偿控制（网络隔离、监控告警、功能降级等）
3. 如果以上都做不到，把风险转移给用户——但必须在标签里充分披露

注意：风险转移有个前提，Section V.A 写了：

Risk transfer, if appropriate, should only occur when all relevant risk information is known, assessed, and appropriately communicated to users.

如果厂商明知有零日漏洞，既没修、又没披露、也没给补偿控制方案，那在 FDA 眼里这就是设备设计缺陷。

P4：x86 绑死，医院新买的 ARM 服务器跑不了

场景：设备软件只支持 Intel x86 架构。医院为了省电采购了 ARM 服务器，想在上面跑这套软件，发现跑不了。

这算什么？

这是"环境假设"和"互操作性"交界的问题。

指南 Section IV.B 有个关键脚注：

Manufacturers may not be able to account for all potential environments of use, but should consider the range of use environments and ensure the risks are identified and controlled for the worst-case environments of use.

以及 Section V.A.3（互操作性考虑）：

the device should be designed to ensure that interoperability does not introduce unacceptable risks.

核心逻辑：你不需要保证设备在所有 CPU 架构上都能跑，但你需要：

1. 在标签/文档里明确写清楚：本设备支持 x86 架构，不支持 ARM
2. 在威胁建模里识别风险：如果有人把设备镜像硬搬到 ARM 上跑，会发生什么？（缓冲区溢出行为不同、加密算法性能降级导致超时等）
3. 设计上做防护：如果可能，加入架构检测，拒绝在不受支持的平台启动

最刁钻的变体：医院 IT 部门买了 ARM 服务器，想虚拟机兼容一下——结果兼容性层引入了新的攻击面。这时候厂商的责任边界在哪？

指南的答案是：你控制不了医院的行为，但你的标签必须足够清晰。如果医院硬上，那是医院的风险管理问题。但如果你的标签根本没提架构要求，那就是你的锅。

P5：2038 年时间跳回，现在不想管

场景：设备用了 32 位时间戳，2038 年 1 月 19 日会发生 Y2K38 问题，时间跳回 1901 年。产品预期使用寿命 15 年，能活到 2038。开发团队说"还有 12 年呢，到时候再说"。

这算什么？

这是产品生命周期管理的经典考题，而且 FDA 很可能不认可"目前不想解决"。

指南 Section V.A.6 讲 TPLC（全生命周期）Security Risk Management：

addressed throughout the TPLC… including design and development, manufacturing, postmarket monitoring, delivering device software and firmware updates, and servicing, among others.

FDA 要求的是全生命周期。如果设备预期使用寿命是 15 年，2038 问题在生命周期内爆发，那厂商必须证明：

• 要么：设计时就避免了这个问题（比如用 64 位时间戳）
• 要么：有明确的上市后更新计划，保证 2038 年前能推送补丁
• 要么：在标签里明确写出"设备支持截止日期为 2037 年 12 月 31 日"，让用户知情

如果厂商说"现在不想管"，但设备到时候还在用，这就是生命周期管理失败。指南 Appendix 1 的"Firmware and Software Updates"控制类别要求 Secure and timely updatability and patchability。

不想管？可以。但得写在产品退役计划里，并在上市前就明确告诉用户。

P6：数字签名验证被伪造或绕过

场景：设备固件更新需要数字签名校验，但校验逻辑有缺陷——只检查签名"有没有"，不检查是谁签的。攻击者用自己的 CA 签发一个"有效签名"，设备也认了。

这算什么？

这是 Authenticity + Integrity 两条安全目标的底线被击穿。如果签名机制本身被攻破，整个信任链就塌了。

指南 Section IV.B 把 Authenticity（包含 Integrity）列为五大安全目标之首，Appendix 1 的 Cryptography 和 Code, Data, and Execution Integrity 控制类别都直接相关。

具体问题拆解：

最刁钻的变体：设备校验了签名，但只校验存在性不校验颁发者——攻击者用自己的 CA 签发一个"有效签名"，设备也认。这在很多嵌入式设备里真实存在。

FDA 的态度：签名不是"有没有"的问题，是整个信任链完不完整的问题。PKI 架构、密钥存储、轮换计划、泄露响应，都得在威胁建模和架构文档里写清楚。

P7：固件回滚攻击

场景：攻击者不推送新漏洞，而是把设备刷回有漏洞的旧固件版本，再利用已知的 CVE 入侵。

这算什么？

这是 Secure and timely updatability and patchability 这条安全目标的反向攻击，很多厂商根本没想到这一层。

攻击逻辑：

1. 厂商发布了 v1.0，有漏洞
2. 厂商发布了 v1.1，修好了
3. 攻击者拿到 v1.0 固件包，通过物理接口或网络推送，把设备强制刷回 v1.0
4. 设备没做任何版本校验，乖乖回去了
5. 攻击者利用 v1.0 的已知漏洞入侵设备

指南 Section IV.B 把 Secure and timely updatability and patchability 列为五大安全目标之一。注意关键词：Secure updatability。更新不只是"能更新"，还要防止恶意更新和回滚。

指南要求的控制措施：

最刁钻的变体：攻击者不刷旧固件，而是篡改版本号——把 v1.0 伪装成 v1.2，设备一看"版本更高"，就接受了。所以版本校验不能只看数字，要和签名绑定。

P8：入侵医院系统后，把患者数据发给保险公司

场景：黑客侵入医院网络，拿到了患者的心肺监护数据、CT影像，打包卖给了保险公司。保险公司据此调整保费或拒保。

厂商需要在威胁建模里防这个吗？

不需要。

这个场景的核心伤害是隐私泄露，不是患者安全。保险公司拿到数据不会让你的心肺监护仪停止工作，也不会让 CT 机误诊。

FDA 这份指南的管辖边界在 device safety and effectiveness。指南 Section III 定义了 “medical device system” 的范围，但核心始终是设备功能和患者安全。如果威胁不影响设备功能、不导致诊疗延误或错误，它就不在 SPDF 必须建模的范围里。

但注意边界：如果这个攻击路径同时包含篡改——比如入侵后修改了监护仪传回中央站的数据，导致护士站看到的血压是伪造的——那这就必须防。

判断标准不是"医院系统被侵入会怎样"，而是"这个攻击路径最终有没有可能回到患者身上"。

P9：安全事件导致设备被迫断电，需不需要快速恢复？

场景：勒索软件锁死医院系统，运维被迫给所有设备强制断电重启。来电后，监护仪多久能恢复工作？恢复后数据还在吗？配置被重置了吗？

这算什么？

普通市电中断不算这份指南管的事，但如果断电是网络攻击的结果，恢复能力就必须纳入设计。

普通的停电、跳闸、电压不稳，归 IEC 60601-1（医用电气设备基本安全）和软件可靠性工程管，不是这里的重点。你的 UPS 续航多久、电池能不能撑过切换、来电后多久能开机——这些在网络安全指南里不聊。

但如果是安全事件导致的"断电"：

所以指南真正关心的是：当安全事件已经发生时，设备能不能活着回来。

相关条款：

• Section IV.B 安全目标：Availability（可用性）和 Secure and timely updatability and patchability
• Appendix 1 控制类别：Resiliency and Recovery（弹性与恢复）
• Authenticity, which includes integrity：如果断电/重启过程中数据被损坏或篡改，完整性就破了

厂商在文档里可以这么处理：

威胁建模：识别"拒绝服务攻击导致设备被迫重启"这一攻击向量
风险评估：评估重启过程中患者监护数据丢失、配置被重置、安全策略失效的风险
控制措施：关键配置和患者数据定期自动备份到非易失存储；重启后自动校验配置完整性和固件签名；恢复后重新认证网络连接，不自动信任之前的会话。

P10：小孩把监护仪插头拔了，给手机充电去了

场景：医院病房里，有家属的小孩把心肺监护仪的电源插头拔了，然后把自己的手机充电器插到了插座上。监护仪断电，患者失去监护，出大问题。

这算什么？

这事还是叫老师和警察吧，医生救不了所有人。

正经说：这超出了任何合理的 intended use environment 假设。指南要求厂商考虑 worst-case，但不是所有 case。物理安全、医院管理、家长监护——这些属于操作层面的问题，不在网络安全设计控制范围内。

厂商能做的是：设计电池备份和断电告警，在标签里写清楚"设备需要持续供电"。但拔插头本身，属于 human factors engineering 和医院制度的范畴，这份指南不背这个锅。

小结：一个判断框架

十个案例看下来，可以提炼出一个简单的判断逻辑：

1. 这个威胁最终会不会影响患者安全？ 不会 → 大概率不在本指南范围（如 P8 隐私泄露、P10 拔插头）。
2. 这个风险厂商能不能在设计阶段控制？ 能 → 必须做（如 P3 漏洞修复、P6 签名校验）。
3. 这个风险在设备生命周期内会不会爆发？ 会 → 必须纳入 TPLC 管理（如 P5 的 2038 问题）。
4. 这个环境是不是厂商能假设的？ 不能 → 必须在标签里写清楚边界，并在威胁建模里评估最坏情况（如 P2 的 WinXP、P4 的 ARM 服务器）。

四个问题问完，基本就能判断一个 corner case 在 FDA 眼里算什么了。

（完）