中国开源发展在哪些方面面临挑战？

开源 软件生态系统庞大，涉及技术、法律、供应链、人才等多个环节，其中任何一环出现问题，开源软件 发展都将面临着挑战。

1.开源面临技术安全风险

（1）开源软件漏洞数量保持高位

根据Synopsys公司发布的《2023开源安全和风险分析（OSSRA）报告》，Black Duck审计服务团队 在2022年审计的涵盖17个行业的1703个代码库中，有96%的代码库包含开源代码，76%为开源代码 库；84%的代码库包含至少一个已知开源漏洞，比2022年版的OSSRA报告增加了近4%；检查的代码库中有48%包含高风险漏洞，仅比去年减少了2%。

中国信息通信研究院发布的《全球开源生态研究报告（2022）》指出，根据Snyk和Linux基金会2022 年发布的开源安全调查报告，一个应用程序开发项目平均有49个漏洞和80个直接依赖项。此外，修 复开源项目漏洞所需的时间也在稳步增加。2018年修复安全漏洞平均需要4天，而2021年修复一个补 丁大约需要110天。

奇安信代码安全实验室《2022中国软件供应链安全分析报告》则显示，截至2021年底，CVE/NVD、 CNNVD、CNVD等公开漏洞库中共收录开源软件相关漏洞52716个，其中6346个为2021年度新增漏 洞。而在奇安信代码安全实验室审计的3354个国内企业软件项目中，存在已知开源软件漏洞的项目 有2897个，占比高达86.4%；存在已知高危开源软件漏洞的项目有2680个，占比为79.9%；存在已知 超危开源软件漏洞的项目有2400个，占比为71.6%。这些项目中，共检出231368个已知开源软件漏洞 （涉及到7269个CVE漏洞编号），平均每个软件项目存在69个已知开源软件漏洞，略高于去年报告 中的66个，最多的软件项目存在1555个已知开源软件漏洞。而从漏洞的影响角度来看，最多的Spring Framework远程代码执行漏洞CVE-2022-22965影响了37.1%的软件项目，多个漏洞影响了超过30% 的项目。

在2021年检测的2406个国内企业自主研发的软件项目中，输入验证、路径遍历、跨站脚本、注入、 NULL引用、资源管理、密码管理、API误用、配置管理、日志伪造等十类安全缺陷是程序员在编写软 件代码时经常会出现的典型安全缺陷，十类典型安全缺陷的总体检出率为59.9%，低于去年报告的 78.8%，。

（2）开源软件漏洞影响范围巨大

根据Synopsys公司《2023开源安全和风险分析报告》，2022年仍存在大量早已在2021年就披露的漏 洞，例如该年影响最大的Apache Log4j2漏洞。2021年12月，Apache Log4j2被发现其某些功能存在 递归解析功能，存在攻击者可直接构造恶意请求，触发远程代码执行的漏洞。根据工信部发布的《关 于阿帕奇Log4j2组件重大安全漏洞的网络安全风险提示》，该漏洞可能导致设备远程受控，进而引发 敏感信息窃取、设备服务中断等严重危害，属于高危漏洞。

据Check Point Research统计漏洞爆发4天（自12月10日至12月13日）情况报告，在Apache Log4j2漏 洞发现早期的12月10日，黑客尝试利用该漏洞进行攻击的次数仅有几千次，但这一数据在隔天却增 至4万次。而漏洞爆发72小时后，捕捉到利用该漏洞尝试攻击的行为就已超过83万次。

不仅攻击次数在持续攀升，基于该漏洞的新变种也在短时间内迅速衍生。Log4j2作为一个基于Java 的日志框架影响范围之广远超开发团队的预想，全球近一半企业因为该漏洞受到了黑客的试图攻 击。并且由于Apache Log4j2应用范围大、漏洞修复较为复杂，而利用漏洞却十分简便，因此Apache Log4j2漏洞很可能在未来几年内也将一直存在。

（3）上游开源组件的漏洞传播与修复挑战

当一个常用开源组件因存在漏洞被修复时，我们希望把新版本快速同步到其他所有调用了该组件的开源项目中去，而不是同一个漏洞被一次次在不同软件中反复发现，反复修复，浪费人力物力，甚至 被攻击者反复利用。上游组件的修复能否快速、大规模、全覆盖地推送到下游依赖环节，是开源软件 供应链安全可靠性面临的重要挑战。

