FDA cyber device上市后SBOM/VEX维护：获批后版本更新、漏洞披露和CAPA记录怎么做

很多企业在拿到FDA 510(k)或PMA批准函的那一刻，以为网络安全这个大包袱终于可以放下了。实际情况恰恰相反——获批只是上市后网络安全合规的起点。你的SBOM从提交那一刻起就开始老化，你的组件供应商可能随时发布安全公告，你的设备在医院网络中每天都在面对新的攻击手法。Section 524B对cyber device的规定从来不只是"提交时有一份SBOM就行"，而是要求你在设备的整个生命周期中持续维护SBOM、生成VEX、处理漏洞、发布补丁、记录CAPA。这篇文章专门解决一个问题：获批之后怎么做。

本文解决什么 / 不解决什么

解决什么

cyber device获批后的SBOM生命周期维护（什么时候更新、谁负责、怎么做）
VEX文档的编写方法与状态判定逻辑
漏洞接收、分诊、补丁分类与客户通知的完整流程
网络安全事件如何接入CAPA和投诉体系
协调漏洞披露（CVD）的策略与时间线
FDA QMSR检查中网络安全证据的准备

不解决什么

上市前SBOM的生成方法（参考我们之前的SBOM合规指南）
网络安全架构设计和威胁建模（参考FDA网络安全指南）
QMSR/ISO 13485的整体实施（参考QMSR实施指南）
其他监管机构的网络安全要求（欧盟MDR、NMPA等）

Cyber device与SBOM的法律基础

Section 524B说了什么

FD&C Act第524B节自2023年3月29日起生效，对"cyber device"提出了三项法定要求：

安全产品开发框架（SPDF）：必须建立覆盖全生命周期的安全开发流程
网络安全透明度：设备标签中必须包含网络安全相关信息
软件物料清单（SBOM）：必须提供SBOM，且必须是机器可读格式

第(3)项是很多人低估的部分。Section 524B(b)(3)写得很清楚：SBOM是cyber device的法定义务，不是建议。不提供SBOM属于FD&C Act第301(q)条规定的禁止行为，FDA可以据此采取执法行动。

什么设备算cyber device

Section 524B(c)定义了三个条件——同时满足才构成cyber device：

包含制造商验证、安装或授权的软件（含固件、可编程逻辑）
具备连接互联网的能力（直接或间接）
具有可能受网络安全威胁影响的技术特性

"连接互联网的能力"这个条件比很多人理解的要宽。FDA在2026年2月3日更新的指南中明确指出：Wi-Fi、蓝牙、USB接口、以太网口、串行端口、NFC，甚至设备上未启用的调试端口或工程接口，只要技术上存在连接能力，都可能被纳入cyber device的范畴。也就是说，你的设备可能没有"上网"的设计意图，但FDA看的是能力，不是意图。

QMSR对SBOM的影响

2026年2月2日生效的QMSR（Quality Management System Regulation）将ISO 13485:2016纳入法规框架，SBOM的管理也随之从"技术文档"上升为质量体系要素。具体来说：

ISO 13485第7.3节（设计和开发）：SBOM被视为设计输出，必须在设计控制流程中管理
ISO 13485第7.3.7节（设计和开发确认）：安全测试作为设计确认的一部分
ISO 13485第8.5节（改进）：网络安全事件纳入CAPA流程
ISO 13485第7.1节（产品实现策划）：网络安全风险管理是产品实现策划的一部分

FDA在2026年2月3日（QMSR生效次日）发布了修订版网络安全指南，将所有引用从旧版QSR（21 CFR 820）更新为QMSR框架。核心要求没变，但结构性意义很大——网络安全不再是一个独立的技术活动，而是质量体系的一部分。

网络安全风险 vs 安全风险

这一点我们在实际咨询中反复强调：FDA的网络安全风险评估和ISO 14971的安全风险评估是两套体系，不能混在一起做。

ISO 14971：基于概率和严重度，评估伤害发生的可能性
FDA网络安全：基于可利用性（exploitability），评估漏洞被攻击者利用的可能性

