开源软件供应链安全风险分析与发展建议

苏 仟 赵 娆

(国家工业信息安全发展研究中心软件所 北京 100043)

当前，开源已成为人类超大规模智力协同的最佳组织方式之一，也成为科技创新的“主战场”，在世界范围内迎来大发展.2020年，开源在教育、金融、医疗等传统行业渗透率超过60%，开源软件已成为企业构建信息技术的重要选择[1].同时，开源软件也成为软件供应链攻击的成熟目标，面临着安全漏洞、知识产权、开源管制等风险，对关键基础设施和企业客户产生广泛影响.

1 开源软件供应链安全现状

1) 开源软件供应链安全事件频发.

近年来数据泄露、网络敲诈等网络安全事件频发，多数与软硬件中的高危漏洞相关.根据Source Check平台对开源项目的扫描结果显示，53.8%的开源项目至少含有1个超危风险漏洞[2].此外，包含高危漏洞的开源组件数量庞大，据安全软件提供商Sonatype的研究数据显示[3]，仅软件包Maven Central，nmp的存储库中，被视为“高危”的组件达60万个以上.这些包含高危漏洞的软件包被频繁下载，导致漏洞在各行业用户中迅速传播.

2) 开源软件供应链攻击增长迅猛.

随着软件产业的快速发展，针对软件供应链的安全攻击事件一直呈快速增长的态势.2021年，Sonatype共测得1.2万起针对开源软件包的攻击事件，较2020年猛增650%[4].

3) 开源软件供应链攻击左移带来安全左移.

相对于交付、运行等环节，软件开发环节的安全防护比较薄弱，且软件开发环节作为软件供应链的上游环节，安全问题会传导至下游环节并被放大，因此软件开发环节成为攻击者的首选目标.与此同时，安全类产品的能力不断随着攻防状态的变化而更新，融合了开发、安全及运营理念的安全管理模式DevSecOps(Development Security Operations)迅速成熟.对于软件开发来说，安全介入越早，安全成本越小，软件安全继续向左移动到设计阶段，发展成为SecDevOps模式，以确保软件“设计安全”.

2 开源软件供应链风险类型

开源软件具有开放、共同参与、自由传播等特性，对推动企业技术革新、降本增效、数字化转型具有重要作用，已成为各行业技术创新的首选方式，但同样也是软件供应链攻击的成熟目标.开源软件供应链安全保障是一项系统工程，涉及开源软件项目全生命周期的多个方面和环节，主要面临安全漏洞风险、知识产权风险和开源管制风险.

2.1 安全漏洞风险

受限于开发者自身的安全意识和技术水平，加之恶意人员向开源软件植入木马程序等行为，带有安全漏洞和潜在风险的开源代码经常被开发人员所采用，导致开源软件安全漏洞风险被动引入[5].开源软件安全漏洞风险主要包括依赖项混淆攻击、误植域名、恶意代码植入等.依赖项混淆攻击源自依赖项管理器的软件开发工具，开发工具会自动下载比其更高版本号的软件包，若软件包受到感染，安全漏洞将一并部署到应用程序中；误植域名则由于开发人员疏忽，下载部署了与目标软件拥有相近名称的受感染软件包；恶意代码植入则是向开源软件添加漏洞代码，使得运行它的任何系统都受到影响.

此外，开源软件安全漏洞的连锁传播会引发企业关键系统的安全危机，导致不可控的风险.安全公司Snyk发布的开源安全现状调查报告显示，78%的漏洞存在于间接依赖关系中.漏洞传播模拟实验发现，开源组件间的依赖层级关系导致组件漏洞存在传播风险，经1轮传播影响范围相比原始样本扩大125倍，经2轮传播影响范围相比原始样本扩大173倍.漏洞在组件之间的传播风险不可忽视[5].

2.2 知识产权风险

与闭源软件不同，开源软件的开发和使用需遵守开源许可协议，开源许可协议规定了开源软件的使用范围和权力义务.然而企业研发人员、合作方以及外包等供应商难以确保开源组件或开源软件完全遵循安全合规要求，这意味着企业在主动或被动引入开源软件后可能因开源许可证的规定或变动而面临知识产权风险.据新思科技研究显示，经审计的代码库中含有许可证冲突、自定义许可证、没有许可证的开源组件总计占比达90%以上.这使得开源组件的使用存在著作权风险，开源许可协议传染性、合规性和兼容性风险以及内外部专利风险，商标商号纠纷等.

