乐于分享
好东西不私藏

软件供应链攻击怎么防?FDA要求从源头管控第三方组件

软件供应链攻击怎么防?FDA要求从源头管控第三方组件

点击上方蓝字关注我们

上一篇我们讲了互操作性的安全风险,今天来聊一个更隐蔽更难防的攻击面——软件供应链安全。先问一个问题:你的医疗设备里多少代码是自己写的?现实是百分之六十到八十的代码来自第三方,开源库、商业SDK、外包开发、芯片厂商提供的BSP,这些代码一旦有漏洞或被植入后门,你的设备就跟着遭殃。更扎心的是FDA的态度非常明确:不管代码是谁写的,既然用进了你的设备,你就要负责管理它的风险,没有任何推卸的空间。2026版指南Section V.A.4和ISO 13485第7.4节把供应链安全要求写得清清楚楚,今天我们就来手把手讲清楚FDA要求你怎么管控第三方组件、在eSTAR里又该怎么体现。

晟信信息科技

什么是软件供应链攻击?

软件供应链攻击是指:攻击者不直接攻击你的设备,而是攻击你依赖的第三方组件、工具或服务。

典型攻击路径

攻击者 → 入侵开源项目维护者账号 → 在流行库中植入后门 → 你下载使用了这个库 → 你的设备被植入后门

真实案例:xz-utils CVE-2024-3094后门事件(2024年)

一个几乎被所有Linux系统使用的基础压缩库xz-utils,被攻击者潜伏3年,成功植入后门。如果不是被微软工程师偶然发现,这个后门可能已经进入了无数生产系统。

医疗设备领域的真实风险

漏洞名称
受影响组件
影响范围
关联CVE
URGENT/11
实时操作系统IPnet
全球数亿台医疗设备
CVE-2019-12256CVE-2019-12257CVE-2019-12258CVE-2019-12262CVE-2019-12264CVE-2019-12259CVE-2019-12265
SweynTooth
蓝牙低功耗协议栈
植入设备、监护仪等
CVE-2019-16336‌CVE-2019-17060‌CVE-2019-17517‌CVE-2019-17518‌CVE-2019-17519‌CVE-2019-17520‌CVE-2019-19192‌CVE-2019-19193‌CVE-2019-19194CVE-2019-19195‌CVE-2019-19196‌
Ripple20
Treck TCP/IP协议栈
输液泵、监护仪等
CVE-2020-11896CVE-2020-11897CVE-2020-11898CVE-2020-11899CVE-2020-11900CVE-2020-11901CVE-2020-11902CVE-2020-11903CVE-2020-11904CVE-2020-11905CVE-2020-11906CVE-2020-11907CVE-2020-11908CVE-2020-11909CVE-2020-11910CVE-2020-11911CVE-2020-11912CVE-2020-11913CVE-2020-11914‌‌
Log4Shell
Apache Log4j
使用Java的医疗设备和系统
CVE-2021-44228

这些漏洞的共同点:不是设备厂商自己写的代码,但出事了厂商要负责。

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."

翻译:不管代码是谁写的,只要进了你的设备,就是你的风险,你来管理。

你必须做到的四个“知道”

要求
说明
对应指南条款
知道用了什么
完整的SBOM,包括间接依赖
Section V.A.4
知道有什么风险
每个组件的已知漏洞评估
Section V.A.4.b
知道怎么应对
漏洞响应和组件替换方案
Section V.A.4
知道怎么告诉用户
标签中披露供应链风险
Section VI.A

全流程供应链安全管控

FDA期望你在组件的整个生命周期都有管控措施。

01.

选型——把好入口关

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

💡 建立内部白名单机制:只有通过上述审查的组件才能被引入。

02.

使用——持续监控

监控活动
频率
工具/方法
SBOM维护
每次发版更新
SCA工具(Black Duck、Snyk、OWASP Dependency-Check)
漏洞扫描
每日/每周
自动对比NVD数据库
CISA KEV监控
实时
重点关注正在被利用的漏洞
厂商安全公告订阅
持续
操作系统、第三方库厂商

特别提醒:CISA KEV目录是FDA明确点名必须监控的来源!

03.

响应——出了问题快速应对

场景
应对措施
组件发布安全补丁
评估影响,按SLA升级组件版本
组件发现0day漏洞
评估可利用性,必要时采取补偿控制(如网络隔离)
组件厂商停止支持
启动替换方案,或自行维护分支
组件厂商倒闭
迁移到替代组件,或使用源代码自行维护

FDA特别关心:你有没有Plan B?

"Develop contingency plans for the possibility that a third-party company goes out of business or stops supporting a licensed product."(Appendix 1.H)

04.

兜底——源代码托管

FDA在指南里专门提了一个要求:

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

翻译:你必须有能力在第三方“消失”后,仍能维护你的设备的源代码。

