当前，开源已成为云计算、大数据、人工智能、工业互联网等新兴领域的主要开发模式。操作系统、数据库、中间件、应用软件、设备固件等开发、编译、测试都越来越多的采用开源代码，软件供应链的开源化趋势越来越明显。但同时，软件供应链也越来越趋于复杂化和多样化，软件供应链安全风险不断加剧，针对软件供应链薄弱环节的网络攻击随之增加，软件供应链成为影响软件安全的关键因素之一。
一、软件供应链的安全现状
软件供应链目前存在断供、安全、知识产权等方面风险，各个环节安全风险缺乏安全评估，危害严重，影响范围甚广。
（一）断供风险
开源生态受制于人，开源软件供应链“卡脖子”事件频频发生。例如：华为在2019年报发布会上指出，谷歌依托安卓操作系统的GMS（谷歌移动服务）对华为断供，至少影响了100亿美元的海外销售收入；Docker是云计算领域最重要的开源应用容器引擎。2020年8月13日起，它的企业版DockerEE和DockerHub禁止被美国政府列入贸易管制“实体清单”的企业使用，一批中国企业、科研院所和高校受到直接影响。
开源相关的法律约束除开源许可证外，还包括出口管制和司法管辖权。按照美国出口管制条例的规定(734.7b和742.15b)，所有“公开可获得”的源代码(不含加密软件以及带加密功能的其他开源软件)，都是不被出口管制的，而“公开可获得”的带加密功能的源代码，虽不会被限制出口，但需登记备案(5D002)。
司法管辖权是指法院或司法机构对诉讼进行裁决和判决的权力。使用网站或注册会员时，如果其使用条款或会员条款中指定了司法管辖权的归属，则代表合同双方同意只承认指定的司法机关做出的判决为赔偿的依据。从现有开源基金会和托管平台的情况来看，开源基金会的管理办法差异较大。例如，Linux基金会自身的管理办法不受美国出口管制，但其旗下的虚拟化项目Xen明确要求其使用并出口者遵循美国出口管制；Apache基金会的管理办法明确说明遵循美国出口管制，旗下绝大多数项目如Hadoop、Spark等，在备案(5D002)后即不受出口管制。而GitHub、SourceForge和Google Code 3个代码托管平台均明确声明遵守美国出口管制条例，并且司法管辖权均在加州。这就意味着，如果一个开源项目或开源组织声明遵从美国的出口管制条例，此时一旦美国修改条例，将一些核心基础软件加入到管制中，那么大量核心开源项目将受到出口管制。因此，一旦美国针对中国公司的贸易管制政策蔓延到开源项目，中国公司托管在海外的开源代码资产将面临冻结风险。
（二）安全风险
软件供应链可划分为开发、交付和使用三个技术环节，每个环节均存在安全隐患，安全事件时有发生。
在开发环节，攻击者通过污染开发工具、复用开源代码等方式控制上游软件供应链，借助软件开发碎片化显著等特点促使污染代码快速传播影响中下游用户。例如2015年9月爆发的苹果开发工具XcodeGhost 事件。Xcode 是一款苹果的开发工具，攻击者利用当时通过官方渠道获取 Xcode 官方版本困难的情况 , 在非官方渠道发布的 Xcode 注入病毒，导致 2500 多款使用该开发工具开发的苹果 App 被植入恶意代码，受影响的苹果 iOS 用户达 1.28 亿。
在交付环节，软件提供方通过网站平台下载、镜像安装、固定销售网点购买等方式完成软件交付。由于交付渠道、交付环境等方面缺乏安全分析评估，导致攻击者利用捆绑软件、下载劫持、依赖混淆等方法实施攻击。例如，2017年8月，安全研究人员发现知名电信设备制造商Iris生产的调制解调器存在五个安全漏洞，其中三个硬编码后门账号漏洞。由于未及时开展漏洞挖掘和修复工作，直接导致攻击者利用三个后门账号控制设备，获取root 权限，安装新固件乃至架设僵尸网络。
在使用环节，由于用户未对升级程序、组件、代码等进行严格检查，导致攻击者在更新升级或者打补丁过程中植入恶意代码控制用户系统。例如，2020年12月，美国SolarWinds公司的Orion软件更新服务器上存在一个被感染的更新程序，导致美国财政部系统等约18000家关键基础设施、联邦机构和企业受到影响，部分受影响设备可由攻击者完全操控。
目前，开发者对开发工具依赖度高，对其中漏洞、恶意代码等安全威胁少有评估，产生的安全风险不言而喻。因此，在软件供应链各个环节应开展安全评估，尽早发现其中的安全问题并采取有效的修复措施。
（三）知识产权风险
开源许可协议是涉及版权、专利、商标等一系列权利义务的格式合同，开源软件的作者或权利人主要通过开源许可协议对其知识产权进行许可与约束。若开源软件使用者未依照相应的开源许可协议使用开源软件，将可能面临知识产权及合规风险。
按知识产权的种类可以将知识产权风险分为：专利风险、商标风险、著作权（版权）风险、商业秘密风险、不正当竞争风险；而按照知识产权风险的性质又可以将知识产权风险划分为：知识产权法律风险、知识产权管理风险、知识产权纠纷风险、知识产权侵权风险。
全球范围内的开源许可协议已达上百种，多种开源许可协议之间还可能存在不兼容性。2020年，98%的代码库包含开源代码，而65%的代码库存在许可证冲突，近四分之三的代码库包含GPL许可证冲突。违反许可证的条款造成违约行为，开源使用者很可能被开源贡献者提起专利诉讼并收取专利许可费。
二、国外与国内对供应链的政策分析
（一）美国政府率先将供应链安全上升至国家战略
美国政府在2008年颁布《国家网络安全综合倡议》（CNCI），要求在产品、系统和服务的整个生命周期内综合应对国内和全球供应链风险。
2009年奥巴马政府发布的《美国网络空间安全政策评估报告》将ICT供应链安全纳入国家安全范畴。
2012年，美国国土安全部发布首个国家层级的战略报告《全球供应链安全国家战略》，提出安全和高效两大目标。
此后，各相关机构出台了一系列文件，如国家标准和技术研究院（NIST）的《联邦信息系统与机构供应链风险管理实践》（2013）、国家网络安全促进委员会的《加强国家网络安全—促进数字经济的安全与发展》（2016）、国土安全部的《供应链风险管理计划》（2017）、白宫的《联邦信息技术供应链风险管理改进法案》（2018）等等。这些文件涉及机制建设、标准制定、产品认证等各领域，形成了比较成熟的ICT供应链风险管理制度体系，在监管国内相关领域的同时也起到了引领国际治理制度建设的作用。
2019年5月，特朗普签署《确保信息通信技术与服务供应链安全》行政令，禁止交易、使用可能对美国的国家安全、外交政策和经济构成特殊威胁的外国信息技术和服务。
2021年，美国商务部发布《确保信息和通信技术及服务供应链安全》的最新规则生效，对美国国家或公民构成不可接受之风险的外国对手的信息通信技术和服务(ICTS)交易所进行识别、评估和风险消除程序，从而决定是否禁止交易。
2021年5月12日，美国总统拜登发布关于增强国家网络安全的 14028 号政令，明确要求联邦政府采取行动，迅速提高软件供应链的安全性和完整性。
（二）应对供应链安全风险，我国相关政策措施逐渐完善
国家层面高度重视软件供应链安全问题，不断建立健全法律法规、标准制度。为应对国内外软件供应链安全威胁，近年来我国先后颁布的《中华人民共和国网络安全法》《网络安全审查办法》《中华人民共和国国民经济和社会发展第十四个五年规划和 2035 年远景目标纲要》《关键信息基础设施安全保护条例》等政策法规强调加强软件供应链的安全保障。
2018年，我国出台了供应链安全管理国家标准《信息安全技术 ICT 供应链安全风险管理指南》(GB/T 36637-2018)。从产品全生命周期的角度开展风险分析及管理，以实现供应链的完整性、保密性、可用性和可控性安全目标。
2020年，中国电子技术标准化研究院发布的国家标准《信息技术产品供应链安全要求》征求意见稿，规定了信息技术产品供应方和需求方应满足的供应链基本安全要求；电信终端产业协会发布的《网络产品供应链安全要求》行业标准对网络产品在管理制度、组织机构和人员、信息系统等以及供应链环节提出了不同等级的安全要求。
2021年，我国率先开展针对软件供应链安全的国家标准立项工作，拟通过研究制定《信息安全技术软件供应链安全要求》提升国内软件供应链各个环节的规范性和安全保障能力。
三、软件供应链风险的应对措施建议
国家出台的一系列政策法规、标准制度是保障软件供应链安全，维护网络空间安全的坚实后盾，然而，如何评估和判断软件各环节是否达到相应安全要求目前尚未形成共识，亟需构建软件供应链安全评估机制，全面保障软件产品和服务安全。
在国家政策层面，持续加强国家层面在软件供应链安全方面的战略引导作用，制定专门针对软件供应链的法律法规，完善软件供应链安全评估政策体系，并组织建设软件供应链公共服务平台，向用户提供查询、检索相关标准、规范、指南等信息，大力推进软件产业的供应链发展。
在管理措施层面，加强软件供应链各环节的管理安全评估，督促供应方、需求方加强组织管理，开展软件供应链安全审查，加强开源许可证合规性分析，加强企业DevSecOps相关能力建设，提升软件开发、交付及使用的规范性和安全保障能力。
在技术评估层面，制定软件供应链技术安全评估规章制度，加强软件成分分析，引入软件供应链安全评估技术平台，并快速识别并修复软件供应链开发、交付和使用环节存在的安全风险。
四、软件供应链的未来发展方向
（一）企业DevSecOps相关能力建设提升软件质量，降低安全成本
DevSecOps开发模式能将安全需求在开发过程中尽可能早的阶段进行实践，在提高软件安全性的同时提高开发团队的开发效率，缩短交付时间，将安全贯穿软件开发生命周期，让业务、技术和安全协同工作，实现设计、开发、测试、交付、运维与安全统一融合，开展安全、高效的软件开发，提升软件质量，降低安全成本。
（二）加强软件SBOM建设，对于整个产业在知识产权风险控制、软件风险持续跟踪、软件管理等方面均有重大意义
软件物料清单 (Software Bill of Materials，SBOM) 是构建（即编译和链接）给定软件所需的组件、库和模块的完整、正式结构化列表以及它们之间的供应链关系。
目前业界对于软件供应链的标识化主要通过软件物料清单、成分清单方法界定，但国内大多数上下游厂商均未集成相应的自动化SCA工具，对于使用的软件成分未知，无法提供软件成分清单(SBOM)，国内相关的SBOM标准也处于“空白”状态。软件系统的不透明性进一步加大了开发、采购和维护的成本，增加了网络安全风险。除了企业所依赖的产品和服务外，风险和成本还会影响到集体产品，如公共安全和国家安全。
由此可见，软件透明是解决潜在安全问题的主要影响因素。为了更好保障软件供应链透明、安全，从上游到下游的供应链中广泛地的生产、分发和使用SBOM，配合相应的自动化SCA安全工具至关重要。
上游供应商具备创建、分析、维护能力，同时在商业软件交付中，上游生产商应明确给出的SBOM清单作为软件交付的一部分，方便下游消费端或者其他第三方控制方进行资产管控、安全和合规等相关决策。
对于下游使用者，对于不同上游的软件产品以及相应的SBOM清单，支持导入各渠道SBOM清单，实现完整的资产管理、许可证和权限管理、知识产权管理、法规遵从性管理、漏洞管理、事件响应等，为采购审查、知识产权审查、安全漏洞管理提供决策支持。
最后，为保证SBOM数据的通用性与兼容性，需要进行更多的研究来完成相应的通用标准的制定，实现上下游标准统一化、最大程度兼容和适配。