攻击者不会按概率分布表来行动。一个CVSS 9.8的远程代码执行漏洞，即使"发生概率"极低，攻击者只需要一个脚本就能批量利用。用ISO 14971的矩阵去评估网络安全风险，大概率会低估威胁。

上市后SBOM生命周期管理

SBOM是活的，不是死的

提交给FDA的那份SBOM，在你拿到批准函的那天就已经开始过时。第三方组件发布更新、开源项目终止维护、新的CVE被披露——这些事件每天都在发生。

FDA在指南中明确要求SBOM包含以下信息：

SBOM必须包含的信息	说明
组件清单	所有商业、开源、自研软件组件
版本号	精确到补丁级别
供应商信息	组件的来源和供应商
依赖关系	组件之间的调用和依赖链
支持级别	活跃维护 / 仅安全补丁 / 已弃用
停止支持日期	供应商计划终止支持的日期
已知漏洞	CISA KEV目录中的已知利用漏洞

FDA会用SBOM和NVD（National Vulnerability Database）、GitHub Advisories做交叉比对。如果你的SBOM中某个组件有已知的严重CVE但你没有在VEX中说明，审查员会追问。

SBOM更新触发条件

我们把SBOM的更新触发条件整理成了一张表：

触发事件	SBOM动作	时间要求	责任方
软件补丁发布	更新组件版本号，重新生成SBOM	补丁发布前完成	研发/配置管理
第三方组件版本升级	更新组件条目和依赖关系	合入主分支前完成	研发/供应链
新CVE披露影响现有组件	在VEX中记录判定结果，SBOM暂不更新（除非发布补丁）	CVE披露后72小时内完成VEX	安全团队
组件供应商发布EOL/EOS通知	更新SBOM中的支持级别和EOS日期	收到通知后30天内	供应链/安全团队
设备硬件平台变更	重建整个SBOM	设计变更冻结前	研发/配置管理
新设备版本发布	生成新版本的独立SBOM	发布前完成	研发/配置管理

这里面最容易忽略的是EOL/EOS通知。很多开源项目和商业组件的停止维护通知发出来之后，企业根本没有跟踪机制。等到FDA检查时才发现SBOM里写着"活跃维护"的组件其实两年前就停更了。

SBOM格式与工具

FDA要求SBOM必须是机器可读格式，目前接受两种标准：

CycloneDX：OWASP维护的开源标准，医疗器械行业采用较多
SPDX：Linux基金会维护的标准，软件行业通用

就实际经验而言，CycloneDX在医疗器械领域的接受度更高，配套工具和社区资源也更丰富。生成工具方面，可以选择前端集成到CI/CD管道的方式（如Trivy、Syft、CycloneDX CLI），也可以用SCA（Software Composition Analysis）平台自动生成。不管用什么工具，关键是每次构建都生成，而不是手动维护一个Excel表格。

VEX文档编写实战

VEX是什么

VEX（Vulnerability Exploitability eXchange）是一个标准化的文档格式，用来告诉FDA和使用者：你的SBOM里列出的那些CVE，哪些真的影响你的设备，哪些不影响。

打个比方：SBOM是一份食材清单，列出你用了什么原料；VEX是一份说明，标注哪些原料里的农药残留超标但已经被加工去除了，哪些根本没进入最终产品。

FDA在2026年的实践中开始要求企业在部分premarket提交中附带VEX文件。而在上市后场景中，VEX的作用更大——每当你收到新的CVE通报，都需要用VEX记录你的判定结果。

VEX的四种状态值

VEX标准定义了四种状态：

VEX状态	含义	典型场景
exploitable（可利用）	该漏洞可被利用，影响设备安全	远程代码执行漏洞暴露在设备网络接口上
not_exploited（不可利用）	该漏洞存在但无法被利用	漏洞所在的代码路径在设备配置中不会被执行
under_investigation（调查中）	正在评估可利用性	新披露的CVE，需要时间分析影响范围
fixed（已修复）	漏洞已通过补丁修复	已发布安全补丁，修复了该CVE

