今天，软件供应链攻击已经成为突破业务防线的新方式之一。在近年来的重大安全事件和实战攻防演练中，软件供应链攻击事件频频出现。2020年12月，基础网络管理软件提供商SolarWinds遭遇软件供应链攻击。不仅是SolarWinds服务的科技公司，还有它服务的一大批制造企业。随着时间的推移，此次供应链攻击波及范围广泛，包括政府部门、关键基础设施，以及多家世界500强企业。事故发生后的一个月内，SolarWinds的股价下跌了50%。2021年12月，Apache开源项目Log4j暴露核弹级漏洞，攻击者仅需一段代码即可远程控制目标服务器。由于Log4j广泛应用于中间件、开发框架、Web应用，而这些中间件和开发框架又被其他软件系统作为软件基础，??因此Log4j在各大软件系统中的应用极为广泛。利用该漏洞攻击软件供应链造成的严重性和影响将在2021年最高。此外，Linux“脏管”事件，年均下载量超过700万的热门JavaScript库ua-parser账号周接手后，依赖混乱影响多家大厂，PHP源码事件频发。.据Sonatype称，供应链攻击比去年增加了430%。这股冷水已经让大部分开发者意识到他们的软件供应链存在严重的安全问题。在过去的几十年里，大大小小的公司都专注于软件构建及其各自的生产环境。虽然基础设施做得很好，但攻击者找到了更简单的方法，即从开放供应链入手。从大门进入。事实上，软件供应链中的安全风险防控并非易事。最大的挑战在于供应链的复杂性。那么，软件供应链安全治理应该怎么做呢？软件供应链安全的复杂性所谓软件供应链攻击，顾名思义，就是针对软件供应链发起的网络攻击。攻击者会先攻击软件供应链中安全防护相对薄弱的环节，然后利用软件供应链中企业间的互联互通（如软件供应、开源应用）等，将风险向上下游扩大企业，这将对大量供应商和最终用户产生巨大影响。与其他形式的攻击相比，软件供应链攻击往往具有“一根头发，牵一发而动全身”的效果。因此，仅仅保护软件供应链中单个环节的安全是远远不够的。需要从供应过程和软件本身的安全性入手。根据软件供应链的特点，可以将软件供应链的业务流程抽象为开发、交付和应用三个环节。开发环节主要是指软件开发商的程序员根据用户（包括定制用户）的需要，对软件包进行编程并完成提供的过程。这个过程主要涉及到用户需求、编程语言、开发环境、开发框架、测试打包等，现阶段还没有统一的安全测试发布渠道，大部分工具都是不经测试直接发布；工具和库通常由商业公司或个人开发，由于代码的复杂性，程序员往往基于易用性来开发唯一的支撑标准，缺乏安全意识。因此在开发阶段存在病毒感染的可能，导致开发的功能模块默认感染病毒。同时，在源代码打包或开发过程中，功能模块的后门保留给程序开发环境和后续使用环境带来了安全隐患。另外，程序开发环境一般都属于核心区。一旦程序员下载了不安全的工具，就可能直接导致整体编程环境的重大安全隐患。所有进出该环境的代码都可能存在泄露、篡改等风险。软件测试也是如此。如果源码测试打包工具有恶意代码感染，可能会感染整个测试环境；测试人员没有安全意识，测试计算机在不安全的环境中运行，会带来二次感染。交付环节主要是指开发者或推广者通过互联网网站、网上商城、社交工具、网盘或存储介质将开发或定制的软件交付给最终用户。在发布渠道方面，目前主流的软件发布渠道缺乏有效监管，应用发布者缺乏对软件发布的安全审计；从上传到下载传输通道、存储、发布等通道。维度篡改行为导致通道风险；非官方发布平台直接发布或被篡改植入恶意代码，造成感染。在发布下载方面，软件厂商往往为了推广目的而捆绑安装自己的软件，形成了完整的灰色产业链，缺乏对捆绑软件的审核机制。同时，域名劫持（DNS）、内容分发系统（CDN）缓存节点篡改等常见事物，导致用户在不知情的情况下下载带有恶意代码或后门的软件。应用环节主要是指最终用户对软件产品的使用，包括下载、安装、注册、付费、使用、故障修复、升级、卸载的全过程。在安装方面，安装源本身可能存在隐患，安装时往往会使用脚本安装工具来执行，但安装工具的出现无疑增加了整个供应链的安全性。在升级方面，升级包是对原有软件进行升级的代码包。未经认证的升级包存在一定的安全隐患；官方厂商和第三方非认证机构往往会通过自己的渠道发布补丁包，大多数终端用户不会被区分、下载和安装。在卸载方面，官方应用往往会在应用中嵌入卸载工具，但对于某些应用，由于卸载不便且容易残留，提供的第三方卸载工具也存在安全隐患。软件供应链安全治理框架推进为了应对不断升级的软件供应链安全威胁，业界逐渐推出软件供应链安全治理框架。最著名的是谷歌的软件供应链安全框架SLSA，这是一个端到端的框架，用于确保整个软件供应链中软件工件的完整性。SLSA由Google的内部“BorgBinaryAuthorization”(BAB)领导——Google已经使用该流程八年来验证代码来源并实现代码身份。SLSA希望锁定软件开发链中的一切，从开发人员到源代码、开发平台和CI/CD系统，以及包存储库和依赖项。由CNCF基金会主办的in-toto项目也是一个通过收集和验证相关数据来保护软件供应链的框架。它通过使图书馆能够收集有关软件供应链行为的信息，并允许软件消费者和项目经理发布有关软件供应链实践的政策来实现这一点，这些政策可以在部署或安装软件之前进行验证。简而言之，它有助于捕获软件供应链中正在发生的事情，并确保它根据定义的策略发生。在国内，信通院也在协助企业进行软件全生命周期的安全管控，以保障全链路安全为目标，建立一系列软件供应链安全标准体系，并实施评估测试。中国信息通信研究院认为，对于软件供应链的安全保障过程，可以分为三个阶段：软件供应链入口（内部引入）、自主开发（自主开发应用）、和出口（外部供应）。、软件资产管理、服务支撑、安全应急响应等多个维度，规范软件供应链安全保障能力，构建软件供应链安全模型。在实施实践方面，中国信息通信研究院率先制定了安全工具研究和运营的标准体系，包括：静态应用安全测试工具（SAST）、交互式应用安全测试工具（IAST）、软件组成分析工具（SCA）、应用程序运行时自我保护系统（RASP）、软件物料清单构建通用框架（SBOM）等多项标准。事实上，要做好软件供应链的安全工作，不仅需要在软件生命周期的各个阶段在安全技术和工具方面实施安全防护，形成开发和运营的闭环安全，还要从多角度考虑组织文化和安全开发流程。考虑，不断优化流程实践以创造更安全的环境。全球软件供应链安全政策软件供应链安全是一个全球性问题，其根源在于软件行业全球化、市场化、模块化的特点。为了防止SolarWinds、Log4j等事件再次发生，全球多个国家的法律法规都在提高对供应链安全的管控要求。近期，美国和欧盟都出台了新的供应链安全相关要求法律，要求制造商对供应链数字产品的安全性进行评估。美国和欧盟都在各自的法案中提到了软件安全测试和软件材料清单（SBOM），这意味着通过强制性的网络安全法规，企业必须通过公开SBOM和源代码安全测试来改进数字产品。安全是继续正常销售和提供数字产品的唯一途径。美国白宫9月14日发布了名为《通过安全的软件开发实践增强软件供应链的安全性》的备忘录，要求供应商为其产品提供安全自我认证。自我认证是指开发人员必须提供的文档，以证明符合安全软件开发框架。此外，美国政府还发布了《ICT供应链风险管理标准》（NISTSP800-161）、商业信息技术软件和固件审查项目（VET）等，明确了涉及存储、检索、修改、传输和服务的相关标准。软件供应链在一定程度上避免了软件供应链面临的诸多风险。欧盟于9月15日发布了名为（网络弹性法案）的草案，旨在为联网设备制定通用的网络安全标准。该法案要求所有出口到欧洲的数字产品必须提供安全保证、软件物料清单（SBOM）、漏洞报告机制，并提供安全补丁和更新。违反规定的公司将面临高达1500万欧元或全球收入的2.5%的罚款。我国近年来出台了《中华人民共和国网络安全法》、《网络安全审查办法》、《中华人民共和国国民经济和社会发展第十四个五年规划和 2035 年远景目标纲要》、《关键信息基础设施安全保护条例》等政策法规，都强调加强软件供应链的安全保障。在标准制定方面，我国颁布了国家供应链安全管理标准《信息安全技术ICT供应链安全风险管理指南》（GB/T36637-2018），从产品全生命周期的角度进行风险分析和管理，实现供应链完整性、机密性、可用性和可控性安全目标。全国信息安全标准化技术委员会归口的国家标准《信息安全技术软件供应链安全要求》已形成标准征求意见稿，规定了信息技术产品供需双方应满足的供应链基本安全要求。虽然国内对软件供应链安全的认识落后于国外，但随着国内技术的发展和安全意识的觉醒，很快就会迎头赶上。结语开源技术的应用、复杂的国际形势、软件供应链的多元化、供应链各环节的攻击急剧上升，已成为网络安全的主要威胁。要想做好软件供应链的安全治理，就需要进行一场“团队竞赛”。整个开源生态角色将在供应链的每个环节建立一系列的安全指南和最佳实践，有效保障整个网络空间的安全。
