如今，软件供应链攻击已成为突破业务防线的新路径之一。在近几年的重大安全事件、实战攻防演练中，已频现软件供应链攻击的身影。

2020年12月，基础网络管理软件供应商SolarWinds遭遇软件供应链攻击，受到攻击的不仅是SolarWinds服务的多家科技公司，还有其服务的大量制造业公司。随着时间的推移，此次供应链攻击事件波及范围极大，包括政府部门、关键基础设施以及多家全球500强企业。

事故发生后的1个月，SolarWinds的股价下跌了50％。2021年12月，Apache开源项目Log4j爆出核弹级漏洞，攻击者仅需一段代码就可以远程控制目标服务器。

由于Log4j被广泛地应用在中间件、开发框架、Web应用中，而这些中间件和开发框架作为软件基础又被其他软件系统使用，因此Log4j被极其广泛的应用在各大软件系统里面。利用此漏洞进行软件供应链攻击造成的严重性、影响面，堪称2021年之最。

除此之外，Linux“脏管道”事件、周下载量超过700万次的JavaScript流行库ua－parser 账户遭接管、影响多家大厂的依赖混淆、PHP源代码事件等供应链安全事件频发。

据Sonatype公司的调查，供应链攻击行为比去年增加了430％。这盆冷水让大多数开发人员意识到，他们的软件供应链有严重的安全问题。

过去几十年，大大小的公司都把注意力聚焦在软件构建和各自的生产环境上，虽然在基础设施方面做得非常好，但攻击者却到了更简单的方法，即从敞开的供应链大门中进入。

事实上，软件供应链安全风险防控并不容易，最大的挑战就在于供应链的复杂性。那么，软件供应链安全治理到底该如何做？

软件供应链安全的复杂性

所谓软件供应链攻击，顾名思义，指的就是针对软件供应链所发动的网络攻击，攻击者会先攻击软件供应链中安全防护相对薄弱的部分，然后再利用软件供应链之间的相互连接（如软件供应、开源应用）等，将风险扩大至上下游企业，对大量的供应商和最终用户带来巨大影响。

与其它攻击形式相比，软件供应链攻击往往会产生“牵一发而动全身”的效果。因此，仅仅对软件供应链某个单一环节进行安全防护是远远不够的，需要从其供应过程和软件自身安全出发。

根据软件供应链的特点，软件供应链的业务流程可以抽象成开发、交付以及应用三个环节。

开发环节

主要是指软件开发商的编程人员根据用户（含定制用户）的需求，进行编程并完成软件包提供的过程。该过程主要涉及用户需求、编程语言、开发环境、开发框架、测试和封包等。

在这个阶段，尚未有统一的、经过安全检验的发布渠道，多数工具未经检测直接发布；工具及库通常由商业公司或个人开发，因代码复杂，编程人员往往依据将易用性作为选择开发配套的唯一标准，缺乏安全的意识。

因此，在开发阶段存在被病毒污染的可能，导致开发出的功能模块默认感染病毒。同时，在进行源代码打包或开发过程中，对功能模块进行后门留存，给程序的开发环境以及后续的使用环境，都带来了安全隐患。

此外，程序开发环境一般属于核心区域，一旦编程人员下载了不安全的工具，则可能直接导致整体编程环境出现重大安全隐患，所有从该环境出入的代码，都可能存在泄密、篡改等风险。在软件测试环节也是如此。

如果进行源代码测试、封包的工具存在恶意代码感染，则可能感染整体测试环境；测试人员不具备安全意识，测试电脑在不安全的环境进行操作，则带来次生感染。

交付环节

主要是指开发商或者推广商通过互联网网站、在线商城、社交工具、在线网盘或者通过存储介质，将开发或定制的软件交付给最终用户。

在发布渠道方面，目前主流的软件发布渠道缺乏有效的监管，各应用发布商缺乏对软件发布的安全审核；从应用在上传至渠道用于下载的传输途径、存储、发布等环节，易发生多维度的篡改行为，导致渠道风险的发生；非官方发布平台直接发布或被篡改并植入恶意代码，造成感染。

在发布下载方面，软件厂商出于推广需要，多数软件往往会对自有软件进行捆绑安装，已形成了完整的灰色产业链，缺乏对捆绑软件的审核机制。同时，常见如域名劫持（DNS）、内容分发系统（CDN）缓存节点篡改等，导致用户在不知情的情况下，下载存在恶意代码或后门的软件。

应用环节

主要是指最终用户使用该软件产品，包括下载、安装、注册、付费、使用、故障修复、升级、卸载等全部过程。

在安装方面，安装源自身可能存在隐患，安装时往往会配套一个脚本安装工具代为执行，但是安装工具的出现无疑会增加整体使用供应链的安全。

在升级方面，升级包是对原软件进行升级的代码包，未经认证的升级包存在一定的安全风险；官方厂商以及第三方非认证组织往往会通过自身渠道进行补丁包发布，终端用户多数不会进行分辨，下载即安装。

在卸载方面，官方应用往往会将卸载工具内嵌至应用中，但是对于部分应用由于其卸载不便，且容易残留，提供的第三方卸载工具，也会存在安全隐患。