措施
说明
源代码托管
内部GitLab、第三方托管服务(如GitHub Escrow)
保留编译环境
完整的工具链、依赖库版本,确保多年后仍能编译
商业组件源码获取权
在采购合同中约定,厂商倒闭时提供源码

如何在eSTAR中体现供应链安全

供应链安全不是单独的附件,而是渗透到多个已有附件中。

01.

威胁模型

必须体现:将“供应链攻击”作为一类独立威胁进行分析。

威胁场景
示例分析
开源组件被植入后门
攻击者在流行npm包中植入挖矿代码,设备CPU占用100%
第三方库存在已知漏洞
OpenSSL存在心脏滴血漏洞,攻击者可窃取密钥
厂商更新服务器被攻破
攻击者通过更新通道分发恶意软件
开发工具链被污染
编译器被植入后门,生成的二进制包含恶意代码
02.

SBOM(三件套)

这是供应链安全在eSTAR中最核心的体现。

附件
供应链安全相关内容
SBOM本体
完整列出所有第三方组件及版本
SBOM支持报告
每个组件的维护状态、停止支持日期
软件组件风险管理报告
每个组件的已知漏洞评估和处置
03.

上市后管理计划

必须体现:供应链持续监控机制。

内容
说明
监控来源
除NVD外,还需监控各组件厂商的安全公告
EoL组件替换计划
对于即将停止支持的组件,说明替换时间表
供应链中断应急预案
如果关键组件厂商突然倒闭,怎么应对?
04.

标签合规报告

必须体现:向用户披露供应链风险。

内容
说明
SBOM获取方式
用户如何获取最新的SBOM
组件支持期限
告知用户关键组件的支持截止日期
停止支持后风险
超过支持期限后,安全风险将增加

供应链安全红黑榜

🟢 红榜(FDA认可的做法)

做法
说明
✅ 建立组件选型安全标准
引入前进行安全评估,建立白名单
✅ 维护完整准确的SBOM
机器可读格式,包含间接依赖
✅ 持续监控组件漏洞
自动化扫描,重点关注CISA KEV
✅ 建立供应链应急预案
关键组件有Plan B
✅ 保留源代码和编译环境
确保长期可维护
✅ 合同约定安全义务
与商业组件厂商明确安全更新承诺
✅ 使用官方渠道获取组件
校验哈希值,防止被篡改

🔴 黑榜(FDA明确反对的做法)

做法
为什么不行
❌ 不知道用了什么组件
无法评估风险,出了事都不知道
❌ 使用已停止维护的组件
未来发现漏洞没人修
❌ 不监控组件漏洞
设备带着已知漏洞上市
❌ 没有Plan B
厂商倒闭就傻眼
❌ SBOM不全或不准
漏洞扫描漏报,给用户虚假安全感
❌ 从非官方渠道下载组件
可能被植入后门
❌ 把供应链责任推给用户
FDA:你是厂商,你负责

三个最容易翻车的供应链安全问题

01.

SBOM不完整

“我们只列了直接依赖,间接依赖太多了列不完”

FDA观点:间接依赖也是依赖,也可能有漏洞。Log4Shell就是典型的间接依赖漏洞——很多人根本不知道自己用了Log4j!

✅ 正确做法:

● 使用SCA工具自动扫描传递性依赖

● 确保SBOM包含所有层级

02.

用了“僵尸”组件

“这个库功能正好满足需求,虽然3年没更新了,但能用就行”

3年没更新的库,大概率积累了已知漏洞没修复,而且未来发现新漏洞也不会有人修。

✅ 正确做法:

● 选型时避开维护不活跃的组件

● 如果已在使用,评估迁移成本,制定替换计划

03.

对商业组件厂商“盲目信任”

“我们用的是大厂的商业SDK,他们肯定很安全”

大厂也会出漏洞,而且大厂的EoL决策可能影响你的产品生命周期。

✅ 正确做法:

● 合同中明确安全更新义务和支持期限

● 监控厂商安全公告

● 即使是大厂,也准备好Plan B

总结:供应链安全的“四个有”

原则
要求
有清单
完整的、准确的、机器可读的SBOM
有监控
持续追踪组件的漏洞和支持状态
有预案
关键组件出问题时的Plan B
有交代
向用户透明披露供应链风险

FDA不要求你用的每个组件都完美无漏洞——这不可能。但要求你:

● 知道用了什么

● 知道有什么风险

● 知道怎么应对

● 知道怎么告诉用户

你们遇到过第三方组件突然停止支持的坑吗?怎么解决的?评论区聊聊!

往期回顾

eSTAR必填!网络安全风险管理报告怎么写才不被退回?

你的威胁模型FDA认可吗?eSTAR要求“列出方法论”,别再只交一张数据流图了!

FDA明确表态:网络安全风险不看概率,看可利用性!

END

公众号:晟信信息

微信号:shengxinxinxikeji

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

感谢您的推荐,我们一路同行!