软件供应链安全日益成为业界高度重视的问题，各方都在积极探索软件供应链安全治理模式。近期，Scantist联合创始人—新加坡南洋理工大学刘杨教授带领的课题组参与浙江大学软件供应链安全课题组相关项目并联合研发了一套软件供应链安全分析系统，刘杨教授也为研究成果提出了建议及具有国际视野的洞见，并且根据行业需求提供了多方面支持，旨在全方位为行业综合赋能，助力提升软件供应链安全管理水平。

刘杨博士现任新加坡南洋理工大学（NTU）全职教授，NTU网络安全实验室主任，新加坡国家卓越可信软件科研中心副主任，新加坡国家网络安全研发技术审查委员会成员。在NTU网络安全实验室，刘杨教授负责学术研究和工业界的合作。科研方面，刘杨教授也一直从事网络安全、软件工程、人工智能等方面的研究工作，在专业领域权威性高，技术积累深厚。

得益于NTU网络安全实验室最前沿的技术研究和转化成果，Scantist在其孵化和落地应用的基础上，在解决方案创新层面上始终保持先进性，这也进一步构成了Scantist软件成分分析（SCA）工具、开源治理平台、以及应用安全测试工具等一系列产品链的核心竞争力。

本次我们转发的文章源自"浙大网安"公众号《软件供应链安全（一）：Java语言生态漏洞影响力与修复分析》，供技术同仁们及相关企业参考，也欢迎大家与Scantist团队交流各类研究心得及技术干货，一起从科研创新走向实践应用。

1、引言

近年来，软件供应链安全事件呈现快速增长态势，在软件生命周期的各个环节、软件系统的各个层次上都可能发生。因此，软件供应链已成为网络空间攻防对抗的焦点，直接影响到国家关键基础设施和重要信息系统安全。据Sonatype统计公布，2021年软件供应链安全事件发生1.2万起，同比增长高达650%，29%的流行项目中至少包含一个已知的安全漏洞。特别是最近公开的Apache Log4j2漏洞和Spring Framework漏洞，因为危害性高、波及范围广，对整个Java生态产生了巨大的危害。

以守护软件供应链安全为己任，任奎教授领导的浙江大学软件供应链安全课题组联合南洋理工大学刘杨教授课题组，设计、研发了一套软件供应链安全分析系统（名为“涅槃”），包含以下三个子系统：

● 集：大规模增量式组件收集；

● 析：多层次高精度依赖分析；

● 警：实时漏洞分析与预警。

“涅槃”系统涵盖了多种语言生态的供应链安全分析，提出了系统化的数据聚合、抽象和提取方法，定义了组件影响力和漏洞传播能力评价指标，实现了高精度的组件依赖分析和新型数据聚合展示技术，从而达到对多种语言生态软件供应链的全景分析，对漏洞传播和影响力的量化分析，以及对漏洞修复精准追踪和分析的目的。“涅槃”系统为漏洞影响力评价、安全预警、修复优先级提供了依据，为软件供应链安全防护指明了重点方向，对提升整个生态软件供应链安全具有重要意义。

2、Java语言生态分析

针对Java语言生态分析，“涅槃”系统中建立了一个覆盖全部Java组件的依赖关系图谱（如图1所示），包含超过880万个组件版本和6500万条依赖关系。基于此图谱，“涅槃”进一步分析得出：

● 在Java语言生态中，软件供应链依赖高度集中，Top 5的组件被超过60%的Java组件所依赖，其安全问题会对整个生态造成灾难性后果。

● Apache Log4j2和Spring Framework这两个漏洞对Java组件的影响比例分别是15%和18%。截止到2022年5月份，其修复比例分别是29%和15%。尽管目前对这两个漏洞已有不少的曝光，但修复比例较低，仍需引起重视。

● 在Apache Log4j2漏洞的传播过程中，Netty-common，Netty-buffer，Netty-transport等组件是扩散的关键节点，而对于Spring Framework漏洞，Spring-beans，Spring-context，Spring-expression等组件进一步扩大了漏洞的传播范围。

生态全景展示

“涅槃”系统分析了Java默认包管理器Maven的所有组件信息（包含全部880万个组件版本，以及各个组件版本间的依赖关系6500万条），绘制了Java生态全景依赖图谱。

图1 Java生态组件依赖网全景图

如图1所示，其中每个节点代表一个Java组件，每条边代表两个组件间的依赖关系，每种颜色代表一种组件以及受其影响的依赖。该图能够直观地展现整个Java语言生态的全貌，以及Top 10组件依赖关系网的分布。从图中可以看出，在Java生态中，被广泛依赖的组件还有Scala-library、Slf4j-api和Guava等，这些组件具有更大的生态影响力，一旦曝出漏洞，将会产生比Apache Log4j2和Spring Framework漏洞更严重的影响。

直接影响力

“涅槃”系统中将组件依赖关系中的直接依赖定义为“直接影响力”，以直接依赖的组件数量为依据绘制了图2。

图2 Java生态直接影响力Top50组件及其依赖关系

图2所示为Java语言生态中被其他组件依赖数量最多的Top50组件及其依赖关系，最近两次影响巨大的软件供应链漏洞攻击事件所涉及到的Log4j-core排名29位（黄色），Spring-core组件排名33位（蓝色）。此外，从上图中可以看出:

