2021软件供应链安全白皮书.pdf

前言INTRODUCTION 随着容器、微服务等新技术日新月异，开源软件成为业界主流形态，软件行业快速发展。但同时，软件供应链也越来越趋于复杂化和多样化，软件供应链安全风险不断加剧，针对软件供应链薄弱环节的网络攻击随之增加，软件供应链成为影响软件安全的关键因素之一。近年来，全球针对软件供应链的安全事件频发，影响巨大，软件供应链安全已然成为一个全球性问题。如何更加全面、高效地保障软件供应链的安全对于我国软件行业发展、数字化进程推进具有重要意义。软件供应链安全作为国家近几年新提出的网络安全理念，不再是针对软件供应链上单一环节进行安全防护，而是针对软件供应链全链路进行安全监控防护，薄弱环节的安全预防更是重中之重。本白皮书着重分析了软件供应链安全，梳理了软件供应链的安全现状，透过现状全面剖析软件供应链的安全风险及面临的安全挑战，有针对性地提出如何对软件供应链的安全风险进行防范与治理，系统阐述了软件供应链安全的防护体系及软件供应链安全的应用实践以供参考，最后白皮书结合现在软件供应链安全的发展趋势进行了全面的分析及展望。目录CONTENTS1 软件供应链概述1.1 软件供应链与传统供应链之间的共性及差异性 1.2 软件供应链的发展历程1.3 开源和云原生时代改变了传统的软件供应链08080910101012121414161818202222232324240204052 软件供应链安全现状21 国内外软件供应链安全发展现状 2.1.1 国际软件供应链安全发展现状 2.1.2 国内软件供应链安全发展现状2.2 软件供应链的安全挑战 2.2.1 国际竞争环境加剧，软件供应链完整性遭遇挑战 2.2.2 软件开源化趋势增强，安全风险加剧 2.2.3 软件复杂度增加，软件供应链每一环节均存在风险 2.2.4 难以处理敏捷开发与安全成本之间的平衡3 软件供应链风险分析3.1 软件供应链风险概述 3.1.1 软件供应链风险现状 3.1.2 软件供应链风险因素分析3.2 软件供应链的漏洞类型 3.2.1 漏洞来源类型 3.2.2 漏洞状态类型3.3 软件供应链的攻击类型 3.3.1 预留后门 3.3.2 开发工具污染 3.3.3 升级劫持 3.3.4 捆绑下载 3.3.5 源代码污染282829323232343535384040414647484 软件供应链安全治理方法4.1 体系构建阶段 4.1.1 SDL 软件安全开发生命周期 4.1.2 DevSecOps4.2 设计阶段 4.2.1 软件供应商风险管理流程 4.2.2 软件供应商评估模型 4.2.3 软件供应商风险管理的作用4.3 编码阶段 4.3.1 构建详细的软件物料清单 4.3.2 使用基于 SCA 技术的工具4.4 发布运营阶段 4.4.1 建立成熟的应急响应机制 4.4.2 构建完善的运营保障工具链 5 软件供应链安全应用实践5.1 可信研发运营安全能力成熟度模型5.2 云安全共享责任模型5.3 Grafeas 开源计划软件供应链概述01 21.1 软件供应链与传统供应链之间的共性及差异性行业内对软件供应链有多种理解，其中包括三种主流理解方式，第一种是将软件供应链单纯视为以开源组件为主的第三方组件供应链条；第二种是将其视为软件生产过程供应链条，包括第三方组件、开发工具和开发环境等要素；第三种是将其视为从原材料开始加工成消费者手中的最终产品并实施运营过程的全流程链条。由于前两种理解存在不同程度的片面性，因此本白皮书中以第三种理解作为阐述基础。传统供应链的概念可以理解为一个由各种组织、人员、技术、活动、信息和资源组成的将商品或服务从供应商转移到消费者手中的过程，这一过程从原材料开始，将其加工成中间组件乃至最终转移到消费者手中的最终产品。软件供应链是根据软件生命周期中一系列环节与传统供应链的相似性，由传统供应链扩展而来。软件供应链的生命周期包括原始组件、集成组件、软件产品及产品运营四个环节（如图 1 所示）。在软件供应链中，原始组件是原材料，集成组件是中间组件，软件产品是交到消费者手中的商品，产品运营是为消费者提供的服务保障产品的正常运行。因此，软件供应链可以理解为软件和系统的从生产到交付全过程，是一套自动化、标准化及规模化的持续交付的流水线。通过设计和开发阶段，将生产完成的软件产品通过软件交付渠道从软件供应链运输给最终用户。原始组件、集成组件、软件产品及产品运营四部分涵盖保障软件供应链安全涉及的诸多关键安全要素，了解软件供应链的每一个阶段及流程中出现的源代码、工具及集成组件对于构建安全可靠的软件供应链至关重要。根据软件供应链的定义，软件供应链安全可以被理解为软件生产的整个过程中软件设计与开发的各个阶段来自编码过程、工具、设备、供应商以及最终交付渠道所共同面临的安全问题。对软件从业者来说，实际需要关注的是自身的软件产品开发过程和运营过程，也就是软件产品和产品运营这两个阶段，软件供应链中的原始组件和集成组件阶段的安全问题应由相应的组件供应商解决。做个类比，假如我们需要生产一部手机，我们需要关注的是手机生产和上市运营。在生产手机过程发生前，我们需要选择可信的零部件供应商，从之购买合格的零部件。而并不需要接管供应商的生产流程，帮助供应商做质量管理。软件产品阶段和产品运营阶段的加总，实际上就是传统概念中的软件生命周期。软件生命周期可以划分为 4 个主要阶段：图 1 软件供应链生命周期 3软件供应链和传统供应链的安全性之间存在显著的共性及差异性，软件供应链与传统供应链之间的共性是攻击者通过攻击目标供应链中较弱的组成部分，导致产业链上游被污染，大量下游厂商的产品或服务作为上游组件的集合，产生大量潜在的攻击目标，而且基于对产品和服务的潜在信任，导致在安全问题出现时，难以彻底断根筛查。同时，召回问题产品的代价巨大，周期漫长，显著增加了供应链攻击的影响程度。差异性是软件供应链所受到的攻击与传统供应链相比，软件攻击面的边界由产品本身扩大到软件生产过程中代码、服务及组件的边界，导致软件供应链的受攻击面不断扩大，显著降低了攻击者攻击的难度，这就导致软件供应链攻击可能发生在软件供应链生命周期的任何阶段，同时更聚焦在威胁的高传播性和强隐蔽性，而非仅仅聚焦在瞬间的破坏力上。设计阶段、编码阶段、发布阶段、运营阶段（如图 2 所示）。这也是软件供应链安全治理中真正需要关注的部分。图 2 软件供应链生命周期与软件生命周期的关系 41984 年，UNIX 创造者之一的 K.Thompson 在 AM Turing Award（ACM）图灵奖的获奖演讲中提到如何通过三步构造一个通过编译器污染所有通过此编译器编译并发布软件的攻击方式，这种攻击可以在人们难以发现的情况下修改编译器，并在其中设置后门。基于此，一个通过攻击软件开发过程中薄弱环节的攻击方式暴露在人们的视野中，这就是令人头疼的 Advanced Persistent Threat（APT）攻击，在著名的震网事件中，非法组织利用震网病毒破坏世界各国的计算机系统，进而破坏国家重要的基础设施。1995 年，软件供应链的概念出现在大众的视野中，之后在 2000 年，M.Warren 和 W.Hutchinson 提出了利用网络攻击破坏软件供应链的可能性。2004 年，微软公司提出了著名的软件安全开发生命周期流程，这一流程将软件开发流程划分为多个阶段，并在各个阶段中引入不同的安全措施，保障软件开发以及最终用户的安全性，并建立了漏洞发现和漏洞处理框架机制。同时提出了多种安全测试工具以及软件发布后的相关运营管理规范，至今仍是各大企业采用处理软件开发安全问题的重要手段之一。2010 年，R.J.Ellsion 和 C.Woody 两人针对当时软件开发过程中直接采购商品化的产品和技术以及产品外包服务逐渐增加的趋势，出于对软件供应链的安全考虑，针对软件开发过程中提出了软件供应链风险管理这一思想，并介绍了相关的风险来源、种类以及风险的分析方法，并讨论了如何应对软件供应链风险的相关措施。2014 年出现著名的 HeartBleed 漏洞，作为被基于 SSLTLS 的软件和网络服务所广泛使用的开源软件包的漏洞，感染了软件和服务的开发阶段中上游代码和模块，并沿着软件供应链，对供应链下游造成了不可磨灭的负面影响，因此这一事件被广泛认为是一起典型的软件供应链安全事件。由于近年来，一系列具有极高相似性的安全事件频频发生，这些事件中所使用的网络攻击方式与传统攻击方式相比具有更加鲜明的高隐蔽性、高传播性、低成本和高效率的特点，使软件供应链安全这一概念受到产业界和学术界的极大关注。2017 年，微软公司旗下的一个研究团队发出声明，声明中表示微软旗下的安全软件阻挡了一起精心策划的，通过攻击软件更新渠道，将插入了恶意代码的第三方软件传输给使用该软件的多家知名机构的高级持续性威胁攻击。在这篇声明中，微软针对本次安全事件，首次提出了“针对软件供应链的网络攻击”这一概念。近年来，由于软件开发日益全球化，导致软件供应链的安全风险愈发严峻，已成为人们不可忽视的存在。软件供应链像是一个充满了未知且不可确定危险因素的地带，需要人们给予更多的关注和思考。1.2 软件供应链的发展历程 5图 3 开源代码占软件代码的比例不断增长与开源密切相关并改变传统供应链的还有云原生时代的出现，容器、Docker 和 Kubernetes（K8s）等概念的出现，改变了传统软件交付的方式，进而影响到软件供应链。容器和 K8s 的引入导致软件供应链的复杂程度加剧。（如图 4 所示）通过引入容器和 K8s 给软件供应链带来更多不可控的第三方依赖，不同于传统的软件供应链，镜像作为软件统一交付的标准在容器场景下被大规模的应用，这极度加大了软件供应链的复杂性。开源是指公开源代码的软件，任何人都可以进行自由修改和共享。源代码是程序员可以创建和编辑以改变软件工作方式的代码。通过访问程序的源代码，开发人员或程序员可以通过添加功能或修复有缺陷的部分来改进软件。在当今快节奏的商业世界中，越来越多的软件团队采用了 DevOps 等敏捷开发实践以跟上业务的需求，这些做法给开发人员带来了很大的压力，要求他们能够更快地构建和部署应用程序。为了在较短的软件发布周期内成功实现此目标，开发人员经常通过对开源软件组件进行修改添加所需要的功能以加快软件开发的速度。开源组件已成为企业实现快速开发和科技创新的必要条件。据统计，大部分的商业程序中都包含开源软件，开源为企业节省了大量的时间和金钱、提高了软件生产质量、提供了业务敏捷性并降低了某些业务风险。若没有开源组件，企业的软件生产将成倍地迟缓。据 Forrester 2021 年发布的报告数据显示（如图 3 所示），开源代码占软件代码的比例从 2015 年到 2019 年的五年时间内几乎翻了一倍。随着开源组件的不断增多，大量的第三方开源组件被插入到产品中，大量开源组件的使用也导致软件供应链变得越来越复杂。1.3 开源和云原生时代改变了传统的软件供应链 6K8s 是一个复杂的平台，需要多个部分组合才能完成工作，但是将其各个部分集成为一个整体后又变得难以管理，当需要安装或更新 K8s 时，必须分别对每个单独的组件进行配置；大量使用容器虽然优化了软件应用程序架构，并且标准化了软件开发和生产环境，但同时也增加了软件部署管理的复杂度。云原生时代下镜像的使用镜像构建构建平台&IDE镜像传输镜像仓库镜像运行/升级K8s运行时图 4 云原生时代下软件供应链软件供应链安全现状02 82.1.1 国际软件供应链安全发展现状开源和云原生时代的到来导致软件供应链越来越趋于复杂化和多样化，安全风险不断加剧，针对软件供应链薄弱环节的网络攻击也随之增加，软件供应链安全已然成为一个全球性的问题。虽然，国际上对加强软件供应链安全管理也早已成为共识，但仍需详细了解软件供应链的背景及发展情况，以便更好的应对软件供应链的安全风险。自软件供应链的概念被提出以来，国际上对软件供应链安全有着高度的重视，国际软件供应链安全的发展情况可从国家层面和企业层面两个方面进行讨论。国家层面，以美国为例，出于对软件供应链的安全性及脆弱性的担忧，早在多年前就开始着手布局国家级软件供应链的安全战略，陆续出台一系列相关政策和重点项目来加强软件供应链的安全管控。2015年4月，美国国家标准与技术研究院（NIST）正式发布软件供应链制定规范 ICT 供应链风险管理标准（NIST.SP800-161），帮助组织机构管理软件供应链安全风险，清楚地界定了软件供应链中相关的标准和要求，建立了适当的政策和流程控制，在一定程度上规避了软件供应链面临的诸多风险。目前，NIST 的标准系列文件，已成为美国和国际安全界广泛认可的事实标准和权威指南。近年来随着管理措施的陆续落地和管理范围的扩大，美国软件供应链安全防御体系不断加强。2017 年、2018 年更是针对关键信息基础设施相关的供应链安全提出了明确的要求，其中包括促进供应链风险态势及相关信息共享、加强供应链风险审查评估、推动相关标准的实施应用等。美国政府正在不断将软件供应链安全问题深化和细化，关注点正在聚焦到特定的 IT 产品和服务上。2021 年 5 月12 日，美国总统拜登签署发布了改善国家网络安全行政令，该行政令是美国联邦政府试图保护美国软件供应链安全采取的最强劲措施，要求向联邦正式出售软件的任何企业不仅提供应用程序，而且还必须提供软件物料清单，提升组成该应用程序组件的透明度，构建更有弹性且安全的软件供应链环境，确保美国的国家安全。除美国之外，2016 年，英国国家互联网应急中心（CERT-UK）发布供应链网络安全风险白皮书，其中，介绍了各类软件供应链的风险案例和规避建议。2018 年 1 月，英国国家网络安全中心（NCSC）发布供应链安全专题和指导文件，其中包括 12 条安全原则，供应链攻击示例和安全性评估方法以及管理实践。在企业层面，开源软件作为软件供应链中最重要的一个部分，国际上的头部企业也进行了相关的合作：以 Google为首的 7 家技术公司在 2017 年合作推出了一个名为 Grafeas 的开源计划，旨在为企业定义统一的方式，审计和管理其使用的开源项目。2.1 国内外软件供应链安全发展现状 92.1.2 国内软件供应链安全发展现状随着网络安全形势的不断变化发展，在严峻的网络安全环境下，我国对软件供应链安全给予了高度的重视。2017年 6 月，我国发布实施网络产品和服务安全审查办法，将软件产品测试交付、技术支持过程中的供应链安全风险作为重点审查内容，并推动开展了云计算服务网络安全审查。在 2020 年 4 月 27 日，国家互联网信息办公室等 12 个部门联合发布了网络安全审查办法，要求关键信息基础设施运营者采购网络产品和服务，影响或可能影响国家安全的，应当进行网络安全审查，此政策的发布代表已明确将软件供应链安全带入到国内大众的视野中。我国针对开源软件的发展也已出台了相关政策，特别是2021年在中国 “十四五”规划和二零三五年远景目标纲要文件中，明确提出“支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务”，这是开源首次被写入国家总体规划纲要之中。企业层面，我国头部的互联网企业和安全厂商均开始投入到软件供应链的安全建设中，围绕保障软件供应链安全的重大需求，充分发挥创新技术在软件供应链网络安全保障中的作用，加大软硬件安全检测及分析、攻防渗透技术、源代码安全审计、漏洞挖掘技术、大数据分析技术等创新技术的研发及投入，切实落实对软件供应链安全的保障，构建一套动态的安全防护体系。同时，国际上许多知名企业正不断加大针对软件供应链的安全风险治理工作，针对开源软件采用软件成分分析技术，确保第三方开源组件的安全性；针对软件开发这一过程，微软提出的软件安全开发生命周期（SDL）及 Gartner 提出的 DevSecOps 理念，均旨在帮助企业降低在软件开发过程中所面临的安全问题。102.2.1 国际竞争环境加剧，软件供应链完整性遭遇挑战2.2.2 软件开源化趋势增强，安全风险加剧软件供应链的竞争和保障，不仅影响着企业的生存和发展，同时也成为世界各国之间互相制约与竞争的重要手段。某些西方国家通过实行严密的技术封锁，建立完善的出口管制法律制度体系，将本国的软件、硬件和技术列入出口管制清单，这导致国际软件供应链竞争环境加剧，软件供应链的完整性遭遇严重的挑战。在全球软件供应链安全问题日益突出，国际 IT 技术竞争激烈的背景下，对我国自主研发生产相关软硬件、研发创新技术及提高 IT 技术实力提出了新要求，同时需要做好软件供应链战略计划，确保我国软件供应链自主可控、安全高效。软件供应链开源化趋势增加，导致影响软件供应链的各个环节都不可避免的受到开源环境的影响。作为创新的基础，开源正不断推动深度信息技术的创新发展，因此开源软件正在呈现指数级增长。例如：根据美国国家计算机安全中心（NCSC）公开的数据显示由流行的软件开发和源代码管理平台 GitHub 托管的公共存储库数量从 2009 年 2 月的46000 个激增到 2020 年 1 月的 2800 万个。由于开源软件之间的关联依赖关系非常复杂，一旦出现安全问题所带来的蝴蝶效应将带来十分严重的影响，若一款开源软件出现未知的安全漏洞，将会导致所有与之存在关联依赖关系的其他软件系统出现同样的漏洞，漏洞的攻击面将会由点及面呈现出爆炸式的放大效果。根据 Sonatype 发布的2020 State of the Software Supply Chain报告可以了解到（如图 5 所示），开发人员往往不能在漏洞披露的第一时间进行漏洞修复工作，51%的开发人员至少需要一个星期以上的时间才会对漏洞采取修复措施，这意味着攻击者有充分利用漏洞进行攻击的时间，极大地增加了软件供应链的安全威胁。软件可以定义世界，数据可以驱动未来，软件正逐渐成为影响世界快速发展的重要因素。软件快速发展需要安全保驾护航，因此软件供应链安全也成为世界广泛关注的重点，根据上述对我国软件供应链现状的描述，结合现阶段国际网络安全形势，可以总结出当前我国软件供应链所面临的安全挑战。2.2 软件供应链的安全挑战 11图 5 从漏洞发现到修复所用的时间开源软件出现漏洞时，若不能及时获取应用程序中漏洞的详细信息，则会导致开发人员修复漏洞难度的增加。根据 Veracode 发布的 2021 软件安全状况报告可以了解到（如图 6 所示），当开发团队了解应用程序中漏洞信息时，3 个星期的时间就可以修复 50%的漏洞，若开发团队不了解其信息，则这一时长大幅增长到 7 个月以上。除此之外，还可能存在具有非法目的开发者故意预留后门的安全缺陷，攻击者通过将恶意代码注入为全球软件供应链提供组件的开源项目中，借助开源软件的“高信任度”和影响力，通过感染软件供应链的“上游”组件加速向“下游”扩散，产生的破坏性进一步加大。同时，国内部分开源软件和开源组件还涉及到开源许可证的冲突风险和知识产权的风险，推进开源标准，完善开源知识产权和法律体系是我国实现开源发展体系化规模化的重要手段之一。不仅如此，开源软件提高了企业软件供应链的暴露程度，国内大多数企业缺少对技术风险、法律风险和供应链风险的认知，极度缺乏专业知识和应对经验，在大量使用开源软件的情况下，可能使其成为攻击者的切入点。因此，软件开源化的趋势导致软件供应链面临极大的安全挑战。了解应用程序中脆弱的开源依赖关系对修复时间的影响7个多月才能修复50%的缺陷开发人员不了解3个星期可以修复50%的缺陷开发人员了解图 6 了解漏洞信息对修复时间的影响 122.2.3 软件复杂度增加，软件供应链每一环节均存在风险2.2.4 难以处理敏捷开发与安全成本之间的平衡现阶段，软件的复杂度随着用户对软件功能需求的不断提高而增加，由于信息技术产业的不断发展以及其它产业对软件依赖的加深，这一趋势将在未来几年持续增加。软件复杂度的增加会导致软件开发的难度加大，同时也会增加后续软件维护的难度。随着软件规模越来越大，程序逻辑越来越复杂，对软件完整语义的理解及操作逻辑的把握越来越困难，设计缺陷、深层次漏洞更难以发现，后门更易于隐藏。在软件扩展过程中新增的组件需要与原组件进行交互，导致了软件开发的组件化、复用化，以及软件供应链的产生。软件供应链可以理解为一个链条，那么在链条上的每一个环节都可能产生安全威胁，由于软件设计缺陷和软件开发过程中产生的漏洞将沿着软件供应链的树状结构由上游向下游扩散，加大了软件供应链的安全风险，同时这也对软件的业务逻辑和安全质量控制及标准提出了更高的要求。随着互联网时代的高速发展，信息得以快速传递，这对软件开发管理带来前所未有的冲击。用户对于软件的功能性、实用性和易用性等方面的要求越来越高，软件市场的竞争压力不断加大，互联网企业面临更加复杂和快节奏的外部环境，这要求软件开发者在较短的时间内完成大量功能开发的任务，并在后续持续不断地高速迭代以满足市场的需求。由于要节省时间成本，开发者在开发过程中必然会大量使用开源库与外包供应商提供的非公开库。但是，在使用外部库时会存在大量安全隐患，一旦出现数据泄露等安全问题，将导致极其巨大的经济损失。在敏捷开发模式中，因为安全影响开发效率导致安全与开发严重割裂，传统安全团队上线前介入的模式已经严重滞后，不仅不能有效地进行系统的安全防护，同时也会影响应用的交付速度。如何在较短的开发周期内尽量完善软件功能，同时完成相对完备的安全性测试，实现质量、安全和速度的平衡是现阶段各企业及开发部门所面临的重要挑战。软件供应链风险分析03 143.1.1 软件供应链风险现状3.1.1.1 软件依赖进口，源头难以控制3.1.1.2 开源存在缺陷，引入安全风险随着我国科技的高速发展，软件供应链正不断延伸，由于针对软件供应链的攻击成本低且回报高，不法分子逐渐将攻击目标转换到软件供应链的薄弱环节上。我国软件供应链面临的安全风险不断加大，遭受破坏而引发的网络安全事件数量逐步上升，因此，有必要针对导致我国软件供应链产生安全风险的主要因素进行深入探讨分析。目前，我国在国家信息建设中关键软件技术方面还无法实现完全自主研发可控，诸多核心行业的关键基础软件长期依赖进口，这为我国的软件供应链安全留下了难以估量的安全隐患。软件供应链上的任一环节出现问题，都有可能带来严重的安全风险，在国家关键基础设施中过度使用从国外引进的技术或软件产品，将加大我国软件供应链安全出现威胁的可能性，危害国家信息安全，同时也会给国家经济安全带来严重的隐患。“棱镜门”事件的发生让世界人民意识到：网络监听、远程控制、数据窃取等并不是危言耸听而是真实存在的。中国互联网新闻研究中心发布的报告美国全球监听行动记录显示，经过长达几个月的查证，中国发现美国的“棱镜门”秘密项目中有针对中国机密的监听行为，此次监听行动涉及中国政府和领导人、中资企业、科研机构等，给中国的信息安全带来严重的影响。除此之外，西方大国还借助其在 IT 领域的技术优势，在相关软硬件产品内预置后门，通过我国进口其软件产品将安全威胁带入国内，非法获取我国重要的信息数据。因此，长期依赖软件进口，将难以从软件生产的源头进行安全治理，会加剧我国软件供应链所面临的安全风险，影响我国推进软件供应链安全的进程，甚至会威胁到国家安全。开源软件的安全形势已愈发严重。根据 RiskSense 发布的研究报告得知，2019 年已公开的开源软件 CVE 漏洞总数为 968 个，比之前数量最高年份的两倍还多，2020 年前三个月新增的 CVE 漏洞数量也处于历史高位。从美国国家漏洞库（NVD）对于开源软件的漏洞管理情况来看，其收录开源软件漏洞的滞后性比较严重，从漏洞首次公开披露到收录进 NVD 平均耗时 54 天，最长耗时 1817 天。攻击者完全有可能利用这段时间开发和部署漏洞利用程序，而正在使用存在漏洞开源软件的企业由于无法及时收到 NVD 的安全警报，企业将完全暴露在安全风险之中。2020 年 2 月，国家信息安全漏洞共享平台（CNVD）发布了关于 Apache Tomcat 存在文件包含安全漏洞的公告，该漏洞可以造成 Tomcat 上所有 webapp 目录下的重要配置文件或源代码等敏感数据的泄露，若同时存在文件上传功能，则可能会进一步实现远程代码执行（RCE），直接控制服务器。Tomcat 是 Apache 软件基金会下一个重要的开源软件，在全球范围内被广泛使用，根据调查数据显示，国内受影响采用 AJP 协议的 IP 数量大约是 4 万个。3.1 软件供应链风险概述 15为了加快业务创新，应用开源技术提高开发效率已经成为企业的主流选择，但也导致企业对复杂的软件供应链的依赖日益增加。尽管开放源码组件具有许多优点，但它的广泛应用也带来了新的安全挑战，一方面由于开发者自身安全意识和技术水平不足容易产生软件安全漏洞，另一方面也无法避免恶意人员向开源软件注入木马程序进行软件供应链攻击等安全风险的存在。由于开源软件使用与获取的便利性，几乎每个商业软件都会大量使用开源组件，但企业并没有对开源组件的来源和质量给予足够的重视，甚至会忽略掉软件组件所带来的安全风险。据 Sonatype 发布的2020 State of the Software Supply Chain报告数据显示，从 2012 年到 2018 年开发团队声称使用的 OSS 组件数量和实际审计出的 OSS 组件数量的差距逐渐加大（如图 7 所示）。企业在软件开发的过程中，对开源软件的使用比较随意，管理者通常不清楚开发团队在开发过程中是否有使用开源软件，具体使用了哪些开源软件，这些开源软件是否存在安全漏洞等，这无形中给软件供应链带来了难以预知的安全隐患，从而导致软件供应链攻击呈现上升趋势。图 7 OSS 组件实际使用数量随着时间推移不断增多3.1.1.3 重视程度不够，安全防护不足由于安全与敏捷开发往往呈对立关系，开发者为了提高效率，往往会忽视掉软件供应链的安全性，安全保障过程被孤立，实行“业务先行”的模式。然而，业务系统从设计、编码、测试到上线运行各个环节都有可能出现安全漏洞，给业务系统带来安全风险。业务系统中水平/垂直越权、批量注册、业务接口乱序调用等业务逻辑漏洞和第三方开源组件漏洞频发，高危的安全漏洞一旦被利用，可能会造成严重的信息泄露或系统中断问题。企业对软件供应链安全技术研发的投入远远不够，敏捷开发与快速迭代导致企业往往在加快开发进度的同时忽略掉部分安全隐患和响应效率，来弥补开发过程中时间的匮乏。高速运转的敏捷开发运营模式将传统的安全工作甩 163.1.2 软件供应链风险因素分析3.1.2.1 设计阶段3.1.2.2 编码阶段通过对导致软件供应链安全风险主要因素的分析，可以发现软件供应链的各环节都有可能被攻击进而产生安全风险，攻击者一旦对软件供应链中的任一环节进行攻击行为，都有可能引起软件供应链的连锁反应，进而造成严重的安全威胁，甚至危害国家网络安全。下文根据软件供应链的相关特征，针对软件生命周期主要的四阶段分析其安全风险。由于开发人员对安全认知的缺失和忽略，往往导致软件产品在功能需求、架构设计和编译的程序代码中存在天然的安全缺陷，而这些往往是无法通过后期软件开发环境加固和安全应急响应进行根本解决的。若在软件开发的设计阶段开发团队没有进行全面的威胁分析，那么很有可能因为没有充分对安全架构和设计进行验证、明确安全目标、识别相关威胁和漏洞及制定相关应对政策，从而加大软件的攻击面，造成软件开发后期需要成本高昂的补救措施。由于应用环境的复杂性，软件可能会存在许多安全漏洞和威胁，但在软件的实际应用中，并不是所有安全漏洞和威胁都会造成软件安全问题，因此，若在软件设计阶段不能识别出软件所需要重点注意的安全威胁，就不能合理的投入资源进行安全防护，从而很有可能会导致不能及时消除有可能造成安全问题的漏洞。在编码阶段，软件编译器是常见的攻击目标，若编译器被植入恶意代码，那么通过该编译器编译出的目标代码也同样会受到病毒感染。编译器在自身编译的过程中被恶意插入“后门”，那么在通过该编译器编译任何源码时都可能将后门插入到目标代码中，对代码安全造成极为恶劣的影响。开源软件已经成为软件开发人员开发代码的重要来源，所有软件开发者均参与到开源软件源代码的开发与维护中，随着开发者将自己的代码提交到开源软件平台的项目库中，这就加大了被攻击者的恶意代码感染的可能性。随着软件开发人员对开源软件的不断使用和传播扩散，一旦开源软件中存在有意或无意引入的安全缺陷，将进步影响软件供应链更多环节的安全性，同时项目集成和代码复用也会带来额外的安全风险，未对第三方代码与软件进行安全检测和审查，是软件供应链安全风险的重大隐患来源。在身后，仅在上线运行阶段开展安全风险控制工作，已无法防御由网络技术发展带来的各项安全威胁。企业软件供应链管理制度不完善，缺乏针对软件生产等重要环节的管控措施。企业软件供应链透明度不高，安全评估缺失，难以依据安全风险划分供应商的安全等级，从而进行针对性的安全管理。部分企业开源代码管理机制尚不完善，在软件开发过程中，随意使用开源组件的现象屡见不鲜，管理者和程序员无法列出完整的开源组件的使用列表，对软件供应链安全问题严重缺乏重视，给软件供应链管控带来极大的安全挑战。173.1.2.3 发布阶段3.1.2.4 运营阶段现代软件开发厂商多以敏捷开发、DevOps 开发方式为主，具有“版本迭代快、开发时间短”的特征。开发团队在版本迭代过程中占用大部分时间执行编码工作，而测试团队则往往没有充足的时间开展测试工作，更无法做到每个版本都执行安全测试。因此，错误的架构设计或程序编码因安全检测不足而未被识别，导致软件自带安全缺陷进行上线部署，并通过不断迭代集成，最终变成软件供应链的安全隐患。除此之外，在软件发布阶段我国遭受最为广泛的软件攻击手段是软件的捆绑下载。各大应用发布平台在软件应用上线前缺少对软件应用的安全审核，导致软件从上传至平台到最后的下载环节，都有被引入安全风险的可能。在软件发布的环节，许多软件厂商出于推广的需求，往往会进行捆绑安装下载，对此已形成一条完整的灰色产业链，导致用户在毫不知情的情况下，下载存在恶意代码或后门的捆绑软件。同时，对于某些软件产品来说，软件开发人员在最初编码过程中为了方便后续的修改和管理，可能会预留一些具有高级管理权限的账号，而当软件产品正式发布时由于开发人员遗忘或故意留下的“后门”，将导致软件产品在发布阶段被攻击者利用进而造成巨大的危害。软件产品在发布之后到达用户手中时，就进入了软件产品的运营阶段，而用户使用过程中，除了产品本身的安全缺陷所带来的安全威胁之外，还可能遭受用户使用环境带来的安全威胁，针对软件运营阶段最常见的攻击方式主要是软件的升级劫持。软件产品在整个软件开发生命周期中几乎都会进行更新，常见的有功能升级更新、软件缺陷更新等等。攻击者可以通过劫持软件更新的“渠道”，比如通过预先植入用户机器的病毒木马更新下载链接、运营商劫持更新下载链接、软件产品更新模块在下载过程中被劫持替换等方式对软件升级过程劫持进而植入恶意代码。在运营阶段，尤其是在更新或升级过程中，多数软件并未对软件升级过程进行严格检查，从而使攻击者有机可乘。在软件升级或更新过程中，攻击者可能通过中间人攻击替换升级软件或补丁包，或诱骗用户从非官方渠道下载，以达到网络攻击的目的。183.2.1 漏洞来源类型3.2.1.1 合法供应商引入的漏洞由于互联网信息技术产业的高速发展和软件开发需求的急速扩增，导致软件开发的难度与复杂程度不断加大，软件开发生命周期中的每一个环节都存在引入漏洞的可能性，导致软件供应链的安全风险无处不在，非法攻击者一旦对软件供应链中的任意环节进行攻击、篡改等，都将会引起最终软件供应链安全风险的连锁反应，产生巨大的安全危害。可以将软件供应链的漏洞大致分为以下几种类型进行分析（如图 8 所示）。随着开发日益全球化，大规模的软件开发导致软件供应链发生了很大的变化，其中最重要的变化是如今的软件供应链中包含引入供应商这一关键环节。全球的互联网企业现如今越来越依赖成百上千的第三方供应商、承包商等外部机构的帮助来支持完成软件生产的过程。3.2 软件供应链的漏洞类型图 8 软件供应链漏洞类型 19通常一个产品的产生需要引入一个或多个第三方供应商，企业往往需要与这些供应商之间进行数据信息共享，但这些第三方供应商的安全性通常难以得到保障，使之成为软件供应链中一个薄弱的环节，给软件供应链带来前所未有的安全威胁。一个典型的通过合法供应商引入漏洞的例子是 VxWorks 所引发的安全事件。VxWorks 是一种使用最广泛的实时操作系统，全世界范围内有超过 20 亿台设备正在使用，包括工业、电力、能源和航天航空等行业关键基础设施。多年前，网络安全公司 Armis 在 VxWorks 中发现了 11 个 0day 漏洞被称为URGENT/11，其中 6 个漏洞为严重漏洞并且可以远程执行代码，其中 5 个漏洞包含拒绝服务、信息泄露和逻辑缺陷漏洞，这些漏洞存在于 TCP/IP 网络堆栈中，允许攻击者绕过传统边界，且无需任何用户操作即可远程接管设备，包括 SCADA 设备、工业控制器、病人监护仪、MRI 机器、防火墙和打印机等关键设备。3.2.1.2 篡改或伪造组件的漏洞3.2.1.3 编码过程引入的漏洞3.2.1.4 开源组件引入的漏洞通过对近年来的网络攻击行为进行深入分析发现，恶意代码的传播和扩散占据很大的比例，尤其是伪造的恶意组件，其主要特征之一是披着正规厂商“合法”的外衣，使伪造恶意代码组件在传播速度与产生的恶劣影响方面有了大幅度的提升。伪造的组件可以使所有信任被攻击厂商证书的机构都陷入被入侵的风险，攻击者可能通过此伪造的组件绕过安全检查进而进行更大范围的攻击活动。披着“合法”外衣的伪造组件，拥有极高的隐蔽性和传播性，能在用户和开发者无感知的情况下产生巨大的安全威胁。利用伪造的组件进行软件供应链安全攻击的典型例子之一是 SolarWinds Orion 攻击事件。攻击者在成功入侵SolarWinds 后，将其官网提供的 Orion 软件安装包替换成植入后门的版本，获取正规厂商的证书并利用其对自身进行签名，使其披上“合法”的外衣，躲避官网对软件的安全检查，从而实现软件供应链攻击。随着软件已成为日常生活中不可或缺的一部分，保证底层源代码的安全性和完整性至关重要。但开发人员在编写代码时，由于缺乏安全意识以及不良的编码习惯、实践和策略往往会引入一些安全漏洞。随着软件规模的持续扩大，功能越来越复杂，编码过程引入的安全漏洞也越来越多；开发人员为了赶研发进度，很有可能会忽视自己使用的框架库中存在的安全缺陷，从而制造出潜在的安全风险，同时开发人员往往会大量复用软件模块，将导致安全漏洞不断延续。除此之外，开发人员在编码过程中为了后续的测试工作往往会留下一些具有高级权限的账号，而在后续的编码过程中故意或误将这些具有高级权限账号留下，这种情况带来的软件漏洞极有可能被攻击者利用，读取软件中重要的敏感信息。203.2.2 漏洞状态类型3.2.2.1 未知的漏洞软件供应链中未知的漏洞往往指的是 0day 漏洞，是指负责应用程序的开发人员或供应商所未知的软件缺陷，因为该漏洞未知，所以没有可以利用的补丁程序。在所有的软件漏洞中，0day 通常能够造成最大的安全风险，针对现代软件大多数是被“组装”出来的，而不是“开发”出来的。现在的软件开发过程类似于早期的工业生产活动，是以开源软件为基础原料，在此基础上，再结合实际的业务需求和应用场景补充添加相对独立的业务代码，最后“拼装”出一套软件系统。这种开发方式虽然在一定程度上提高了软件系统开发的效率，却并未充分考虑其使用的基础开源组件是否安全可靠，为软件系统的安全性和可控性带来了巨大的安全挑战。随着开源技术快速形成生态，开源热度的持续升高，企业引入开源软件已成为一种趋势。Sonatype 发布的2020 State of the Software Supply Chain报告中提到现代应用程序中 90%的组件都是开源的（如图 9 所示），其中11%的开源组件中存在已知的安全漏洞。随着开源组件使用的增加，风险面