这里面的关键判定逻辑是：一个CVE存在不等于它可利用。比如一个开源库中存在缓冲区溢出漏洞，但你的设备从未调用那个有问题的函数——这就是"not_exploited"。VEX的价值在于减少噪音，让FDA和使用者把注意力集中在真正有风险的漏洞上。

VEX文档示例格式

以下是一个实际可用的VEX文档表格结构：

字段	内容示例
CVE ID	CVE-2026-12345
组件名称	openssl
组件版本	3.1.2
VEX状态	not_exploited
判定理由	该CVE影响OpenSSL的TLS服务端功能，本设备仅作为TLS客户端使用，不触发受影响代码路径
影响的设备版本	MonitorPro v2.1.0 ~ v2.3.5
修复计划	不适用（无需修复）
判定日期	2026-04-15
判定人	张工（安全团队）

再看一个exploitable的例子：

字段	内容示例
CVE ID	CVE-2026-67890
组件名称	libcurl
组件版本	7.88.1
VEX状态	exploitable
判定理由	该CVE为HTTP/2协议栈溢出漏洞，本设备使用libcurl进行固件更新下载，攻击者可通过中间人攻击触发远程代码执行
影响的设备版本	MonitorPro v2.1.0 ~ v2.3.5
修复计划	已启动补丁开发，计划30天内发布v2.3.6
判定日期	2026-04-18
判定人	李工（安全团队）

VEX的维护频率

VEX不是一次性文档。每当以下事件发生时，VEX需要更新：

NVD或GitHub Advisory披露了影响SBOM组件的新CVE
CISA KEV目录新增了影响你设备的条目
你发布了安全补丁（对应CVE的状态从exploitable变为fixed）
你的调查完成（状态从under_investigation变为最终判定）

在我们看来，最务实的做法是将VEX维护嵌入到漏洞分诊流程中——收到CVE后72小时内必须有VEX记录，即使是"under_investigation"也行，但不能空白。

漏洞接收与分诊流程

信息来源

持续的漏洞监控是Section 524B上市后要求的核心。FDA期望的不是年度评估，而是持续监控。你需要建立以下信息来源的监控机制：

监控来源	覆盖范围	更新频率
NVD（National Vulnerability Database）	所有已公开CVE	每日
GitHub Security Advisories	开源组件漏洞	每日
CISA KEV（Known Exploited Vulnerabilities）	已被实际利用的漏洞	每周（目录持续更新）
组件供应商安全公告	商业组件漏洞	按供应商发布频率
ISAO（信息共享与分析组织）	行业威胁情报	实时/每日
内部渗透测试与安全评估	自研代码漏洞	按评估周期

加入ISAO（如Health Information Sharing and Analysis Center，H-ISAC）对医疗器械企业来说是性价比很高的选择。H-ISAC的威胁情报通常比公开渠道快1-3天，而且在FDA检查中，加入ISAO本身就是你建立漏洞监控体系的证据。

分诊工作流

收到漏洞信息后，分诊流程大致如下：

第一步：SBOM匹配（24小时内）

新CVE披露后，对照SBOM检查受影响组件是否存在。如果SBOM中没有该组件，标记为"不影响"，记录VEX。如果有该组件但版本不在受影响范围内，同样标记并记录。

第二步：可利用性评估（48-72小时内）

如果SBOM中存在受影响组件，进行可利用性分析：

设备是否调用了漏洞所在的代码路径？
攻击者是否可以通过设备的网络接口触发该漏洞？
是否存在缓解措施（如编译选项、防火墙规则、身份验证）可以阻断利用？
漏洞是否被CISA KEV收录（表示已被实际利用）？

第三步：风险分级与补丁分类

根据可利用性评估的结果，将漏洞分为不同等级，对应不同的补丁策略（详见下一节）。

分诊决策表

