文 | 北京中关村实验室 于励飞 彭迎涛 龚振炜 安达
支撑装备制造、电子信息、能源、汽车制造等支柱产业数字化转型的软件栈普遍建立在开源基础之上，例如，工业互联网平台底层基础设施广泛基于Linux内核及其开源生态构建，车载操作系统广泛采用基于Linux的汽车级平台（AGL）和基于自研内核的开源鸿蒙（OpenHarmony）等方案，电力调度系统广泛采用开源中间件，能源行业大模型训练普遍依赖开源框架。黑鸭软件（Black Duck）的《2025年度开源安全与风险分析报告》进一步表明，97%的商用代码库含有开源组件，平均每个应用引入911个开源依赖。开源软件供应链安全风险与治理，成为重要的研究问题。
一、我国支柱产业开源供应链安全面临的风险
开放源代码促进会（OSI）于1998年发布《开源定义》，通过自由再发布、源代码可获取等十项条款界定“开源”。本文所论“开源”，涵盖开源软件、开源组件及其所依托的全球化开发与分发生态：软件与组件是嵌入产业系统的运行实体，生态则是其生产、维护与演化的组织基础。与通用软件开源供应链不同，支柱产业开源供应链具有产业系统嵌入深、产品生命周期长、实时性与可靠性要求苛刻等特征。这使通用互联网行业的风险应对经验无法直接被套用。开源供应链安全风险的核心特征在于其传导性与放大效应：上游一个节点的异动，可沿依赖网络层层下传，在支柱产业的规模化部署中被数倍乃至数十倍放大：治理权的缺失削弱漏洞响应能力，使级联攻击更易得逞；合规与断供风险进一步压缩安全补丁与替代方案的获取空间，加剧级联后果。
（一）开源生态话语权的梯度缺失风险
在决定开源项目演进方向的三个关键梯度（代码贡献、标准制定、治理决策）上，我国产业界的影响力逐级递减。
在代码贡献度层面，在Linux内核、编译器、数据库核心引擎等全球基础设施级项目中，中国开发者的贡献占比明显低于装机量所反映的使用规模，且贡献集中在驱动适配与外围模块，对进程调度、内存管理、存储引擎等核心子系统的影响力有限。在能源领域，电力调度领域广泛使用的开源时序数据库核心开发团队仍以欧美为主，国内能源企业对海量测点高并发写入、国产化适配等特性的需求，难以优先纳入主线版本规划。在汽车制造领域，汽车开放系统架构（AUTOSAR）标准的核心特别兴趣小组席位仍以欧美整车厂为主导，国内企业即便是大规模使用方，也主要处于“标准消费者”位置。
在标准制定层面，国内企业在第五代精简指令集架构（RISC-V）、开放平台通信统一架构（OPC UA）、车载网络协议等开源标准化组织中的议案提出数量与通过率均偏低，导致新兴标准的演进方向难以充分反映国内产业需求。在装备制造领域，工业机器人开源运动控制库（如ROSIndustrial）的标准化进程中，国内龙头企业的提案占比有限，导致符合国内产线工艺特征的标准模块长期滞后。国内企业即便在个别项目中积累了贡献度，若无法参与标准起草与技术规范定义，仍无法将产业需求固化为生态规则。
在治理决策层面，在Apache软件基金会、Linux基金会、Eclipse基金会、云原生计算基金会（CNCF）等顶级基金会中，我国开发者在项目管理委员会（PMC）、技术监督委员会（TOC）等治理岗位的比例仍然有限，对项目孵化、版本演进、弃用决策等关键议程的影响力不足。在电子信息领域，国内头部云厂商虽在部分边缘计算框架项目上保持较高的代码提交量，但其在CNCF技术监督委员会等治理岗位的席位占有率与代码贡献规模仍不匹配，难以主导边缘计算方向与产业需求的对接节奏。2024年，Linux内核6.9版本将EXT2独立文件系统驱动标记为弃用（建议用户迁移至EXT4驱动），下游部分操作系统厂商需相应调整文件系统驱动适配与产品维护策略。这是治理权缺失传导至下游产品的典型表现。
这三个梯度相互叠加、层层传导。贡献度不足削弱标准话语权，话语权不足削弱治理决策权，治理权不足又反过来限制核心贡献机会，最终形成闭环式的结构性约束。其中，治理权的缺失对级联风险的放大效应尤为关键。当上游项目作出弃用或重构决策时，缺乏话语权的下游使用者将被动承受兼容性破坏、维护资源收缩及迁移成本上升等外部冲击，同时，上游的每一次变更均可能转化为下游的供应链震荡。若不加以系统性破解，我国支柱产业将长期处于“用得多、说不上、定不了”的被动局面。
（二）漏洞级联扩散与供应链攻击风险
开源软件的依赖关系已形成深度嵌套的复杂网络：单个应用直接依赖数十个组件，每个组件又向下依赖数十乃至上百个子组件，依赖深度通常可达十层以上。在这种结构下，漏洞不会按“发现—修复—消除”的线性路径消失，而是沿依赖链路逐级传导、逐层放大：上游一个基础库的缺陷，经中间框架、工具链、基础镜像层层传递，可在一级依赖中表现为功能异常，在二级依赖中转化为接口失效，在三级依赖中触发服务中断乃至系统级沦陷。根据《2025年度开源安全与风险分析报告》，86%的代码库含有已知开源漏洞，81%含有高危或严重风险漏洞。2021年的CVE-2021-44228漏洞展示了“深层传递性依赖”的级联威力。Java日志库并非多数应用的直接依赖，而是作为第三方框架的子依赖甚至“孙依赖”被间接引入。一个Java命名与目录接口（JNDI）注入缺陷经四级到六级依赖链路传导至全球数十万应用，波及金融核心系统、电力调度系统与工业互联网平台。在汽车制造领域，根据奇安信代码安全实验室《2025年中国软件供应链安全分析报告》对5家主流车企的车载远程信息处理终端（T-Box）、车载信息娱乐系统（IVI）、高级驾驶辅助系统（ADAS）等关键部件固件的深度检测，其中，某厂商T-Box单固件即存在漏洞3118个，某厂商IVI固件存在漏洞1014个（包括超高危漏洞82个）。所有被测厂商均使用了含有已知漏洞的cURL、OpenSSL等通用开源组件，其中，某单个组件引入114个超高危漏洞，甚至部分固件仍存在20年前的历史漏洞。2022年的CVE- 2022-22965漏洞揭示了“框架级”级联的破坏力。作为Java生态的基础设施，Spring框架参数绑定机制的漏洞使所有基于Spring栈构建的业务系统同时暴露，金融、政务、制造等行业被迫进行大规模版本迁移与架构重构。
支柱产业的运行特征将上述级联风险进一步放大。智能制造、车联网、电力调度等场景要求毫秒级至秒级的实时响应。级联漏洞一旦触发即可能导致生产停摆，而非仅限于信息泄露。更严峻的是，汽车、电力设备等长生命周期产品的依赖冻结周期通常以年计。当上游漏洞修复发布时，下游产品可能因兼容性约束、认证壁垒或升级窗口限制而无法及时部署补丁，形成“上游已修、下游难动”的修复断层。在汽车制造领域，由于车规级软件需同时满足功能安全（ISO26262）与网络安全（ISO/SAE21434）双重标准，漏洞修复后需经过单元测试、集成测试、系统测试、整车测试及道路测试等多重验证，单轮验证周期通常已达数月。这表明，“上游已修、下游难动”的修复断层在级联依赖中被逐层放大：一级依赖的修复延迟为天，二级为周，三级可达月甚至年。因此，亟须建立与产业特性及依赖深度相匹配的级联感知与阻断体系，而非止步于传统的单层漏洞扫描。
（三）许可证合规与地缘政治断供风险
开源许可证的复杂性与国际地缘环境的不确定性，正对支撑支柱产业的开源软件生态形成叠加压力。在许可证合规层面，GNU通用公共许可证（GNU GPL）系列、GNU Affero通用公共许可证（GNU AGPL）、服务器端公共许可证（SSPL）等具有“传染性”条款的许可证与商业闭源产品混用，在汽车嵌入式系统、工业软件出海等场景构成显著合规风险。多数企业的研发流程尚未建立完整的软件物料清单（SBOM）机制，导致许可证冲突在深层传递性依赖中隐蔽化，一旦在海外市场或合规审计中被发现，将可能触发产品召回或诉讼。类似地，某化工集团的工业仿真软件在海外项目中因嵌入了GPL许可证的开源线性代数库，曾触发合规审计中的许可证传染性争议，险些导致项目交付受阻。在地缘政治层面，近年来，若干开源基础设施的访问控制与许可政策表现出一定的地缘敏感性。例如，部分国际开源基金会曾以合规与出口管制为由限制特定国家或地区的访问与会员资格；GitHub对受制裁地区的访问管理也曾引发对代码托管可持续性的讨论。在支柱产业层面，上游托管平台、构建镜像站或依赖分发通道一旦出现访问受限，将直接影响国内企业获取关键开源组件的版本跟进与安全补丁，其中，汽车、能源等长生命周期产品所受影响尤为深远。在电子信息领域，2022年8月，美国商务部对全环绕栅极晶体管（GAAFET）工艺电子设计自动化（EDA）实施对华断供，限制3纳米及以下先进制程芯片设计的EDA软件出口。此前，华为于2019年被列入美国“实体清单”后，新思科技（Synopsys）、楷登电子（Cadence）、明导（Mentor）三巨头即暂停对其授权和更新。华为被迫自研EDA工具，并于2023年宣布完成14纳米以上芯片EDA工具国产化。寒武纪、壁仞科技等国内芯片设计企业切换至国产EDA工具后，单项目迁移成本超2亿元，设计周期延长10%~20%。
在合规与地缘两类风险相互叠加的背景下，支柱产业不能仅以“许可证审查”应对，而需在供应链控制、自主镜像基础设施与关键组件替代方案三个层面同步布局。尤其值得警惕的是断供风险与级联风险的叠加效应。当关键组件的安全补丁因断供而无法及时获取时，已知漏洞将沿依赖链在产业系统的各个层级持续扩散。唯有构筑“供应可控、修复可达”的双重防线，方能实现供应侧的实质性韧性。
二、开源供应链安全治理的目标、理念与实践基础
面对开源生态高度国际化、软件依赖高度耦合的发展趋势，需要从治理理念、能力体系与产业协同机制等层面进行系统性重构。其核心在于提升对开源生态的理解能力、参与能力与塑造能力，在开放协作与安全可控之间建立长期平衡。
（一）治理目标
支柱产业开源供应链安全治理不能停留于事件驱动的被动响应，而需建立面向中长期的结构性韧性。治理目标应分三个层次递进展开。短期目标（1—3年）是实现SBOM在重点支柱产业关键系统的全覆盖，建立面向公共漏洞和暴露（CVE）、许可证冲突与依赖变更的多源情报实时感知能力，确保高危漏洞平均修复时间（MTTR）进入可量化、可考核的区间。中期目标（3—5年）是在支柱产业核心软件栈中形成对关键开源组件的自主维护与替代能力，在主要国际开源基金会与标准组织中实现话语权从“席位缺席”到“规则共治”的跃迁。长期目标（5年以上）是构建开放与安全并重、自主与共治协调的产业开源底座，使我国支柱产业在全球软件供应链中从“深度依赖方”转型为“韧性共建方”，实现开源红利与供应链安全的动态平衡。
（二）治理理念
支柱产业开源供应链安全治理应遵循四个基本原则。一是安全和发展并重。支柱产业数字化转型对开源的深度依赖是客观现实，既不能因噎废食地收缩使用开源软件，也不能放任风险积累。治理应在保障安全底线的前提下，最大化赋能开源创新效应，实现“以安全促发展、以发展强安全”的良性循环。二是自主与开放共治。自主可控不等于封闭自研——在开源软件已成为全球软件基础设施构成主体的格局下，完全脱离国际开源生态的“自主”既不经济也不可持续。正确路径是在深度参与国际开源生态前提下，通过提升贡献度、争取治理席位、建设自主镜像与替代方案，实现“开放中自主、共治中有为”。三是全生命周期管理。开源组件的安全风险贯穿引入、使用、更新、退出全过程，尤其是级联风险往往并非源于直接依赖，而是隐藏在第三层甚至更深的传递性依赖中。治理应将安全关口前移至组件引入阶段，建立覆盖“选型评估—准入审查—持续监测—应急响应—退役替换”的闭环机制，避免将治理窄化为事后漏洞修补。四是产业特性驱动。不同支柱产业的软件栈结构、实时性要求与生命周期特征差异显著——汽车产业依赖链长、产品生命周期以十年计，电力能源秒级响应且不允许计划外停机，电子信息产业迭代快但生态锁定效应强。治理方案不宜统一套用，应在统一框架下为不同产业量身定制重点措施与考核指标。
（三）实践基础
在制度基础方面，我国已初步构建起覆盖“法律义务—审查程序—技术评价”的多层次制度框架。其中，《中华人民共和国网络安全法》确立了网络安全审查机制；《关键信息基础设施安全保护条例》与《网络安全审查办法》明确了关键信息基础设施运营者的采购安全审查要求；《信息安全技术ICT供应链安全风险管理指南》（GB/T 36637-2018）从风险识别、评估与响应三个维度建立通用管理框架；《信息安全技术关键信息基础设施安全保护要求》（GB/T39204-2022）就采购过程的安全审查制度作出系统规定；《网络安全技术软件产品开源代码安全评价方法》（GB/T43848-2024）作为首个聚焦开源代码安全评价的国家标准，围绕来源可信性、安全质量、知识产权合规性与管理规范性四个维度明确了评价指标。
然而，现有制度仍以通用框架为主，面向支柱产业的行业应用细则尚待出台，包括SBOM强制提交、关键组件分级管理等核心制度尚未落地。在生态探索方面，本土开源项目已在关键领域实现阶段性突破。截至2025年年底，OpenHarmony代码贡献者突破1万人，累计合入拉取请求（PR）超过74万次，代码规模达1.3亿行；开源项目openEuler汇聚超2万名贡献者、2000余家社区伙伴，装机量突破1000万套；百度飞桨凝聚超2300万开发者，服务76万家企业。这些项目证明，我国已具备培育规模化开源生态的能力，为支柱产业开源供应链安全治理提供了可依托的本土技术底座。OpenHarmony与openEuler的快速成长表明，通过定向投入与生态运营，我国科技企业有能力在特定领域实现从“使用者”到“共建者”的跨越。关键在于将这种模式从终端操作系统向数据库、中间件、工业协议栈等更多基础软件领域扩展，同时，在国际化治理层面实现系统性突破。
三、构建我国支柱产业开源供应链安全治理体系
在开源组件规模化复用、供应链风险持续外溢的背景下，支柱产业开源供应链治理重点已从单点防御转向体系化能力建设，从事后响应转向全过程风险控制。只有同步强化制度供给、技术基础设施与开源生态参与能力，才能逐步建立具备自主韧性的产业级开源供应链安全体系。
（一）完善法规标准与自主可控制度
制度供给是开源供应链安全治理的基础保障，需通过专门立法、标准细化与产品级安全义务，构建覆盖支柱产业的法规标准与自主可控的制度体系。一是建议制定专门的“软件供应链安全管理办法”，对金融、能源、电信、汽车、装备制造等重点支柱产业提出SBOM强制提交、开源组件备案、重大漏洞报告等具体要求。二是以GB/T43848-2024为基础，加快形成面向支柱产业的应用细则，明确高危组件判定、版本停服管理、许可证合规审查的技术指标。三是参照欧盟《网络弹性法案》确立的产品级安全义务，要求在支柱产业软件供给侧提供开源组件使用声明与安全证明。在具体落地层面，可在装备制造、能源等行业先行建立“开源组件使用备案+关键组件分级管理”制度，对Redis、Nginx、OpenSSL等高使用率关键组件实施重点监测，将高风险组件与替代方案纳入行业主管部门监管范围。
（二）建设可信开源技术能力链
技术能力链是将制度要求转化为可执行防护的关键支撑，应围绕软件物料清单生成、漏洞情报分析与风险处置三个环节，打造贯穿研发全流程的可信开源技术能力。在生成层面，统一推广软件包数据交换标准（SPDX）、CycloneDX等SBOM标准，结合美国网络安全与基础设施安全局（CISA）的《软件物料清单最基础要素》指引，在支柱产业研发流水线中强制集成SBOM自动生成工具，实现每次构建均出具直接依赖与传递性依赖清单，解决级联风险“不可见”的问题。在分析层面，建设面向国内支柱产业的漏洞情报联动平台，整合国家信息安全漏洞共享平台（CNVD）、国家信息安全漏洞库（CNNVD）、GitHub安全公告、OSS索引等多源数据，利用知识图谱与机器学习技术实现CVE与国内企业依赖使用情况的实时映射，提前识别高传染性漏洞经多层依赖的潜在影响面，解决级联风险“难评估”的问题。在处置层面，推广可复现构建、组件签名验证、依赖关系冻结等机制，确保依赖项在传输与构建过程中不被篡改，解决级联风险“难阻断”的问题。在具体落地层面，可在汽车产业重点试点车载软件SBOM与空中下载（OTA）联动，使漏洞定位到车型、电子控制单元（ECU）与版本粒度；可在电力能源产业重点试点“调度系统依赖冻结+漏洞黑名单实时阻断”，形成具备产业特征的示范经验。
（三）推动支柱产业开源社区共建与提高贡献能力
生态参与能力决定我国在全球开源治理格局中的话语权，需通过开源专项、闭环激励与国际化治理，推动支柱产业从开源使用者向规则共建者转变。一是针对支柱产业关键技术方向设立开源专项：在智能网联汽车方向，支持AGL、OpenHarmony车机子项目；在工业互联网方向，支持工业协议栈与时序数据库开源项目；在能源方向，支持新型电力系统调度与预测开源平台。二是建立“产业需求—开源贡献—企业收益”闭环激励机制，将企业对关键开源项目的代码贡献、项目管理委员会与技术监督委员会席位占有量纳入重点行业科技评价与政府采购加分体系。三是以开放原子开源基金会为牵引，支持OpenHarmony、openEuler、openGauss等项目走向国际化，推动我国支柱产业的相关诉求从“席位缺席”向“规则共治”演进。
（本文刊登于《中国信息安全》杂志2026年第6期）
声明：本文来自中国信息安全，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
