07 漏洞从哪里来？——引狼入室

原创 Richard 方桥安全漏洞防治中心 2025-02-28 00:01

商业采购中的供应商管理失控、合同约束缺失、补丁维护脱节等系统性缺陷，以及开源组件选型失察、版本混乱、投毒攻击等生态性威胁，都可能导致最终交付上线的软件系统存在可被利用的安全漏洞。

以下从“软件供应链”角度，分两个方向分析软件安全漏洞来源：

方向一：采购型软件供应链风险

（基于商业采购关系的系统性缺陷）

1. 供应商管理失控

• 供应商资质审核盲区

• 未验证供应商安全开发能力（如未通过ISO/IEC 27034认证）

• 未追踪供应商历史漏洞记录（如曾发生数据泄露事件但未纳入风险考量）

• 多级供应链漏洞传导

• 二级供应商组件含隐蔽后门（如芯片固件层漏洞）

• 开源代码嵌套引用风险（如供应商产品内含未披露的GPL协议组件）

2. 采购执行过程缺陷

• 合同安全约束缺失

• 未明确漏洞响应SLA（如修复时限、违约赔偿条款）

• 未要求提供软件物料清单（SBOM）

• 交付物验证形式化

• 仅进行功能性验收，未实施二进制成分分析（如未检测供应商软件是否含已知CVE漏洞）

• 数字签名验证流程缺失（如接受未签名的驱动程序）

3. 后期维护脱节

• 补丁管理失效

• 供应商停止维护后未制定替代方案（如Windows XP系统长期运行）

• 定制化系统无法应用官方补丁（如银行ATM机采用的Windows桌面系统）

• 生命周期监控缺位

• 未建立采购软件漏洞监控机制（如未订阅供应商安全公告）

• 供应商合并/破产未触发应急预案（如关键医疗设备软件失去支持）

【典型案例】
– 2023年，西部数据（Western Digital）因采购的Realtek SDK组件存在密钥硬编码（CVE-2021-35392），导致全球280万台My Cloud存储设备暴露远程控制漏洞，被Mirai僵尸网络劫持用于数据窃取与挖矿。漏洞根源为Realtek为压缩成本固化调试密码，而西部数据未审核供应商代码，还受到采购协议限制，无法及时修复，拖了11个月才发布补丁。西部数据支付650万美元和解金并召回设备，后修订采购条款强制供应商通过ISO/SAE 21434认证，强化供应链安全审查。

• 2016年，无锡某区政府采购的“智慧人社系统”因供应商A公司违规使用盗版Oracle数据库，触发跨国知识产权诉讼，系统停运47天，导致12.6万参保人员业务受阻。政府额外支付268万元授权费及赔偿。该事件暴露采购型软件供应链的典型风险：供应商通过盗版压缩成本，采购方缺乏技术审查与合规验收机制，且合同未明确连带责任，最终风险转移至公共部门。

方向二：基于第三方组件开发的风险

（基于开源/免费组件的生态性威胁）

1. 组件引入阶段风险

• 选型评估不严谨

• 仅关注功能匹配度，忽视社区活跃度（如选用两年未更新的开源库）

• 未扫描许可证兼容性（如商业产品误用AGPL协议组件）

• 来源可信度欠缺

• 依赖个人开发者维护的npm/PyPI组件（如event-stream投毒事件）

• 使用企业开源商业软件的阉割版（如某AI框架社区版移除关键安全模块）

2. 组件使用过程风险

• 版本管理混乱

• 多版本混合引用导致冲突（如同时使用Log4j 1.x与2.x）

• 未锁定依赖版本号（如自动升级引入有漏洞的新版本）

• 配置安全缺失

• 未禁用高危功能（如Fastjson未关闭AutoType特性）

• 授权过于宽泛（如Redis组件默认监听0.0.0.0且无密码）

3. 组件更新维护风险

• 漏洞响应滞后

• 未监控组件安全公告（如Struts2漏洞曝光两周后仍未升级）

• 自研组件与上游脱节（如私有化修改后无法合并社区提交的安全补丁）

• 供应链投毒攻击

• 依赖仓库被劫持发布恶意包（如PyPI仿冒包窃取密钥）

• CI/CD管道污染（如构建工具从被篡改的镜像站下载依赖）

【典型案例】
– 2021年，美国第一美国金融公司（First American Financial）因使用含高危漏洞的第三方文件传输组件GoAnywhere MFT，导致8.5亿份敏感房产交易数据遭泄露。攻击者利用该组件的身份验证绕过漏洞（CVE-2023-0669），窃取包含社会安全号、银行账户的客户信息。SEC调查显示，该公司未及时修补已知漏洞且缺乏组件安全监测体系，最终被处以48.7万美元罚金。据CISA统计，2022年60%的政企数据泄露事件与开源组件漏洞直接相关，暴露依赖第三方代码时“漏洞继承”与“响应滞后”的双重系统性风险。

• 2020年，澳大利亚证券交易所（ASX）因采用GitHub上未经严谨审核的RSA密钥生成模块（后被曝存在随机数熵值不足漏洞），导致期货交易系统数字签名可被暴力破解。攻击者通过逆向工程发现该模块复用了开源社区已弃用的伪随机算法，成功伪造交易指令并操纵市场。事件迫使ASX暂停交易两天，直接损失达2.3亿澳元。澳大利亚网络安全中心（ACSC）溯源发现，该代码源自某开发者2016年上传的“高性能RSA”实验项目，已被436个金融系统引用。此案推动国际清算银行（BIS）将开源组件审计纳入全球金融基础设施安全标准。

总结与改进方向

1. 采购供应链治理

• 建立供应商安全能力评估矩阵（覆盖SDL实施、漏洞修复时效、漏洞响应体系等维度）

• 推行软件成分透明化（强制要求供应商提供SBOM与组件依赖关系图谱）

2. 第三方组件管控

• 构建组件全生命周期管理平台（集成SCA工具与许可证扫描）

• 实施分级信任策略（如核心模块仅允许使用Apache基金会成熟项目）

• End –

---

---

下期分享

08 漏洞从哪里来？——乌合之众

你没错，我没错，咱俩在一起就是错

推荐阅读

01 漏洞从哪里来？——综述

02 漏洞从哪里来？——设计缺陷

03 漏洞从哪里来？——编程习惯

04 漏洞从哪里来？——认知局限

05 漏洞从哪里来？——体系痼疾

06 漏洞从哪里来？——视而不见

---