条件	判定	VEX状态	后续动作
SBOM中无受影响组件	不影响	not_exploited	记录VEX，无需补丁
有受影响组件但不在受影响版本范围	不影响	not_exploited	记录VEX，无需补丁
有受影响组件，但漏洞代码路径未被执行	不影响	not_exploited	记录VEX，附技术论证
有受影响组件，代码路径被执行，但有缓解措施	低风险	not_exploited（附缓解说明）	记录VEX，评估是否补丁
有受影响组件，可远程利用，CVSS > 7.0	高风险	exploitable	启动补丁开发，通知客户
有受影响组件，可远程利用，已被CISA KEV收录	紧急	exploitable	30天内完成补丁，立即通知客户
有受影响组件，需要时间分析	待评估	under_investigation	72小时内完成分析并更新状态

这里有一个实操建议：把"under_investigation"的停留时间控制在72小时内。FDA在检查中可能会问：这个CVE从披露到你完成判定花了多久？如果你能拿出一个稳定的72小时SLA，会给检查员留下很好的印象。

补丁分类与发布策略

补丁分类矩阵

FDA将补丁分为两大类，对应不同的时间要求和报告义务：

分类	定义	时间要求	FDA报告义务
关键安全补丁	修复可利用漏洞，且残余风险为"未控制"	30天内开发，60天内部署	可能触发21 CFR 806报告
安全补丁	修复可利用漏洞，残余风险为"已控制"	合理时间范围内（通常90天）	通常不需要21 CFR 806报告
功能/常规补丁	非安全相关的功能改进或错误修复	按正常发布节奏	不需要

FDA区分"已控制风险"和"未控制风险"的逻辑是：如果一个漏洞虽然可利用，但你已经通过其他安全控制（如网络隔离、访问控制列表、禁用相关功能）将残余风险降到了可接受水平，那它就是"已控制"的，补丁的紧迫性可以适当降低。

补丁发布的质量体系要求

补丁不是随便打个包发出去就完了。在QMSR框架下，每个安全补丁都需要走设计控制和变更管理流程：

变更申请：记录漏洞描述、影响范围、修复方案
影响评估：补丁是否影响设备的基本安全和基本性能
验证测试：确认补丁有效且不引入新问题
回归测试：确认设备原有功能不受影响
审批放行：按照ISO 13485设计控制流程审批
客户通知：按照Cybersecurity Management Plan中定义的流程通知使用者
SBOM更新：同步更新SBOM和VEX
记录归档：所有文档归入设备主记录（DMR）

这套流程看起来和普通的设计变更差不多，但有一个区别：安全补丁的时间压力往往更大。对于紧急安全补丁，你可能需要在60天内完成从变更申请到客户部署的全流程，这就要求质量体系在安全补丁场景下有加速通道。

客户通知要求

Section 524B要求制造商向使用者（医院、诊所等）提供及时的安全更新通知。通知内容应包括：

漏洞描述和CVE编号
受影响的设备型号和软件版本
风险评估结论（对患者的潜在影响）
补丁的获取和安装方法
临时缓解措施（在补丁安装前）
预期的补丁安装时间和停机要求

通知的时效要求与补丁的紧急程度匹配：紧急安全补丁应在补丁发布的同时通知所有受影响客户；常规安全补丁可按照季度安全公告的节奏通知。

CAPA与投诉关联

网络安全事件何时触发CAPA

ISO 13485第8.5节要求CAPA流程整合网络安全事件。但不是每一个漏洞发现都需要开一个CAPA。判断标准如下：

网络安全事件类型	是否触发CAPA	触发条件
SBOM中发现新的CVE	通常不触发	除非在VEX中判定为exploitable且需要补丁
VEX判定为exploitable	可能触发	如果残余风险为"未控制"或补丁超过60天未发布
第三方报告的安全漏洞	触发	收到外部安全研究员或客户的漏洞报告
设备遭受实际攻击	触发	任何已确认的攻击或入侵事件
安全补丁发布后客户投诉	触发	补丁导致设备功能异常
定期安全评估发现新漏洞	视情况	取决于漏洞严重度和可利用性
未能在承诺时间内发布补丁	触发	违反Cybersecurity Management Plan中定义的时间线