企业在自研和采购软件过程中，往往无法准确判断其是否遵循开源许可协议，进而可能因为开源许可证的传染性规定被迫开源.例如，根据GPL许可证的规定，凡引用、修改遵循GPL代码的软件都必须开源和免费，并且需要采用同样的GPL许可证.此外，开源许可证之间可能不兼容，若无法同时满足各部分代码的许可证要求，则开源软件不可能“合法”分发，必然引发著作权风险[6].开源软件的使用规则存在不确定性，多个开源软件开发商(如Redis，MongoDB，Kafka等)已经对过去使用的开源许可证进行了修改.

主流开源许可证BSD、MIT和GPL 2.0等并未包含明确的专利授予条款，导致内外部专利风险隐藏其中.部分商业软件基于开源进行二次开发后以闭源形式提供给用户，却不遵守开源许可证的署名要求，存在贡献者商标商号的知识产权纠纷.

2.3 开源管制风险

开源代码按照开源协议的限制使用.当前，主流开源许可证、开源软件托管平台、知名开源项目等大多由美国公司出具或运营，部分开源软件供应链受美国法律管辖和出口管制.开源管制风险主要包括开源代码断供、上游贡献限制、开源帐号封锁、产业生态萎缩等.

3 开源软件开发安全解决方案

为了帮助企业在源头解决软件开发安全问题，美国的Synopsys、以色列的Checkmarx和Cycode、中国的奇安信等国内外软件安全供应商纷纷提出全生命周期的开源软件供应链安全解决方案，包括软件成分分析(software composition analysis, SCA)，静态应用程序安全测试(static application security testing，SAST)，动态应用程序安全测试(dynamic application security testing, DAST)，交互式应用程序安全测试(interactive application security testing, IAST)，模糊测试，渗透测试等一系列安全工具和方法，其核心是通过对开源代码的扫描审核，识别应用程序开发生命周期中的可疑和潜在恶意开源包.

3.1 SCA

SCA是一种生命周期管理方法，用于跟踪和管理企业中使用的开源组件，对扫描出来的高危漏洞、不合规许可证、风险组件以及软件成分物料清单(SBOM)等进行实时监控跟踪，提出合理修复建议以及预警等.在高度监管的金融服务领域，SCA成为管理和降低整体风险的关键.企业凭借SCA了解其正在使用哪些开源库以及这些库中可能包含哪些漏洞，并以安全方式快速响应漏洞.

3.2 SAST

SAST可帮助开发团队在编写代码时发现并修复代码中的安全、质量和合规缺陷.静态代码分析工具包括VisualCodeGrepper，RIPS，Brakeman，Flawfinder，Bandit等开源分析工具，以及Perforce公司的Klocwork、Synopsys公司的Coverity等商业化分析工具.静态代码分析工具多样且各有侧重，开发人员可通过1种或多种静态代码分析工具的组合提升误报率.然而，静态代码分析通常需要花费大量的时间成本，阻碍敏捷开发的进行，这也是许多开发人员放弃使用静态代码分析的重要原因之一.

3.3 DAST

DAST无需了解应用程序的内部交互或设计，也无需访问或查看源程序，即可检查正在运行的应用.此外，DAST可对漏洞利用攻击作出实际响应，提供有用的建议，说明该漏洞被操纵的可能性.

3.4 IAST

IAST可根据业务目标和应用安全需求，确定关键风险的优先级并发出警报，并利用现有测试方式主动验证已识别的漏洞，判断该漏洞是否会被利用，从而减少误报.此外，IAST还可识别薄弱的代码行，并提供相应的补救建议，为开发人员解决代码安全问题提供便利.IAST的优点在于其可支持DevSecOps，以及可对应用程序进行持续的实时测试、监控、评估和验证.

4 开源软件供应链发展建议

4.1 建立统一安全管理机制