仍以2021年底爆发的Log4j2为例，Apache Log4j2零日漏洞（Log4Shell、CVE-2021-44228）是因 “Lookup”机制存在解析问题，导致了JNDI注入漏洞。该漏洞的触发条件简单，但危害却极大。攻击 者可向程序输入特定的攻击字符串，当程序进行日志记录时，该漏洞即可被触发，用来执行恶意代 码。Log4j2是Java代码项目中广泛使用的开源日志组件，因此这个漏洞很快演变为一场Java生态中 开源软件供应链的安全危机。据不完全统计，GitHub超过8600多个开源软件直接依赖Log4j2组件， 但通过这些开源软件继续追溯，最终超过20万个开源软件受到了影响；同时，在官方第一次发布修 复版本的一周时间后，仍然有超过80%的间接关联开源软件没有被修复。

从数据上可以看出，上游开源组件中一旦发现有严重漏洞，就会直接或间接地影响到依赖它的下游 开源软件，同时通过开源软件之间错综复杂的层级依赖关系的传播后，该漏洞隐匿在深层依赖的应 用中不易被发现，为全球软件供应链带来无法估量且不可控的影响。

（4）对开源软件组成成分分析时，受制条件较多

目前，如果被检测的软件无法提供源代码，那么二进制文件是唯一可以进行分析检测的对象，但大多 数二进制文件都经过了混淆、加壳等处理，给组件成分分析带来了巨大的困难和挑战。同时，从二进 制文件推导除组件以及版本的精确度问题也需要解决。此外，在进行开源软件克隆检测时，需要有 一个巨大的开源软件源代码数据库作为支撑，而如何高效地在海量代码片段中检索到被检测软件的 克隆特征，进而进行同源分析，并减少人工确认的工作量、减少误报是工业界面临的一个问题。

2.开源面临法律风险

（1）开源许可证法律效力有待进一步明确

根据Synopsys公司《2023开源安全和风险分析报告》显示，尽管存在许可证冲突的代码呈逐年减 少的趋势，但在2022年的被审代码库中仍有高达54%的代码存在冲突。其中，Creative Commons ShareAlike 3.0 (CC BY-SA 3.0)许可证冲突以约20%的占比，称为该年度许可冲突的最主要的原因。 CC BY-SA 3.0许可证冲突数据揭示出，许多商业和开发人员常将来自Stack Overflow等论坛的代码 片段、函数、方法和操作代码片段，不假思索地引入到软件中，从而引发冲突。此外，标准开源许可 证的变体或定制版本许可证可能会对被许可方提出不必要的要求，并且要求对可能的知识产权问题 和其他问题进行法律评估。例如，JSON许可证实质上是宽松型MIT许可证，只不过添加了“该款软 件严禁用于恶意用途，仅限用于善意用途”的注释。许多热门项目的责任方都因为许可证定义含糊不 清而删除了使用JSON许可证的代码，因为“善意用途”与“恶意用途”定义争议性极强，很难界定。

国内司法实践中逐步开始重视开源许可证的法律效应。2021年4月，广东省深圳市中级人民法院审理罗 盒公司诉风灵公司案的一审判决，该案明确指出GPLv3协议是一种民事法律行为，具有合同性质，可以 认定为授权人和用户间订立的著作权协议，属于《合同法》调整的范围。此案例是国内首个明确GPLv3 协议法律效力的案例，对开源许可证的法律界定，对开源软件侵权行为的判罚作出了有益的探索。

（2）著作权风险

开源代码有时会渗透到其他代码中，或者其他代码渗透到开源代码中。根据不同的开源许可，则有可 能不得不向整个社区公开原本不想公开的代码。例如，某些代码根据GPL等许可证合并到某些软件 的源代码中，可能会“感染”该软件，从而导致该软件根据许可证的条款自动获得许可，也因此必须 遵守该许可。例如，微软便遇到过该渗透问题，在微软将具有GPL许可的部分代码合并到其Hyper-V 驱动程序中后，才发现部分代码被感染，而微软不得不向Linux贡献了该Hyper-V驱动程序的代码以 避免违反GPL。

（3）专利权风险

专利相对于著作权来说更加复杂，在获取专利权和维持专利权上要投入更多。专利在申请阶段就需 要提交和申请很多文件，而一旦出现潜在的侵权问题，专利的诉讼成本也高于一般的著作权诉讼的 成本。因此发起专利侵权诉讼本身就是专利权人需要极为慎重考虑的事情。

另外，完全存在适用于许可软件但许可人和被许可人都不知道的专利。由于专利数量较多，开发者 不可能了解世界上所有的软件。由于许可人只能许可属于他们的作品，因此特定软件许可的存在并 不能保护被许可人免受第三方专利权人提出的侵权索赔。对专利风险的分析往往需要聘请律师来进 行，成本也较高。

（4）商业秘密问题