漏洞报告何时变成投诉

这是一个在实务中经常被忽略的问题。在FDA的质量体系框架下，"投诉"是来自使用者或其他外部来源的关于设备质量问题的报告。如果一家医院的安全团队写信告诉你"你们设备的某个端口存在未加密的通信漏洞"，这封信就是一封投诉。

判断标准：

是投诉：外部人员（客户、安全研究员、ISAO合作伙伴）报告了与设备网络安全相关的问题
不是投诉：你自己通过SBOM扫描或漏洞监控主动发现的问题

前者需要按21 CFR 820.200（现在是QMSR下的等效条款）的要求记录、评估和处理。后者按内部设计变更流程处理即可。

CAPA记录应包含的内容

对于网络安全事件的CAPA记录，以下要素应当完整：

事件描述：CVE编号、漏洞类型、发现来源
影响评估：受影响的设备型号、版本、部署数量
根因分析：为什么这个漏洞会存在（组件选择不当？编译选项缺失？架构设计缺陷？）
纠正措施：发布补丁、更新SBOM/VEX、通知客户
预防措施：改进组件选择标准、加强SCA扫描、更新安全编码规范
有效性验证：确认补丁部署后的设备不再受该漏洞影响
关联记录：相关的设计变更记录、测试报告、客户通知记录

就实际经验而言，FDA检查中最常出问题的是根因分析和预防措施。很多企业的CAPA只写了"发布了补丁"就结案，没有分析为什么会引入有漏洞的组件，也没有制定防止类似问题再次发生的措施。这种CAPA在检查中会被认为是不完整的。

协调漏洞披露（CVD）

CVD为什么不是可选项

2026年FDA网络安全指南明确将CVD列为强制性流程。这不是一个建议，是要求。你的Cybersecurity Management Plan中必须包含CVD章节，涵盖以下内容：

接收外部安全研究员报告的渠道
漏洞分诊和响应的时间线
与报告者的沟通流程
补丁开发和发布的承诺时间
向使用者和监管机构披露的策略

CVD政策的核心内容

一份合规的CVD政策应当包含：

CVD要素	要求
报告渠道	提供专门的security@邮箱或Web表单，确保安全研究员可以方便地提交报告
确认响应	收到报告后24小时内发送确认回执
初步评估	72小时内完成初步评估并回复报告者
漏洞验证	与报告者合作验证漏洞的可复现性
补丁时间线	与报告者协商补丁发布日期（通常90天内）
披露策略	补丁部署后按约定时间公开披露漏洞详情
报告者认可	在披露中感谢安全研究员的贡献（经其同意）

与安全研究员的合作

就实际经验而言，与外部安全研究员的合作是企业CVD流程中最敏感的部分。以下几点值得注意：

不要威胁报告者：有企业在收到漏洞报告后第一时间让法务发律师函，这在行业中的口碑非常差。FDA在检查中也可能询问你如何处理外部报告
建立清晰的SLA：报告者最在意的是他们的报告是否被认真对待。即使最终判定漏洞不可利用，也要给出详细的技术论证
主动沟通：不要让报告者在黑暗中等待。每周更新一次进展，即使进展是"我们还在分析"

客户沟通策略

在漏洞披露的时间线上，客户（医院、诊所）的沟通优先级最高。一般遵循以下顺序：

内部分诊完成 → 通知受影响客户（附临时缓解措施）
补丁开发完成 → 通知所有客户（附补丁安装指引）
补丁部署率达标（通常60-90天内） → 公开披露漏洞详情
公开披露 → 更新CVD记录和VEX

行业调研数据表明，相当比例的医疗机构在过去一年中经历过针对医疗器械的网络攻击，其中多数报告了对患者护理造成了影响（RunSafe Security 2026 Medical Device Cybersecurity Index调查了551名医疗行业专业人士）。这个数据从侧面说明，你的客户非常在乎设备的网络安全状况——主动、及时的沟通能建立信任，也能降低被攻击后的法律风险。