相较于直接购买商业公司的闭源软件，使用开源软件对企业的开发、运维、安全、法律等方面提出了更高要求[4].目前大多数企业对自身正在使用的开源软件缺乏统一管理，企业级开源软件供应链安全管理模式尚处于探索阶段.此外，分布式架构、云端部署日益成为主流，系统模块化、组件化明显，开源软件之间依赖关系趋于复杂，追踪和理清开源软件之间的依赖关系成为开源治理的难点.实施开源漏洞管理，建立统一安全管理机制成为降低开源风险的有效手段.

在企业外部，鉴于开源软件的多样性和依赖关系的复杂性，企业、行业协会、产业联盟应尽快配合相关主管部门，制定开源安全、风险治理等方面的相关办法和指导性文件，建立统一安全管理机制.从跟踪开源软件依赖关系、确保许可证合规性入手，逐步打破软件开发、法律法规和安全工作流程之间的边界，将现有工作流程中的开源风险问题左移，为开源软件的管理、审计、分析、控制和修复工作提供制度性依据.

在企业内部，根据自身业务特点和既有业务流程，搭建开源管理组织架构，从管理层面进行统筹规划.明确开源治理职责分工，明确开源治理统一协调部门，对接相关主管部门、行业协会、产业联盟、软件供应商等多方资源，协同推动企业开源治理工作落地.

4.2 开展全生命周期风险审查评估

开源代码中不断发现新的安全漏洞，很多开源项目没有查找并修复漏洞的响应机制，也没有明确、标准的安全记录方式可以遵循.GitHub上排名前40万的公共代码库中，仅2.4%的开源项目有安全文档[7].企业引入开源软件过程中，各个环节间缺乏系统的安全审查机制，部分企业内部也缺少必要的安全检测要求和规范，导致企业开源软件的开发、使用、运维人员均无法准确掌握开源软件中的安全漏洞.这些有问题的开源组件将会影响的商业产品、业务领域也无从得知，为行业带来重大安全风险.

开源软件的风险审查评估成为防范开源风险的基础.企业及其开源软件供应商在开源软件的引入、使用、退出、维护全生命周期应联合开展开源软件风险审查评估管理机制[8]，严格执行开源软件全生命周期的安全使用和风险控制，做到先评估再整改，先可知再可控[9].

在开源软件引入阶段：一是企业积极开展开源组件分析能力、漏洞响应能力和漏洞修补能力建设，掌握提供开源组件台账和开源风险点的能力，并持续监控与审查；二是企业结合行业特性，评估所引入开源软件的技术需求，探索建立开源软件选型引入评估模型；三是企业从合同义务等方面确保开源软件供应商遵循开源代码安全合规要求，明确责任.

在开源软件使用阶段，引入或借助专业的技术力量持续加强对在用开源软件的安全风险评估.通过渗透测试、代码安全性分析或者建设网络靶场，持续动态验证和评估开源软件的可靠性、可用性和安全性，提升开源软件的安全应用能力.

在开源软件退出阶段，企业根据实际情况定期制定开源软件退出规划，根据开源软件退出规划进行迁移、替换、退出等操作.

在开源软件维护阶段，企业定期对自身应用开源的情况进行深入摸底排查，真实掌握开源使用规模和复杂度，主动对已存在的安全漏洞、许可证合规风险进行防控处理.

4.3 培育壮大开源软件根社区

近年来，企业结合自身业务需要和实践经验，在开源软件供应链管理方面形成了部分优秀解决方案.但科技企业和实体企业之间存在壁垒，可以落地开源项目的社区规模较小，合适的行业落地途径尚不明晰.

鉴于上述情况，建议凝聚各方资源，着力培育壮大开源软件根社区.加强企业、行业协会、产业联盟、基金会等多方合作互动，学习了解开源软件治理制度规范，分享开源软件治理落地经验.行业协会、产业联盟积极发挥平台优势，加快形成开源标准和自律公约，指导开源软件用户合法合规应用开源技术，形成技术、产业相互促进的良性生态，在全球范围内构建有话语权的国际开源机构.

5 结束语

开源软件供应链安全问题受到广泛关注，建立统一安全管理机制、开展全生命周期风险审查评估以及培育壮大开源软件根社区等有助于建设可靠的开源软件供应链，保障开源软件供应安全、高质量创新发展.