奇安信发布《2022中国软件供应链安全分析报告》 谁会成为下一个Log4j2？

7月26日，奇安信集团对外发布了《2022中国软件供应链安全分析报告》（简称《报告》），对过去一年多来国内软件供应链各个环节的安全形势，进行了深入细致的分析。

《报告》指出，尽管“Log4Shell”漏洞造成了空前的影响，但关键基础开源软件仍然没有引起足够的重视，我们应通过该漏洞事件举一反三，对类似Log4j2这样的关键基础开源软件进行系统化梳理，从基础底座层面进行漏洞排查和加固，针对性采取更强的安全防护措施。

《报告》显示，与前一年度相比，企业自主研发源代码安全缺陷情况有明显改善，千行代码缺陷密度和十类典型安全缺陷的总体检出率均有明显下降,这应该得益于软件源代码安全缺陷分析工具的持续应用，以及程序员编写代码时的安全意识提高。但开源软件安全风险仍然居高不下，开源软件的安全风险管控是当前软件供应链安全保障需要解决的核心焦点问题。

开源软件安全形势严峻已成软件供应链安全的焦点

据奇安信代码安全实验室监测发现，2020年底和2021年底，主流开源软件包生态系统中开源项目总量分别为3814194个和4395386个，一年间增长了15.2%，开源生态依然保持蓬勃发展的态势。

与此同时，开源软件漏洞数量持续增长，2021年新增的开源软件漏洞达到6346个。2021年全年，“奇安信开源项目检测计划”对1780个开源软件项目的源代码进行了安全检测，共发现安全缺陷2648242个，其中高危缺陷162959个。整体缺陷密度为16.11个/千行，高危缺陷密度为0.99个/千行，均高于前一年度报告的14.96个/千行和0.95个/千行。

另一方面，奇安信代码安全实验室对3354个国内企业软件项目中使用开源软件的情况进行了分析。分析结果显示，平均每个项目使用了127个开源软件，存在已知开源软件漏洞的项目占比86.4%，其中存在容易利用的漏洞的项目有2581个，占比高达77.0%。平均每个项目存在69个已知开源软件漏洞，略高于前一年度的66个，最多的软件项目存在1555个已知开源软件漏洞。十类典型缺陷的总体检出率为73.5%，远高于去年的56.3%。

值得关注的是，在所有被检出的漏洞中，最古老的漏洞是2005年8月公开的CVE-2005-2541，仍然存在于13个项目中。在开源项目版本管理方面，20年前的老旧开源软件版本仍然在使用，同一开源软件各版本的使用相比于前一年度更加混乱，存在大量版本混用的情况，最多的开源软件有235个版本在使用，从而进一步加剧了开源项目的整体安全风险。

《报告》指出，从数据分析情况来看，国内企业使用开源软件时的安全风险问题没有得到改善，开源软件安全风险是当前企业软件开发中亟待解决的首要问题。

防范下一个Log4j2

“关键基础开源软件”需被重点关注

在开源生态中，有一些开源软件的地位非常重要，它们被众多开源软件所依赖，被广泛地使用在各种软件系统之中，这些开源软件可以说是现代软件开发的核心基础设施和底座，《报告》将其称为“关键基础开源软件”。

因为“Log4Shell”漏洞(漏洞编号：CVE-2021-44228)而被更多人熟知的Apache Log4j2就是关键基础开源软件中的一员。作为目前最为流行的开源日志组件之一，Apache Log4j2等关键基础开源软件一旦出现漏洞，其放大效应非常显著，影响范围巨大且难以消除。

《报告》使用了直接依赖该软件的开源组件数量，作为开源软件重要性度量的指标，并且基于经验参考将直接依赖数大于1000的开源软件定义为关键基础开源软件。直接依赖数越大的开源软件出现漏洞后，造成的放大效应越大，影响的范围越广。

奇安信代码安全实验室分析发现，Maven、NPM、Nuget、Pypi、Packagist、Rubygems等主流开源生态中直接依赖数大于1000的开源软件共有1068款，开源软件junit:junit的直接依赖数高达95614，排名第一，大名鼎鼎的Apache Log4j2并没有出现在TOP50中，其直接依赖数为7233，排在第103名。下表为报告发布的关键基础开源软件TOP15（完整 TOP50见报告全文）。

从漏洞放大效应的角度来看，如果TOP50里的任何一款开源软件曝出严重漏洞，其影响可能都会大过Apache Log4j2 的“Log4Shell”漏洞。因此，《报告》认为，关键基础开源软件的安全现状不容乐观，防范出现下一个Log4j2，需要未雨绸缪，关键基础开源软件需要被重点关注。

保障软件供应链安全

软件物料清单（SBOM）应成为软件产品标配

尽管在过去的一年里，软件供应链安全的重要性已经逐步成为各方共识。但国内大多数机构和企业目前对于软件供应链安全还处于了解和保持关注阶段，尚未付诸真正的行动。从《报告》中国内企业软件开发项目的实测数据来看，软件供应链安全相关风险很高，形势严峻且紧迫。

《报告》认为，软件组成成分的透明性是软件供应链安全保障的基础，建议将软件物料清单（SBOM）作为软件供应链安全的抓手首先推进落地，通过软件物料清单（SBOM）的推广应用，牵引软件供应链上下游各个环节的协同。奇安信代码实验室给出的具体建议如下：

在国家与行业监管层面，提高关键基础设施和重要信息系统用户软件供应链安全保障的要求，要求向关键基础设施和重要信息系统用户销售软件产品、提供软件定制开发的厂商和供应商，在交付软件系统的同时，需提供软件物料清单（SBOM），以保持足够的透明性；组织制定软件物料清单（SBOM）相关的国家标准、行业标准，规范针对软件物料清单（SBOM）的格式和内容要求，促进软件物料清单（SBOM）成为软件产品的标配；建立相应的公共服务平台，提供软件物料清单（SBOM）的检测验证、数据查询、威胁情报等服务。

针对软件厂商和供应商层面，建议在自身软件开发流程中采用开源安全治理工具，持续监测软件开发中所使用的开源软件物料，消减其安全风险；产品正式发布时，应提取和生成产品的软件物料清单（SBOM），并随软件向客户提供；针对自身软件产品中所使用的软件物料，持续监测其安全漏洞等风险情况，并及时为客户提供相应的技术支持服务。

在软件最终用户层面，建议保持对软件物料透明性的高度关注，在购买软件产品或委托定制开发软件系统时，要求厂商和供应商提软件物料清单（SBOM），并与其签订安全责任协议，要求其对软件物料的安全性负责并提供后续的技术支持服务；对于运行重要业务的软件系统，应使用合适的检测工具验证厂商和供应商所提供的软件物料清单（SBOM）的正确性，确认软件的组成成分及安全风险状况；在软件系统日常运行过程中，应基于软件物料清单（SBOM）持续跟踪软件物料相关的威胁情报，及时采取安全措施，消减相关安全风险。