软件供应链安全

治理框架的推进

为了应对不断升级的软件供应链安全威胁，业界已经在逐步推出软件供应链安全框架。

最为知名的莫过于Google的软件供应链安全框架SLSA，用于确保整个软件供应链中软件工件完整性的端到端框架。

SLSA以Google内部的“Borg二进制授权”（BAB）为主导——Google八年来一直使用这一流程来验证代码出处和实现代码身份。

SLSA希望锁定软件开发链中的所有内容，从开发人员到源代码、开发平台和CI／CD系统、以及包存储库和依赖项。

CNCF基金会托管的in－toto项目，也是一个通过收集和验证相关数据来保护软件供应链的框架。

它通过使库能够收集关于软件供应链行为的信息，并允许软件消费者和项目经理发布关于软件供应链实践的政策来做到这一点，这些政策可以在部署或安装软件之前进行验证。

简而言之，它有助于捕获软件供应链中发生的事情，并确保它按照定义的策略发生。

在国内，中国信通院也在助力企业针对软件全生命周期进行安全管控，以全链路安全保障为目标，建立了一系列软件供应链安全标准体系，并落地评估测试。

中国信通院认为，针对软件供应链安全保障流程，可划分为软件供应链入口（对内引入）、自身（自研应用）、出口（对外供给）三大阶段，应从软件来源、软件安全合规、软件资产管理、服务支持、安全应急响应多个维度，对软件供应链安全保障能力进行规范，搭建软件供应链安全模型。

在落地实践方面，中国信通院已牵头制定了研运安全工具标准体系，包括：静态应用程序安全测试工具（SAST）、交互式应用程序安全测试工具（IAST）、软件组成分析工具（SCA）、应用运行时自我保护系统（RASP）、软件物料清单建设总体框架（SBOM）等多项标准。

事实上，要做好软件供应链安全，不仅要在安全技术及工具上对软件全生命周期的每个阶段进行安全防护，形成开发运营安全闭环，还要从组织文化、安全开发流程等多角度考虑，不断优化流程实践，以建立更安全的环境。

       软件供应链安全的全球性政策

软件供应链安全是一个全球性问题，究其根本，是由于软件行业全球化、市场化、模块化的特点。为了防止诸如SolarWinds、Log4j等事件的再次发生，全球多国法规都在提升对供应链安全的管控要求。

近期，美国和欧盟都发布了新的供应链安全相关要求法案，要求厂商评估供应链数字化产品的安全性。

美国和欧盟在各自的法案都提到了软件安全检测，软件物料清单（SBOM）等内容，这意味着通过强制性的网络安全法规要求，企业必须通过披露SBOM、源代码安全检测等手段提升数字化产品安全性，才能继续正常地销售提供数字化产品。

美国白宫在9月14日发布了题为《通过安全的软件开发实践增强软件供应链的安全性》的备忘录，要求供应商产品需提供安全自我证明。自我证明是指开发人员必须提供以证明其符合安全软件开发框架的文档。

此外，美国政府还发布了《ICT供应链风险管理标准》（NIST SP800－161）、商用信息技术软件及固件审查项目（VET）等，清楚界定了软件供应链中涉及存储、检索、修改、传输以及服务的相关标准与要求，在一定程度上规避了软件供应链面临的诸多风险。

欧盟在9月15日发布了题为《网络弹性法案》（Cyber Resilience Act）的草案，旨在为联网设备制定通用网络安全标准。法案要求所有出口欧洲的数字化产品都必须提供安全保障、软件物料清单SBOM、漏洞报告机制，以及提供安全补丁和更新。

违反规定的公司将面临最高1500万欧元或全球营收2．5％的罚款。在中国，近年来先后颁布的《中华人民共和国网络安全法》、《网络安全审查办法》、《中华人民共和国国民经济和社会发展第十四个五年规划和 2035 年远景目标纲要》、《关键信息基础设施安全保护条例》等政策法规，都强调加强软件供应链的安全保障。

在标准制定方面，我国出台了供应链安全管理国家标准《信息安全技术ICT供应链安全风险管理指南》（GB／T 36637－2018），从产品全生命周期的角度开展风险分析及管理，以实现供应链的完整性、保密性、可用性和可控性安全目标。

全国信息安全标准化技术委员会归口的国家标准《信息安全技术软件供应链安全要求》已形成标准征求意见稿，规定了信息技术产品供应方和需求方应满足的供应链基本安全要求。

尽管国内对软件供应链安全的重视认知稍微滞后于国外，但随着国内技术的发展和安全意识觉醒，很快就能追赶上来。

结语

开源技术应用、国际形势复杂、软件供应链的多样化，供应链各个环节的攻击急剧上升，已然成为网络主要的安全成胁。想要做好软件供应链安全治理，需要打好“团体赛”，由整个开源生态角色在供应链的各个环节，建立一系列的安全准则和最佳实践，切实保障整个网络空间的安全。

【科技云报道原创】

转载请注明“科技云报道”并附本文链接

       原文标题 : 软件供应链安全治理需打好“团体赛”