在开源领域，商业秘密的判断比较困难，因为开源软件本身就开放了很多信息，哪部分能够构成商业 秘密是未来需要探讨的方向。

（5）认定受开源许可证影响的软件边界

高传染性。在过往的案件中，曾出现北京高级人民法院认为软件中的插件并不受到GPL约束，而广州 知产法院认同了GPL协议的“高传染性”，即在GPL3.0协议下开源软件的衍生作品或修改作品也需 要遵循GPL许可协议开放其源代码。

独立程序。在2019年，最高院审理的一件计算机软件作品著作权纠纷案中认为前端和后端代码是独 立的不同代码，前端代码用于页面设计等，而后端代码用于实现软件本身的底层逻辑，因此认为前 端代码与后端代码在实际达到的效果和最终结果存在明显不同，且法院认为不能仅仅因为代码的交 互配合就认定二者为同一代码。最高院认为GPL的高传染性包括基于开源软件的衍生程序或修订版本，但不包括存在交互或联系的其他独立程序。正如计算机系统中的多数软件或代码需要互相配合 以达到目的，但这些软件或代码并非同一软件或代码。2022年3月，陕西省西安市中级人民法院判决 的另一起计算机软件作品著作权纠纷案中提及，根据GPL协议规定，只要修改文本在整体上或某个 部分来源于遵循GPL的程序，该修改文本的整体就必须按照GPL流通，不仅该修改文本的源码必须 向社会公开，且对于修改文本的流通不准许附加修改者自己作出的限制。

开源的界限。开源软件经常涉及技术的跨国界传播，因此也需要面对各国国家的技术管制相关法律。 开源社区是在不同国家的法律下建立起来的，其必须遵守所在地的法律法规，因此，开源平台和开源 企业实际上难以保持中立。开源软件的开发与维护往往涉及到不同的主体，也就涉及到不同的权利 归属、许可、授权等法律问题。

3.开源面临供应链风险

软件供应链已经成为网络空间攻防对抗的焦点，直接影响关键基础设施和重要信息系统安全。软件 的供应链安全问题由来已久，只是随着开源软件规模化应用，软件供应链愈发复杂多元，在开源协作 模式下，软件之间的供应链关系已经非常普遍和繁杂，构建和维护开源软件供应链已成为全球开源 领域的共同挑战。

总体来说，当前中国开源软件供应链主要面临三方面的挑战。

（1）关键开源组件的可持续维护挑战

开源软件的长期义务维护可能会导致一系列不公平的现象，例如商业公司通过开源软件赚取了丰厚 利润，但并没有给维护者任何回馈，甚至会刻意回避谈及对开源软件的使用，由此引起开源维护者的 反感甚至一些过激行为。2022年3月发生的faker.js与colors.js开源库遭作者Marak恶意破坏的事件就 是典型的例子。faker.js与colors.js使用范围较广，faker.js在npm上的每周下载量接近250万、colors.js 达到约2240万，属于较为关键的开源软件供应链上游节点。faker.js使用的是十分宽松的MIT开源许 可协议，因此许多商业公司并没有为使用此项目支付任何费用。作为fake数据领域最优秀的开源项 目之一，faker.js和colors.js庞大的工作量却主要由其作者Marak一人完成，并且没有从商业公司得到 相应的支持和回报。长期累积的恶性循环终于爆发，作者通过向两个包提交恶意代码进行供应链投 毒，并发布到GitHub和npm包管理器中，之后又将项目仓库所有代码清空，完全停止维护，从而使依 赖于这两个库的数千个项目无法运行。可想而知，这些软件包在出现漏洞后，修复的及时程度和全面 程度必然会受到影响。

（2）国际局势动荡的挑战

最近几年，开源软件供应链出现了意识形态、地缘政治、战争冲突等导致的开源社区分裂。一些关键 的开源托管平台和开源基础软件对特定国家、特定实体雇员采取了账号禁止访问、代码删除等“断 供”行为，这也是未来开源软件发展面临的又一巨大挑战。 开源无国界，但开源组织（如基金会）、开源代码托管平台（属于商业公司所有）乃至开发者（开发 者有国籍）都会受到属地出口管制政策的制约。例如，全球最大的代码托管平台GitHub、全球最大的 容器托管平台Docker Hub、国际著名开源基金会Apache基金会就明确声明受美国《出口管理条例》 的约束。早在2019年，GitHub就曾禁止伊朗程序员访问托管其上的仓库。Docker Hub也曾声明对列 入美国制裁实体清单上的企业停止容器镜像托管和下载服务。

