可靠的软件供应链需要上游供应链软件社区的持续投入和长期支持(Long Time Support，LTS)。软件也存在生命周期，上游供应链软件开发团队能否对软件全周期进行持续高质量的维护与投人，也是软件供应链中的风险点。在安全漏洞披露之后，供应链软件对安全漏洞更新与修复速度影响到下游软件的安全与可靠性，而其依赖于背后是否有一支强大的开发与维护团队。此外，也要注意上游供应链软件的开发者生态。由于开源软件的非营利性，开源社区往往依赖于开发者的无偿贡献与使用者的自愿资助，因此其软件周期存在很大的不确定性，很可能在资金缺乏后停止软件的维护。而软件的停止维护也意味着安全漏洞暴露之后，下游软件无法通过更新的方式规避安全漏洞的风险，使得软件项目暴露在安全风险之下例如，红帽公司决定在2021年12月底停止对Cent0SLinux8的支持，意味着国内大量使用Cent0s的企业都需要进行上游操作系统的迁移与替换而没有及时替换的软件在遇到安全漏洞之后可能面临无法得到红帽公司技术支持的帮助。
近年来，中国开源正处于加速发展阶段，各技术领域正在与开源深度融合，传统行业也正在被开源快速渗透。在系统分析中国开源生态和商业模式之后，本章对中国开源面临的知识产权、安全漏洞、供应链等风险进行深入的研究，并根据现有的问题提出加强知识产权保护、建立安全漏洞处理机制等对策和建议，以期优化中国开源产业创新环境，促进开源产业的可持续发展。
开源创新的风险及表现
开源在中国的各行各业及各领域得到广泛应用，开源生态整体呈现出蓬勃发展的态势。不过，开源高速发展的过程中也面临诸多风险，如在使用开源软件进行软件开发中可能遭遇的来自著作权、专利权等法律风险问题，以及国产开源软件的知识产权归属和供应链风险等。在拥抱开源的过程中化解开源风险并加快开源发展迫在眉睫，希望可以借此帮助开源企业、开发者认清拥抱开源过程中的各类风险，实现低成本高效率的创新。
1、法律风险
开源相关的法律风险主要在于使用开源代码进行软件开发时，由于未遵守许可合同而可能负有继续履行合同的义务或者承担版权侵权的责任包括著作权和专利权风险，以及相关的软件边界问题。
开源著作权是指开源软件的著作权人通过开源协议将开源软件的复制权、修改权、发行权等部分权利许可给了使用人，但这种许可是附条件的，被许可人只有在遵从开源许可协议规定的前提下，才可以行使这些权利。开源软件和开源软件的修改版本跟专有软件一样，都享有著作权而开源协议的本质是软件著作权人将其复制权、发行权、修改权等附加条件许可给不特定公众的著作权许可使用合同。开源协议具有明显的双务性，被许可人在行使复制、发布、修改开源软件的权利时，也需要按照开源协议要求承担相应义务，否则可能导致其权利被终止。
对开源协议的误解会导致著作权风险。在分析中国相关案件中被诉著作权侵权人的抗辩时会发现，被诉侵权人往往仅强调GPL等开源协议中权利人的开源义务(许可他人修改、复制等)而忽视被许可人的义务(保留声明、注明修改信息等)，这其实是对开源软件和开源协议的一种误解以 GPL协议为例:第4条规定被许可人在发布完整副本时须每份复制件上均附有明显且恰当的版权声明，完整保留GPL协议及附加条款，完整保留不含担保声明，将GPL协议与程序一同移交接受者;第5条规定被许可人发布的修改版本须带有醒目的修改声明及相应的日期;第8条规定被许可人未获得 GPL协议明确授权时，不得传播和修改受保护的作品。任何试图以其他方式进行复制、发布、修改受保护作品的行为都是无效，且将自动终止被许可人通过 GPL协议获得的权利。被许可方复制、发布、修改相关开源软件的唯一权利来源是开源协议的许可，一旦被许可方违反GPL协议，其权利即告终止，但其复制、发布、修改软件的行为通常会处于持续状态，在此期间，被许可方复制、发布、修改软件而无合法权利来源可能构成侵犯他人著作权。因此，违反GPL等开源协议可能存在违约责任和侵权责任竞合的问题，二者在法律依据、侵害对象、产生前提、举证责任范围、责任内容等方面不同。从德国、美国司法实践看，多数法院将被许可方未履行开源协议约定的义务的行为认定为著作权侵权。因此，以权利软件使用了开源协议或包含开源代码而无权禁止复制、发布、修改为由提出的不侵权抗辩，除需证明权利软件受将其复制权、发行权、修改权许可他人使用的开源协议的约束外，被诉侵权人还需证明其行为符合相应开源协议的要求而非随意使用，否则仍有可能因其行为不符合开源协议约定导致许可终止而构成侵权。
在使用开源软件过程中违反开源许可证和使用了有著作权瑕疵的开源软件会引起著作权风险。第一，有著作权瑕疵的开源软件指的是含有侵权代码的开源软件，而开源软件的开发者通常不负有瑕疵担保责任，若在商业软件中因使用含侵权代码的开源软件而造成侵权的则需企业承担由此造成的侵权责任。第二，违反开源许可证会引发著作权侵权问题。违反开源许可证的问题通常是因未遵循开源许可证约束违规使用开源软件，或者未兼容好各开源许可证而引发的。前者相当于违反合同义务而丧失免费的开源软件使用权限，后者的情况则相对复杂。一般而言，在将不同许可证的两个开源程序合并成一个较大的程序，或者把其中之一的代码合并人另一个时，如果各个许可证的限制或条件没有冲突，则开源许可证是兼容的。但因各类开源许可证的义务与要求存有差异，因此在使用或引入开源软件时，若未合理注意各开源软件所适用的开源许可证兼容性问题，也将因违反开源许可证而引发著作权侵权问题。
开源代码泄露会引起著作权风险。开源代码有时会渗透到其他代码中，或者其他代码渗透到开源代码中。根据不同的开源许可，则有可能不得不向整个社区公开原本不想公开的代码。例如，某些代码根据GPL等许可证合并到某些软件的源代码中，可能会“感染”该软件，从而导致该软件根据许可证的条款自动获得许可，也因此必须遵守该许可。例如，微软便遇到过该渗透问题，在微软将具有GPL许可的部分代码合并到其 Hyper-V驱动程序中后，才发现部分代码被感染，而微软不得不向Linux 贡献了该 Hyper-V驱动程序的代码以避免违反 GPL协议。
相对于保护作品表达的著作权保护，专利主要保护的是开源软件的方法和功能。专利权和著作权对于软件的保护是有所区分的。具体来说，著作权保护的是实现特定软件功能的源代码本身，也可以理解为“代码的撰写形式”，包括架构、算法，以及实现算法的具体语言和具体代码组织形式;而专利权则不同，它保护的是代码之上的技术方案，是抛弃具体代码形式基于算法逻辑的流程。专利相对于著作权来说更加复杂，在获取专利权和维持专利权方面要投入更多。专利在申请阶段就需要提交和申请很多文件，而一旦出现潜在的侵权问题，专利的诉讼成本也高于一般的著作权诉讼成本。因此，发起专利侵权诉讼本身就是专利权人需要极为慎重考虑的事情。
开源软件的开发人员复杂松散，数量可能几十人、几百人，某些大型开源软件如 Linux甚至上千人，某一参与开发的人员修改或编写的代码可能完全覆盖非受许可证限制的第三人的软件专利，构成整个开源软件的专利侵权。软件专利保护是对于计算机程序设计思想和算法的独占性保护而同一种软件算法可能有多种实现方式，这就使得开源软件作者几乎没有可能知道在开发程序时采用的算法和设计是不是已经被其他软件申请了专利。因此，软件专利保护增加了后续开发者侵犯他人在先权利的风险。被加入侵权代码的开源软件会通过许可证的方式向下授权，不管被授权的开源软件被用于进行商业开发，还是继续开源，这种专利侵权风险都将一直存在于后续软件中。含有侵权代码的开源软件随时有可能卷入专利纠纷的旋涡。专利侵权的巨大风险时刻威胁着开源软件项目和开源社区的发展当开源软件代码贡献者怀揣着技术开放、创意共享的美好愿望为开源软件贡献一份力量的时候，很可能因为其贡献侵犯软件专利而成为一枚潜在的炸弹。
IBM公司被SCO公司起诉专利侵权就是因BM贡献给开源作系统Linux的代码涉嫌专利侵权。2003年3月8日，著名的Unix系统开发商SCO公司控告软件制造商IBM公司，声称IBM公司将Unix组件用在了免费开源 Linux 操作系统中，而该 Unix 组件的专利权是归 SCO 公司所有。随后，SCO 公司致信全球Linux用户，声称inux操作系统侵犯了其Unix专利权，Linux用户应向 SC0 支付软件使用许可费，否则inux用户可能会因为使用了没有取得专利授权的操作系统而面临侵权诉讼。许多使用开源Linux软件的公司迫于SCO诉讼威胁，开始购买其专利授权以便继续合法使用 Linux 软件。如果 SCO 公司指控 IBM 公司的侵权的事实成立，IBM 对开源社区贡献的源代码就将失去了法律基础，Linux操作系统的合法性将受到质疑。虽然在开源软件业的强烈抵制和漫长诉讼的拖累下，SCO公司出现财务危机，开源Linux软件凭借其特有的开源优势和全世界开源软件用户的支持，取得了更大的市场占有率，但是这一诉讼给以Linux为代表的开源运动敲响了专利威胁的警钟。
在使用开源软件时若未得到开源软件中软件专利的授权许可，也可能存在专利侵权的风险。部分开源许可证(如Apachev2)中虽明示了专利许可要求，但也说明了专利报复条款，其专利侵权风险相对较小。而若开源许可证未说明专利许可规定的，其软件代码虽开源公开了，但开源代码贡献者仍可提起专利侵权诉讼并要求专利许可费用。开源软件虽由贡献者贡献，但不能保证其贡献的代码不侵犯开源许可协议约束的第三方专利权，若使用者未得到第三方的专利许可，其也可能遭遇专利诉讼。
另外，完全存在适用于许可软件但许可人和被许可人都不知道的专利。由于专利数量较多，开发者不可能了解世界上所有的软件。许可人只能许可属于他们的作品，特定软件许可的存在并不能保护被许可人免受第三方专利权人提出的侵权索赔。因此，专利风险往往需要专业律师进行评价和分析，企业需要为之付出额外成本。
涉及软件边界的法律问题一直是较为困难的问题，主要原因有以下四点。第一，高传染性。在过往的案件中，曾出现北京高级人民法院认为软件中的插件并不受GPL约束，而广州知产法院认同了GPL协议的“高传染性”，即在GPL3.0协议下开源软件的衍生作品或修改作品也需要遵循GPL许可协议开放其源代码。第二，独立程序。在2019年，最高院审理的一件计算机软件作品著作权纠纷案中认为前端和后端代码是独立的不同代码，前端代码用于页面设计等，而后端代码用于实现软件本身的底层逻辑，因此认为前端代码与后端代码在实际达到的效果和最终结果存在明显不同，且法院认为不能仅因为代码的交互配合就认定二者为同一代码。最高院认为GPL的高传染性包括基于开源软件的衍生程序或修订版本，但不包括存在交互或联系的其他独立程序。正如计算机系统中的多数软件或代码需要互相配合以达到目的，但这些软件或代码并非同一软件或代码。第三，开源的国别界限。开源软件经常涉及技术的跨国界传播，需要面对各国国家的技术管制相关法律。开源社区是在不同国家的法律下建立起来的，其必须遵守所在地的法律法规，因此，开源平台和开源企业实际上难以保持中立。开源软件的开发与维护往往涉及不同的主体，也就涉及不同的权利归属、许可、授权等法律问题Ф。第四，商业秘密问题。商业软件使用开源软件的商业秘密泄露风险主要是指由开源许可证的传染性风险造成的商业秘密泄露。若在私有软件或代码中，加人使用GPL类开源许可证的开源软件或代码，私有软件或代码将受到GPL类开源许可证“传染”而可能需要被迫开源，由此可能被迫公开商业秘密。与此同时，若引人的开源软件存在恶意代码、病毒或其他安全漏洞等问题，则也可能造成内部系统商业秘密的泄露。当然，在开源领域，商业秘密的判断比较困难，因为开源软件本身就开放了很多信息，哪部分能够构成商业秘密是未来需要探讨的方向。
2、知识产权风险
除法律法规的保护外，开源软件的作者或权利人主要是通过开源许可证对其知识产权进行许可与约束。若开源软件使用者未依照相应的开源许可证来使用开源软件，将可能侵犯开源软件的作者或权利人的知识产权。开源许可证涉及的知识产权风险较为复杂。
第一，开源许可证导致知识产权风险。开源使用方在引入开源软件时，由于开源许可证的规定或变动，可能面临知识产权风险。一是可能因许可证的传染性规定被迫开源。例如，根据CPL许可证的规定，使用依GPL开源的软件并涉及修改和分发，需要将后续修改代码全部开源。二是商业软件是否遵守开源约定未知。例如，部分商业软件基于开源进行二次开发后以闭源形式提供给用户，却不遵守开源许可证的署名要求。三是知识产权风险易被忽略。例如，BSD、MIT和GPL2.0等并未包含明确的专利许可条款，许可用户使用软件所包含的相关专利。四是开源许可证之间可能不兼容。例如，GPL开源许可证在GNU的网站上详细列出何种开源许可证是否与其兼容。五是开源软件的使用规则存在不确定性。例如，2018年以来多个开源软件开发商(Redis、MongoDB、Kafka等)已经对其过去使用的开源许可证进行了修改，0racle宣布2019年1月以后发布的0racleJava SE8 公开更新将不向没有商用许可证的业务、商用或生产用途提供。
第二，商标侵权导致开源知识产权风险。从产权角度看，开源软件所遵循的开源许可协议不同，开源软件的知识产权风险点不同。开源许可协议的本质是许可合同，对开源软件的复制、修改、再发布等行为必须遵循开源许可协议的规定，不同的开源许可协议赋予用户不同的权利和义务，在著作权、专利、商标等方面的规定不同，因此带来的风险也就不同。
使用开源软件的商标侵权风险来源于两个方面:一方面，开源软件使用的开源许可协议未经0SI认证，但使用了opensource商标。只有通过开源促进会认证的开源许可协议，才可以使用0SI关于opensource的商标未授权使用，就会带来商标侵权风险。另一方面，开源软件使用者未经授权擅自使用贡献者的商标、商号、服务标记等进行软件宣传，导致商标侵权。绝大部分开源许可协议都不包括商标授权，有些许可协议明确规定不得任意使用商标。因此，未经额外许可使用商标，会有很大隐患。
第三，开源社区规定不统一导致知识产权风险。所有开源软件均面临版权瑕疵风险，风险大小与开源社区的管理和代码审核的规定相关。例如，在Apache社区中，在一个开发人员成为提交者(committer)之前他必须首先签署一份个人贡献者许可协议(ICLA)并备案，声明将所有贡献授权于 Apache软件基金会，并保证这些贡献都是他们自己原创的工作没有侵犯第三方的知识产权，有权作出如上授权。如果一个开发者自己并不拥有对自己工作内容的这种权利(如一个商业公司对雇员工作拥有权利)，那么还需要商业公司的代表署一个企业贡献许可协议(CCLA)。因此，Apache基金会所属的项目对用户来说由于版权瑕疵带来的侵权风险较小。
3、许可证合规风险
随着各行各业越来越多地使用开源代码，围绕开源合规的讨论成为焦点。开源许可证是一种授权许可，允许用户在承认原作者著作权的基础上拥有自由复制、修改及再发布的权利。开源许可证是解决知识产权专有性和源代码共享二者之间矛盾的关键。
通常认为符合开源定义的许可证就是开源许可证，开源定义对于开源许可证的标准包含以下几个条件:必须允许任何人以源代码或其他形式重新发布程序，且不收取任何费用，源代码免费可获取，或收取不超过传输成本的费用;必须允许分发衍生或修改后的软件;不歧视任何用户群体或应用领域，保证源代码的完整性;允许对许可证中的权利重新分发;许可证不得特定于产品:许可证不得限制其他软件;许可证必须是技术中立的。
开源软件涉及开源许可证的合规问题，进而可能会诱发一系列潜在风险。目前，经过 0SI认证的开源许可证共有87种，根据其是否要求修改的代码在分发时再次公开大致可以分为开放型许可证、弱传染型许可证、传染型许可证、强传染型许可证4类。
根据新思科技公司发布的《2022开源安全和风险分析报告》，2021年审计的代码库中有53%包含有许可证冲突的开源代码，有17%存在许可证兼容性问题。热门开源项目开源许可证风险较为普遍。经信通院通过开源治理工具扫描显示，容器运行技术领域(Docker，RKT&KATA，Docker)的子项目发现少量使用传染性许可证的开源组件，用户在使用过程中需要关注引人、修改、分发方式，判断可能的违约和被开源风险;容器编排技术领域(Kubermetes，Swarm&Mesos)，均发现少量使用传染性许可证的开源组件;微服务框架领域(Dubbo，Istio&Tars)，均发现使用传染性许可证的开源组件;DevOps领域(Jenkins&Ansible)，Jenkins许可证存在的隐含风险需引起关注;无服务架构领域(0penwhisk&Kubeless)，Openwhisk许可证存在的传染性组件需引起关注;人工智能领域(TensorFlow，Keras&Pytorch)，TensorFlow许可证存在的传染性组件需引起关注;数据库领域MySOL许可证存在的传染性组件需引起关注。开源软件许可证风险中最有代表性的当属GPL了，其允许下游软件使用者随意修改、分发上游供应软件，但同时规定需要将自身软件源码也开源，即大家常说的“Copylett”例如，BusyBox是指明的Unix工具包，包含了Linux 一系列工具集合，其中包括一些GPL许可证授权的工具。
4、安全漏洞风险
新思科技开源治理专家王永雷表示，开源代码已经成为企业数字化转型的重要组成部分，整体看企业开源安全漏洞的比例在下降，越来越多的企业重视开源供应链，借助物料清单(BOM)识别安全漏洞风险。然而安全漏洞风险主要体现在以下五个方面。
第一，漏洞数量保持高位。根据Symopsys 公司《2021开源安全和风险分析报告》显示，BlackDuck审计服务团队在2020年审计的盖17个行业的1546个流行代码库中，98%的代码库包含开源代码，75%的代码由开源代码构成，84%的代码包含至少一个漏洞，每个代码库平均有158个漏洞，65%的代码库存在许可证冲突。而GitHub官方数据显示，2018年新增开源漏洞数也创下近六年新高，新增7563个漏洞，2019年与2020年增长率略有下降，2020年发布的漏洞数较2019年发布漏洞数少了1746条。
奇安信代码安全实验室发布的《2021中国软件供应链安全分析报告》则显示，截至 2020年底，CVE/NVD、CNNVD、CNVD等公开漏洞库中共收录开源软件相关漏洞 41342 个，其中5366 个为 2020 年度新增漏洞。而在奇安信代码安全实验室审计的2557个国内企业软件项目中，存在已知开源软件漏洞的项目有2280个，占比高达89.2%;存在已知高危开源软件漏洞的项目有2062个，占比为80.6%;存在已知超危开源软件漏洞的项目有1802个，占比为70.5%。这些项目中，共检出168604个已知开源软件漏洞(涉及4166个CVE漏洞编号)，平均每个软件项目存在66个已知开源软件漏洞，最多的软件项目存在 1200个已知开源软件漏洞。而从漏洞的影响角度来看，最多的SpringFramework安全洞CVE-2020-5421影响了44.3%的软件项目，多个漏洞影响了超过30%的项目。输入验证、路径遍历、跨站脚本、注入、NULL引用、资源管理、密码管理、API误用、配置管理、日志伪造等十类安全缺陷是程序员在编写软件代码时经常会出现的典型安全缺陷。在2020年检测的1364个开源软件项目中十类典型安全缺陷的总体检出率为56.3%。
第二，漏洞影响范围巨大。根据Synopsys 公司《2021开源安全和风险分析报告》，2020年再次发现了2019年前十大开源漏洞(包括一个高风险漏洞)，其中一些漏洞的百分比显著增加。2021年的Apache Log4j2 洞事件的影响比较严重:2021年12月，ApacheLog4j2被发现其某些功能存在递归解析功能，存在攻击者可直接构造恶意请求，触发远程代码执行的漏洞。根据工信部发布的《关于阿帕奇 Log4j2 组件重大安全漏洞的网络安全风险提示》，该漏洞可能导致设备远程受控，进而引发敏感信息窃取设备服务中断等严重危害，属于高危漏洞。据CheckPointResearch统计漏洞爆发4天(自2020年12月10~13日)情况报告，在ApacheLog4j2洞发现早期的12月10日，黑客尝试利用该漏洞进行攻击的次数仅有几千次，但这一数据在隔天却增至4万次。而漏洞爆发72 小时后，捕捉到利用该漏洞尝试攻击的行为就已超过83万次。
不仅攻击次数在持续攀升，基于该漏洞的新变种也在短时间内迅速衍生。Log4j2作为一个基于Java的日志框架影响范围之广远超开发团队的预想，全球近一半企业因为该漏洞受到了黑客的试图攻击。并且由于ApacheLog4j2 应用范围大、漏洞修复较为复杂，而利用漏洞却十分简便，因此Apache Log4j2 洞很可能在未来几年内也将一直存在。
第三，漏洞危险性极高。2021年底在被广泛采用的ApacheLog4j程序中新发现的零日漏洞。这个被称为Log4Shel(CVE-2021-44228)的Log4j漏洞允许攻击者在受影响的服务器上执行任意代码。随着分析的展开，该漏洞的潜在严重性也变得清晰起来。Log4Shell最令人值得关注的地方并不是它的普遍性，而是它激发了人们的意识。随着该漏洞的发现，企业和政府机构被迫重新审视如何使用和保护主要由无偿志愿者而非商业供应商创建和维护的开源软件。该漏洞的发现还暴露了许多企业根本不知道其软件中使用了多少开源代码的问题。同时，Log4j事件还揭示了企业对开源软件的固有信任问题:大多数开发团队在使用开源软件时都没有像对待商业或私有软件那样进行安全审查。另外，开源代码的多样性使情况变得更复杂。例如，GitHub有数百万个项目，但开发者只有个位数。而对于Kubermetes 等广受欢迎的开源项目，则有大量的志愿开发者参与维护代码当然，其中有一些维护人员受雇于使用漏洞与安全Kubernetes的公司，因此其维护工作也符合公司利益。
第四，开源组件的漏洞修复挑战巨大。当一个常用开源组件因存在漏洞被修复时，人们通常希望把新版本快速同步到其他所有调用了该组件的开源项目中去，而不是同一个漏洞被一次次在不同软件中反复发现、反复修复，浪费人力物力，甚至被攻击者反复利用。上游组件的修复能否快速、大规模、全覆盖地推送到下游依赖环节，是开源软件供应链安全可靠性面临的重要挑战。仍以2021年底爆发的Log4j2为例，Apache Log4j2 零日漏洞(Log4Shell、CVE-2021-44228)因“Lookup”机制存在解析问题，导致了JNDI注入漏洞。该漏洞的触发条件简单，危害却极大。攻击者可向程序输入特定的攻击字符串，当程序进行日志记录时，该漏洞即可被触发，用来执行恶意代码。Log4j2是Java代码项目中广泛使用的开源日志组件，因此这个漏洞很快演变为一场 Java 生态中开源软件供应链的安全危机。据不完全统计，GitHub超过8600多个开源软件直接依赖og4j2组件，但通过这些开源软件继续追溯，最终超过20万个开源软件受到了影响。同时，在官方第一次发布修复版本的一周时间后，仍然有超过80%的间接关联开源软件没有被修复。从数据上可以看出，上游开源组件中一旦发现有严重漏洞，就会直接或间接地影响到依赖它的下游开源软件，同时通过开源软件间错综复杂的层级依赖关系的传播后，该漏洞隐匿在深层依赖的应用中不易被发现，为全球软件供应链带来无法估量且不可控的负面影响。
第五，开源软件组成成分分析受限。目前，二进制文件是唯一可以进行分析检测的对象，但大多数二进制文件都经过了混淆、加壳的处理，给组件成分分析带来了巨大的困难和挑战。同时，从二进制文件推导出组件及版本的精确度问题也需要解决。此外，在进行开源软件克隆检测时，需要有一个巨大的开源软件源代码数据库作为支撑，而如何高效地在海量代码片段中检索到被检测软件的克隆特征，进而进行同源分析，并减少人工确认的工作量、减少误报是工业界面临的一个问题。
5、开源项目供应链风险
对应传统供应链的概念，广义的开源软件供应链可以这样定义:开源软件供应链是一个实际业务系统，在开发和运行过程中，涉及的所有开源软件上游社区(Upstream)、源码包(SourcePackage)、二进制包(Bina-ry)、包管理器(PackageManager)、存储仓库(Repository)，以及开发者(Developer)和维护者(Maintainer)、社区(Community)、基金会(Foun-dation)等，按照依赖、组合、托管、指导等关系形成的供应链网络。
随着开源组件的不断增多，大量的第三方开源组件被集成到软件中，导致供应链变得越来越复杂。“供应链”通常牵扯数十个(甚至数千个)个体开发人员、组织机构、软件片段，以及将它们交织在一起的工具、策略和程序。开源软件供应链关系网络越发复杂多元化，导致开源软件的供应链风险尤其突出。Sonatype的软件供应链状况报告指出，29%的热门开源项目至少包含一个已知漏洞，2020~2021年针对开源软件供应链的网络攻击增加了650%。最常见的攻击是依赖项混淆和命名空间混淆攻击，其次是误植域名攻击。在这几种情况下，攻击者通常依托于恶意软件包，一旦维护人员不小心下载就会被攻击。相对少见的攻击是恶意源注人，但这也是最可怕的攻击。恶意软件会通过黑进开发人员的账户、篡改工具直接注入开源项目，随之进入下游应用程序中，进而影响整个进程。因此需要对软件供应链进行分析、检测与规避隐含的风险。当前开源软件供应链存在标准不清晰、风险处置能力滞后、生态体系不透明等问题。总体来说当前中国开源软件供应链主要面临三方面的挑战。
首先，关键开源组件的可持续维护是一个挑战。开源供应链中关键开源组件出现问题，那么会对整个供应链产生巨大影响。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包管理器中，之后又将项目仓库所有代码清空，完全停止维护，使得依赖于这两个库的数千个项目无法运行。
可靠的软件供应链需要上游供应链软件社区的持续投入和长期支持(Long Time Support，LTS)。软件也存在生命周期，上游供应链软件开发团队能否对软件全周期进行持续高质量的维护与投人，也是软件供应链中的风险点。在安全漏洞披露之后，供应链软件对安全漏洞更新与修复速度影响到下游软件的安全与可靠性，而其依赖于背后是否有一支强大的开发与维护团队。此外，也要注意上游供应链软件的开发者生态。由于开源软件的非营利性，开源社区往往依赖于开发者的无偿贡献与使用者的自愿资助，因此其软件周期存在很大的不确定性，很可能在资金缺乏后停止软件的维护。而软件的停止维护也意味着安全漏洞暴露之后，下游软件无法通过更新的方式规避安全漏洞的风险，使得软件项目暴露在安全风险之下例如，红帽公司决定在2021年12月底停止对Cent0SLinux8的支持，意味着国内大量使用Cent0s的企业都需要进行上游操作系统的迁移与替换而没有及时替换的软件在遇到安全漏洞之后可能面临无法得到红帽公司技术支持的帮助。
其次，国际局势动荡也是一个挑战。最近几年，开源软件供应链出现了意识形态、地缘政治、战争冲突等导致的开源社区分裂。一些关键的开源托管平台和开源基础软件对特定国家、特定实体雇员采取了账号禁止访问、代码删除等“断供”行为，这也是未来开源软件发展面临的又一巨大挑战。开源无国界，但开源组织(如基金会)、开源代码托管平台(属于商业公司所有)都会受到属地出口管制政策的制约。例如，全球最大的代码托管平台 CitHub、全球最大的容器托管平台Docker Hub、国际著名开源基金会Apache软件基金会就明确声明受美国《出口管理条例》的约束。出于美国制裁的原因，GitHub 开始封禁俄罗斯开发者的账号，严格限制俄罗斯获得维持军事能力技术。一些著名的开源社区和开源项目也出现了宣扬政治立场的行为。轻则在开源项目中植人支持某方的标语口号、捐款按钮等，重则把对方排除出开源社区。例如，0penBLAS作为一个基于BSD许可发行的优化 BLAS 计算库，删除了对俄罗斯国产处理器Elbrus 的支持这意味着 Elbrus可能将无法使用新版功能的优化线性代数内核，未来E-brus处理器也无法在被依赖 OpenBLAS库的应用直接使用。
最后，大企业垄断开源生态的行为会阻碍创新。开源一直秉承鼓励创新的发展理念，已成为推动全球数字科技创新的重要因素。数据表明，开源技术支撑了90%以上的互联网产品，推动了一大批小而精的创新型企业发展壮大。开源倡导开放、共享的模式，兴起之时就遭到众多科技巨头的坚决抵制，但随着开源势不可挡的发展，全球科技巨头转而持续加码开源领域，纷纷通过收购开源平台强化其垄断地位，试图通过掌控开源平台不断强化对科技生态的领导力，并使得社区从早期高度分散的技术架构转变为由几个强大的网络巨头所控制的架构。这种“大公司拥抱开源”的现象，一方面，因大公司拥有在更高级别上开发和维护开源项目所需的资金，推动产生了更多的开源重点项目，并有助于提高质量和安全性;另一方面，受商业利益等因素驱使，通过对开源社区项目的开发和商业化推广，对开发人员施加种种限制，易造成技术垄断，阻碍技术创新。