乐于分享
好东西不私藏

第三方软件出事了谁负责?FDA要求厂家“兜底”所有组件风险

第三方软件出事了谁负责?FDA要求厂家“兜底”所有组件风险

点击上方蓝字关注我们

上一篇我们讲了SBOM的三份配套报告,今天来聊一个更扎心的现实问题。你设备里60%到80%的代码其实都是第三方或开源组件,一旦这些组件出了漏洞,到底谁来负责?很多厂商的心态是:我只管自己写的那部分代码,开源组件漏洞找社区,商业组件找厂商。但FDA的态度非常明确——你是医疗器械制造商,你负全责,没有任何推卸的空间。2026版指南Section V.A.4和ISO 13485第7.4节已经把这条写死了,今天我们就一次性讲透,在开源组件漏洞管理上,制造商到底要兜哪些底、怎么兜。

晟信信息科技

FDA的核心立场:厂家是“最终责任人”

FDA在指南里说得很清楚:

"When these components are incorporated, security risks of the software components should become factors of the overall medical device system risk management processes and documentation."

翻译:不管代码是谁写的,只要进了你的设备,就是你的事!

责任清单:厂家必须做到什么?

责任项
具体要求
对应指南条款
风险评估
对所有软件组件(含第三方/开源)进行网络安全风险评估
Section V.A.4
漏洞管理
监控所有组件的漏洞,并及时响应
Section V.A.4.b
支持兜底
如果第三方停止支持,厂家要有应对方案
Section V.A.4
标签告知
在说明书中向用户披露组件信息及风险
Section VI.A
源代码保管
建立源代码托管或备份机制,确保长期可维护
Section V.A.4
常见甩锅话术(FDA一律不接受)
01.

“这个漏洞是开源组件的问题,我们管不了”

FDA观点:你可以选择不用这个组件。既然选了,就要负责管理它的风险。

✅ 正确做法:

● 建立开源组件选型标准(社区活跃度、维护状态、漏洞历史)

● 持续监控所选组件的漏洞通告

● 有能力自行修复或替换问题组件

02.

“商业组件厂商说这个版本已经停止支持了,我们也没办法”

FDA观点:这是你的供应链管理问题。选型时就应该考虑生命周期。

✅ 正确做法:

● 选型时确认组件的长期支持承诺(LTS版本优先)

● 合同中明确厂商的安全更新义务

● 准备好替代方案(厂商倒闭/停止支持的Plan B)

03.

“用户自己选的运行环境,出了问题不关我们事”

FDA观点:如果你的设备宣称支持某环境,就必须评估该环境的安全风险。

✅ 正确做法:

● 明确支持的操作系统和版本

● 评估所支持环境的安全风险

● 在标签中告知用户最低安全配置要求

供应链安全:FDA要求从选型就开始管控

指南引用ISO 13485第7.4节(采购),要求制造商建立供应商管理流程。

第三方软件选型时的安全检查清单

检查项
要问的问题
红灯信号🚨
维护状态
是否仍在活跃维护?最近一次更新是什么时候?
超过1年没更新
漏洞历史
过去一年有多少CVE?严重程度如何?响应速度如何?
高危漏洞超过3个月未修复
社区/厂商活跃度
GitHub star/contributor数量?厂商财务状况?
单人维护、公司濒临破产
许可证
什么许可证?是否允许商业使用和修改?
GPL传染性条款影响闭源代码
支持承诺
有LTS版本吗?承诺支持到什么时候?
没有明确的EoL日期
依赖链
它又依赖了什么?那些依赖健康吗?
依赖链深且包含问题组件

💡 建议:建立内部开源软件使用白名单,只有通过审查的组件才能引入。

第三方停止支持了怎么办?

实操1

这是最常见的供应链风险场景。FDA要求厂家提前想好Plan B。

应对策略矩阵

情况
推荐方案
备选方案
组件厂商倒闭
迁移到功能相似的主流组件
自行维护分支(需有源代码)
版本EoL但新版不兼容
评估升级成本 vs 自行维护成本
加强补偿控制,限制攻击面
开源项目无人维护
Fork代码自行维护
寻找活跃的替代品
许可证变更
替换为许可证友好的替代品
法律评估 + 商业谈判

源代码托管:FDA的“兜底”建议

FDA在指南里特别提到:

"device manufacturers should establish and maintain custodial control of device source code throughout the lifecycle of a device as part of configuration management."

实操建议:

1. 确保你有所有第三方组件的源代码访问权(开源天然有,商业组件合同中要约定)

2. 建立源代码托管机制(如内部GitLab、第三方托管服务)

3. 保留完整编译环境(工具链、依赖库版本),确保多年后还能重新编译

💡 惨痛教训:某厂商用了10年前的编译器,厂商早没了,想修复漏洞时发现根本编译不了!

如何持续监控第三方组件漏洞?

实操2

光靠人工盯CVE列表是不现实的。需要建立自动化监控机制。

推荐的监控工具链

工具类型
推荐选项
作用
SCA工具
Black Duck、Snyk、OWASP Dependency-Check
自动扫描SBOM中的已知漏洞
漏洞情报
CISA KEV、NVD、厂商安全公告
获取最新漏洞信息
SBOM管理平台
OWASP Dependency-Track、商业化的SBOM管理平台
集中管理SBOM和漏洞状态

监控流程建议

1. 定期自动扫描SBOM,对比最新漏洞数据库

2. 发现新漏洞 → 自动告警 → 人工评估

3. 评估影响(本设备是否受影响?可利用性如何?)

4. 根据风险等级触发响应流程

- 严重/KEV漏洞:紧急响应,72小时内出方案

- 高危漏洞:纳入下一补丁周期

- 中低危漏洞:纳入常规版本规划

5. 更新组件风险评估报告

在标签中向用户透明披露

实操3

FDA要求厂家把供应链风险信息写进标签(Section VI.A)。

标签中应包含的供应链安全信息

信息类型
示例内容
目的
SBOM
提供或说明如何获取
用户了解自己用的设备含什么软件
组件支持期限
“本设备软件中包含的XXX组件支持至2028年12月”
用户预判未来风险
停止支持后的风险说明
“超过支持期限后,网络安全风险可能增加”
风险转移告知
安全配置要求
“必须运行于防火墙保护的内网环境”
补偿控制传达

eSTAR中如何体现供应链风险管理?

在eSTAR的以下附件中需要体现你的供应链管控能力:

eSTAR附件
体现供应链管理的部分
SBOM
完整清单
SBOM Support Report
组件支持状态和EoL计划
Software Component Risk Management Report
组件漏洞评估和处置
Cybersecurity Management Plan
上市后持续监控组件漏洞的计划
Labeling Report
向用户披露的供应链信息

三个灵魂拷问

FDA审评员最可能问的

01.

“你设备里用的OpenSSL版本明年就停止支持了,你打算怎么办?”

❌ 错误回答:到时候再说 / 用户自己负责

✅ 正确回答:

● 已规划升级路线,将在XX日期前迁移至OpenSSL 3.X LTS版本

● 过渡期内将密切关注该版本的漏洞通告

● 已评估如果出现严重漏洞时的应急响应时间(X天)

02.

“这个开源组件已经两年没更新了,你为什么要用它?”

❌ 错误回答:它功能正好满足需求

✅ 正确回答:

● 选型时该组件状态良好,我们进行了X项安全评估

● 我们已Fork代码并具备自行维护能力

● 目前正在评估替代方案,预计X时间完成迁移

03.

“你怎么确保第三方组件没有被植入后门?”

❌ 错误回答:我们信任厂商

✅ 正确回答:

● 从官方渠道获取组件(校验哈希值)

● 使用SCA工具扫描已知恶意包

● 关键组件进行源代码审查

● 二进制进行病毒/恶意软件扫描

总结:厂家的供应链安全“五个一”工程

动作
具体内容
一份清单
完整的SBOM,包括支持状态
一套流程
组件选型→引入→监控→响应的全流程
一个Plan B
每个关键第三方组件的替代方案
一份存档
源代码托管+编译环境保留
一段话术
标签中向用户清晰传达供应链风险

FDA不要求你用的每个组件都完美无漏洞——这不可能。但要求你知道用了什么、知道有什么风险、知道怎么应对、知道怎么告诉用户。

你们公司遇到过第三方组件突然停止支持的情况吗?怎么处理的?评论区聊聊!

END

公众号:晟信信息

微信号:shengxinxinxikeji

扫码添加官方微信了解更多内容~

点个在看,你最好看