随着俄乌局势升级，出于美国制裁的原因，GitHub开始封禁俄罗斯开发者的账号，严格限制俄罗斯 获得维持军事能力所需的技术。一些著名的开源社区和开源项目也出现了宣扬政治立场的行为。 轻则在开源项目中植入支持某方的标语口号、捐款按钮等，重则把对方排除出开源社区。例如， OpenBLAS作为一个基于BSD许可发行的优化BLAS计算库，删除了对俄国产处理器Elbrus的支持， 这意味着Elbrus可能将无法使用新版功能的优化线性代数内核，未来Elbrus处理器也无法在被依赖 OpenBLAS库的应用直接使用。更为严重的是，有人在广泛使用的开源基础库中植入恶意代码，当判 断使用者IP地址属于某个特定国家时，会对整个系统根目录发起强制删除操作，后果不堪设想。这些 行为虽然已经背离了开源精神，违反了开源社区的基本共识，但在高强度的对抗情况下几乎必然会 发生，不得不引起高度重视。

（3）大企业垄断开源生态阻碍创新

在过去十余年中，从Linux、MySQL到Kubernetes、Spark、Presto和MongoDB，开源一直是云创新的 支柱，但部分大型云服务商正在改变开源的形态，可能会破坏开源创新的激励因素。大型云服务商 很容易获取到优质的开源项目，并将其作为托管服务提供给客户。这些大企业并没有动力去回馈开 源社区，很自然地从这些别人的工作中获得不公平的利润，从而破坏了开源创新所需要的发展动力。 如果这种现象持续存在，将会极大地对开源从业者创办企业和获得投资方面产生抑制作用。

另外一些国际巨头不断通过垄断开源生态，在产业链中掌握极大话语权，并以此获益。例如Google 旗下的操作系统Android、浏览器Chrome、深度学习框架TensorFlow、容器编排引擎Kubernetes等， 分别在各自的领域占据优势地位，这些开源产品自身具有一定通用性和适用性，便于后续开发者“不 重复制造轮子”而在其产品的基础上进行进一步开发，但又通过人为制造诸如广告服务、有意破坏其他竞品连接Google服务的用户体验等方式排除竞争者获得垄断地位，最后从高达30% Google应用 商店抽成，内置Android系统的Google ADs，以及GMS服务授权费用等途径获得高额的垄断利润。尽 管这些产品本身都是开源的，但中小企业和个体开发者在面对Google限定的服务接口、苛刻的商业 条款等问题时，很少有能力再进行创新并反馈开源社区，开放共享的初心被完全破坏殆尽。2020年 底，红帽公司宣布2021年底停止维护CentOS 8，2024年6月30日停止维护CentOS 7，这意味着在全 球使用广泛的开源CentOS服务器操作系统将停服，后续将无法获得官方升级和补丁，为广大基于开 源CentOS服务器操作系统的业务应用带来网络安全风险。

为了积极应对和防范开源软件供应链风险，建立软件物料清单SBOM(Software Bill of Materials)是 一个极为必要的工作。SBOM旨在跨组织共享，有助于提供软件供应链成分清单与透明度。根据 NTIA(美国国家电信和信息化管理局)的定义，SBOM(Software Bill of Materials，软件物料清单)是一 种正式标准化的、机器可读的元数据，它唯一地标识软件组件和依赖，以及它们之间的层级关系；也 可能包括版权和许可证等成分数据。

4.开源面临人才风险

（1）人才供需对接的效率低

据GitHub《2021年度Octoverse报告》统计，中国开发者人数占比排名第二，有755万以上。按照中国 数字经济转型发展的要求，2022年中国有1200万的人才需求缺口。

（2）高技能人才匮乏，结构性供给不足尤为突出，顶尖开源人才更难寻

自然语言处理、视觉识别、语音识别等人工智能领域的人才缺乏尤其严重。但企业找到恰当的、需要 的人才成本依然很高，普通大学毕业生去企业之后要1-2年才能适应开源等工作的岗位要求，总体来 看，人才培养周期长，加剧了企业的开源人才挑战。

（3）企业对开源人才的培养成本投入少，开源人才留存困难

由于工作时间长、压力大、企业凝聚力弱等问题，给开源人才的留存造成了一定困难。加之多数企 业存在人力成本居高不下，对开源人才的支持与培养投入少，导致在开源人才管理方面也面临一些 挑战。

（4）国内就业文化和试错容错机制差，开源人才压力大，不能长期持续走冷板凳研发源码和产品

相比ChatGPT几年磨一剑的过程来看，国内就业大环境压力和同行竞争等原因，使人员团队很难静 下来研发和打磨，大部分以短平快的研发为主。而由于年龄歧视的原因，一些有经验的专家级开发人 员又很难有用武之地，被迫中断原来积累的经验和技术。