检查证据准备

FDA检查什么

QMSR生效后，FDA的检查框架已经从旧版的QSIT（质量体系检查技术）更新为CP 7382.850。新的检查程序不再是按子系统抽样检查，而是按全生命周期风险管理的逻辑来评估。对于cyber device，检查员会重点关注以下方面：

检查前自查清单

检查项	应提供的证据	常见问题
SBOM管理	SBOM生成、更新和维护的SOP；每版设备的SBOM副本	SBOM停留在提交时的版本，从未更新
VEX记录	所有已评估CVE的VEX文档，含判定理由和签名	发现CVE但没有VEX记录，或VEX停留在旧版本
漏洞监控	监控来源清单、自动化工具配置、日志记录	只依赖手动检查NVD，没有系统化监控
补丁记录	补丁的变更记录、验证报告、客户通知副本	补丁走了研发流程但没有走设计控制
CAPA记录	网络安全相关CAPA的完整记录	漏洞修复了但没开CAPA，或CAPA缺少根因分析
CVD政策	书面的CVD政策、报告渠道页面截图、历史报告处理记录	没有书面CVD政策，或报告渠道无法访问
客户通知	安全公告副本、发送记录、客户签收确认	没有按照承诺的时间线通知客户
网络安全管理计划	Cybersecurity Management Plan文件	计划停留在premarket版本，没有更新
安全测试记录	定期安全评估和渗透测试报告	只在premarket做过一次渗透测试
组件生命周期管理	EOL/EOS组件的跟踪记录和迁移计划	SBOM中存在已停止维护的组件但没有迁移计划

检查中的常见问题

根据行业反馈，FDA检查员在cyber device检查中倾向于追问以下几个方向：

"你们上一次更新SBOM是什么时候？为什么？"——如果你回答"提交之后没有更新过"，检查基本就朝着不利方向走了
"这个CVE你们是怎么判定的？谁做的判定？依据是什么？"——VEX中的判定理由需要有技术支撑，不能只写"不影响"
"你们的补丁用了60天部署，这期间设备在客户现场的风险是怎么管理的？"——你需要解释临时缓解措施
"客户的安全补丁部署率是多少？你们怎么追踪的？"——FDA越来越关注补丁是否真正到达了终端设备

常见失败模式

失败模式一：静态SBOM

症状：SBOM停留在premarket提交时的版本，设备已经在市场上运行两年，SBOM从未更新。

根本原因：把SBOM当作提交文档而非运营工具。没有人被指定负责SBOM维护，也没有更新触发机制。

后果：FDA交叉比对SBOM与NVD时发现组件版本已经过时，包含多个已知严重漏洞，但企业声称SBOM"没有问题"。检查员会质疑你的整个网络安全管理体系。

失败模式二：有SBOM但没有VEX

症状：SBOM中列出了几十个开源组件，其中不乏包含高危CVE的组件，但没有VEX文档说明这些CVE的可利用性。

根本原因：不了解VEX的作用，或者认为VEX只适用于premarket提交。

后果：FDA无法判断你的设备是否真的安全。审查员会逐一追问每个CVE，极大延长审查周期。在上市后场景中，缺失VEX意味着你没有漏洞分诊的证据。

失败模式三：没有CVD政策

症状：无法提供书面的协调漏洞披露政策，或者security@邮箱不存在/无人值守。

根本原因：认为CVD是大企业的事，或者觉得"没有人会来报告漏洞"。

后果：2026年指南已将CVD列为强制要求。没有CVD政策属于质量体系缺失，FDA可以发出警告信。此外，安全研究员如果找不到你的报告渠道，可能直接公开披露漏洞（即"零日披露"），这对品牌声誉的打击远大于主动管理。

失败模式四：CAPA与网络安全脱节

症状：网络安全事件（如漏洞修复）在研发或IT部门内部处理，没有进入质量体系的CAPA流程。

根本原因：网络安全被当作"技术问题"而非"质量问题"，质量团队和网络安全团队之间缺乏协作机制。