● Top组件之间互相存在依赖关系，例如Guava组件依赖于热门组件Jsr305，同时又被热门组件Guice依赖;

● Top组件之间形成了依赖群体，意味着一旦在这些Top组件中发现漏洞，漏洞的传播存在放大效应，使传播范围更广，影响力更大。

3、漏洞传播与修复分析

“涅槃”系统不仅能够正向推理语言生态中的依赖关系形成知识图谱，还能够反向追溯漏洞在软件供应链上的传播，并且可以精确到传播中的关键组件、版本以及传播层级，这对于研究漏洞在软件供应链中的传播态势、传播特点以及如何在关键节点上进行漏洞阻断和修复具有重要的意义。下文以Log4j2和Spring两个漏洞为例展示分析结果。

层级影响力

“涅槃”系统中将组件依赖关系（包含直接依赖和间接依赖）以传播距离进行分层抽象，定义了“层级影响力”，并对所有版本的直接依赖和间接依赖关系进行提取，从根节点开始自上而下逐层分析，清晰呈现了每一级的组件版本数和逐层变化的层级影响力。

图3 Log4j-core组件层级依赖图

图4 Spring-core组件层级依赖图

图3、图4分别展示了Log4j和Spring的组件层级依赖。从图中可以看出：

● Log4j和Spring组件影响超过百万组件版本，影响范围较广；

● 大多数依赖都集中于五层以内，说明对Log4j和Spring组件的引用层次较浅，代码路径短，因此二者曝出的漏洞极易被触发；

● 由于浅层依赖较多，有利于漏洞修复，当部分组件漏洞修复之后，其余组件可以灵活地进行依赖调整，选择最新版本进行漏洞规避。

传播影响力

“涅槃”系统把组件所辐射到的直接和间接依赖的组件、版本数量定义为“传播影响力”。

图5 Log4j-core依赖组件传播影响力分布图

图6 Spring-core依赖组件传播影响力分布图

图5、图6分别展示了Log4j和Spring的组件依赖传播影响力分布图，其中标明了传播影响力排名前30的组件名称。从图5、图6可以看出：

● 在依赖Log4j-core的组件中，影响力权重最大的前三个组件是Netty-common，Netty-buffer，Netty-transport。

● 在依赖Spring-core的组件中，影响力权重最大的前三个组件是Spring-beans，Spring-context，Spring-expression。

● 权重较大的组件之间存在相互依赖，组成了重要的传播链，进一步扩大了漏洞的传播影响力。

● 传播影响力排名靠前的关键组件是进一步扩大漏洞传播影响力的关键所在，其修复状态在生态中也至关重要。

修复全景展示

“涅槃”统计了截止到2022年5月份Log4j-core漏洞传播影响力覆盖到的所有依赖数据，从中筛选出各组件的最新版本及其依赖路径，共计超过8万个节点和10万条边，并对Lo4j-core的53个版本分别着色，形成了Log4j-core最新组件依赖网修复全景图，如图7所示。

图7 Log4j-core最新组件依赖网修复全景图

图中漏洞未修复版本用暖色系（红、黄、橙、紫等）表示，漏洞已修复的版本以冷色系（青、蓝、绿等）表示。可以明显看到，整个软件供应链中依然有大量的组件未被修复。而在已修复版本中，log4j-core@2.17.1版本被依赖组件数量最多，这是由于漏洞曝光之后，发布了一系列修复版本，但又都引入了新的漏洞，直到2.17.1版本漏洞才完全被修复，所以被多数其他组件所依赖。

图8 Spring-core最新组件依赖网修复全景图

“涅槃”系统对Spring漏洞的修复现状也做了同样的统计分析，如图8所示，共计9.7万个节点和16万条边，覆盖了Spring-core的全部版本。图中冷色系（青、蓝、绿等）表示已修复版本，只有少量显示，可见由于Spring漏洞爆发时间尚短，目前整个Spring-core软件供应链中大部分组件仍未被修复。

修复比例分析

为了直观地展示漏洞的修复速度，“涅槃”统计了从2021年12月10日至2022年5月5日所有直接依赖于Log4j-core各个版本的最新组件数量的动态变化，计算出了各个时期直接依赖组件的修复比例，如图9所示。其中，红色系为受漏洞影响的版本，绿色系为修复版本，从动图中可以看出，红色系版本的比例不断缩小，尝试修复漏洞的绿色系版本不断增加，截至今年5月5日，修复版本占总体直接依赖数量比例为29%，依然有71%的直接依赖未被修复。

图9 Log4j-core直接依赖组件修复比例变化动图

由于Spring版本众多，“涅槃”将部分版本分区间进行了合并，统计了从2022年3月29日至5月5日之间，所有直接依赖于Spring-core各个版本的最新组件数量的动态变化，计算出各个时期直接依赖组件的修复比例，如图10所示。截至今年5月5日，修复版本占总体直接依赖数量比例已经达到了15%，说明软件供应链安全日益被开发者所关注，在漏洞发生之后很短时间就能迅速作出修复，但依然有85%的依赖未进行修复。

图10 Spring-core直接依赖组件修复比例变化动图