后果：ISO 13485第8.5节要求CAPA整合网络安全事件。如果检查员发现漏洞修复没有CAPA记录，会认为你的质量体系不完整。更严重的是，没有CAPA意味着没有根因分析和预防措施，同样的漏洞很可能再次出现。

失败模式五：没有客户通知时间线

症状：Cybersecurity Management Plan中没有定义安全补丁的客户通知时间线，或者定义了但没有执行。

根本原因：补丁发布流程与客户沟通流程分离，安全团队发布了补丁但没有通知市场/售后团队去联系客户。

后果：Section 524B要求制造商向使用者提供及时的安全更新。如果你发布了补丁但客户不知道，设备继续以有漏洞的版本运行，这在FDA看来等同于"没有采取行动"。

失败模式六：网络安全风险管理混入ISO 14971

症状：只有一个风险管理文件，用ISO 14971的P×S矩阵同时处理安全风险和网络安全风险。

根本原因：不了解FDA对两套风险评估体系的要求差异。

后果：2026年修订指南明确指出网络安全风险必须独立于ISO 14971进行评估。混在一起做会导致网络安全风险被低估——一个概率"极低"但影响"严重"的远程代码执行漏洞，在ISO 14971矩阵中可能被评为"可接受"，但在网络安全框架下绝对不可接受。

如何补救

针对静态SBOM

立即用当前构建环境重新生成SBOM（CycloneDX或SPDX格式）
将SBOM生成集成到CI/CD管道，确保每次构建自动生成
指定SBOM的负责人（通常是配置管理或安全团队）
建立SBOM变更日志，记录每次更新的原因和内容
将SBOM更新纳入设计变更控制流程

针对缺失VEX

从当前SBOM出发，扫描所有组件的已知CVE
对每个CVE进行可利用性评估，生成VEX记录
建立VEX模板和审批流程，确保后续新CVE的VEX能在72小时内完成
将VEX维护嵌入漏洞分诊流程，不再单独处理

针对没有CVD政策

起草CVD政策文件，涵盖报告渠道、响应时间线、披露策略
在公司官网设立security@邮箱或安全报告页面
指定CVD协调员（通常由安全团队负责人担任）
在公司内部建立CVD响应流程，确保法务、研发、质量、市场团队都清楚各自的职责
将CVD政策纳入Cybersecurity Management Plan

针对CAPA脱节

梳理过去12个月的所有网络安全事件，评估哪些应该触发CAPA但没触发
为漏掉的网络安全事件补建CAPA记录
在CAPA SOP中增加网络安全事件的触发条件和评估标准
建立网络安全团队与质量团队的定期沟通机制（建议每月）
在CAPA表单中增加网络安全专用字段（CVE编号、CVSS评分、VEX状态）

针对客户通知缺失

建立受影响设备的客户清单（包括设备型号、软件版本、部署位置）
在Cybersecurity Management Plan中明确不同紧急程度的通知时间线
准备安全通知模板，减少紧急情况下的起草时间
建立通知发送和签收的追踪机制
定期演练客户通知流程（建议每季度一次桌面演练）

针对网络安全风险与ISO 14971混淆

将网络安全风险评估从ISO 14971文件中独立出来
建立单独的Security Risk Management Report（SRMR），使用可利用性评估方法
在两份文件之间建立交叉引用（标注哪些网络安全风险可能导致ISO 14971中的伤害场景）
培训风险分析团队，确保他们理解两套评估体系的差异
在下一次设计评审中验证两份风险文件的独立性和一致性

FAQ

Q1：已经获批的设备，FDA会检查我们的SBOM更新吗？

会。QMSR生效后，FDA检查（包括常规检查和有因检查）的框架已经更新为CP 7382.850，网络安全是独立的检查领域。检查员可能会要求你展示最新的SBOM、VEX记录和补丁历史。如果你提交时的SBOM和当前的SBOM完全一样，而设备已经在市场上运行了一年多，这本身就是一个危险信号。

Q2：VEX中的"not_exploited"判定，FDA会接受吗？

会，但前提是你的判定理由有充分的技术论证。FDA并不期望SBOM中每个组件都完美无瑕——他们也知道这不现实。VEX的价值就在于区分"有漏洞"和"有风险"。如果你的"not_exploited"判定附上了代码路径分析、编译配置说明或攻击面论证，FDA一般会接受。反过来，如果你只写了"经评估不影响设备"而没有具体理由，FDA可能会追问细节。

Q3：我们的设备只有USB接口，算cyber device吗？

根据Section 524B(c)的定义和FDA 2026年指南的解释，算。USB接口技术上具备连接能力（可以通过USB连接到联网的电脑），FDA在多次公开说明中确认了这一点。我们的建议是：当拿不准的时候，按cyber device来处理。多做一些网络安全工作，总比在检查中被认定违规要好。

Q4：补丁必须通过FDA审批后才能发布吗？

大多数安全补丁属于"设备改进"，不需要FDA审批。但如果补丁改变了设备的基本性能或预期用途，可能需要通过510(k)或其他途径提交。在QMSR框架下，安全补丁需要走内部的设计变更控制流程，但不一定需要FDA的事前批准。对于改变设备标签信息（如新增网络安全声明）的补丁，可能需要参考21 CFR 806的要求评估是否需要报告。

Q5：小企业没有专门的安全团队，怎么做SBOM/VEX维护？

几个务实的建议：第一，用自动化工具降低人力成本。Trivy、Grype等开源工具可以自动扫描SBOM中的CVE。第二，将SBOM/VEX维护整合到现有的质量体系角色中——不一定需要专门的"安全团队"，配置管理工程师加上一位有网络安全知识的评审人就够了。第三，考虑使用第三方服务（如安全托管服务），将漏洞监控和VEX编写外包给专业团队，质量团队保留审批职责。行业调研显示，越来越多的大型医疗采购方在招标中将SBOM列为硬性要求——这意味着不做SBOM不仅是合规风险，也是商业风险。

Q6：协调漏洞披露中，安全研究员要求赏金怎么办

FDA并没有要求企业必须提供漏洞赏金。但你需要有一个明确的回复政策。如果研究员要求赏金而你不提供，礼貌地说明你的政策，同时确保他们的报告得到认真对待和及时响应。很多安全研究员更在意的是响应速度和技术认可，而不是金钱奖励。如果预算允许，设立一个适度的赏金计划（如根据漏洞严重度给予$500-$5,000）可以显著提升外部安全研究员的参与意愿，进而提升你的漏洞发现能力。不过，赏金计划是加分项，不是FDA要求的——CVD政策本身才是强制的。

Q7：组件已经停止维护（EOL），但SBOM里还在用，怎么办？

这是检查中的高频发现。处理方式分三步：第一步，在SBOM中标记该组件的支持级别为"已弃用（abandoned）"或"已停止维护（end-of-support）"，并注明EOS日期。第二步，在VEX中记录该组件的已知漏洞状态，并说明你采取的缓解措施（如网络隔离、功能禁用）。第三步，制定迁移计划，在合理的时间范围内将该组件替换为仍在活跃维护的替代方案。如果你能拿出这三步的证据，FDA一般会接受你在过渡期内的管理方式。什么都不做是最差的选择。

参考资源：

FDA Quality Management System Regulation (QMSR) — FDA QMSR官方页面，包含法规文本和实施指南
FDA Cybersecurity in Medical Devices Guidance — FDA网络安全指南主页，含2026年2月修订版
A Guide to FDA's SBOM Requirements for Medical Devices (2026 Update) — Hattrick IT的SBOM合规详解，含NTIA最小元素清单
FDA Guidance on Post-Market Medical Device Cybersecurity — Censinet对FDA上市后网络安全要求的解读
Medical Device Cybersecurity in 2026 — RunSafe Security的2026年医疗器械网络安全现状报告，含行业数据
CISA Known Exploited Vulnerabilities Catalog — CISA KEV目录，FDA交叉比对SBOM的主要数据源