前言
Log4j2作为java代码项目中广泛使用的开源日志组件，它的一个严重安全漏洞对于全球的软件供应链生态来讲不亚于一场新冠病毒的影响，任何企业的代码项目沾上它都有可能给企业带来致命的安全风险。
全球新一轮的产业数字化升级对开源软件的依赖日益提升，从而催生开源生态的蓬勃发展，而开源软件的全球化和开放共享的特性使得任何一个非常底层和基础的开源组件的漏洞都有可能像一个新冠病毒一样快速传播，对全球的数字化产业带来无法估量的影响。而这种影响的持续时间可能是3～5年，甚至更长。
比新冠病毒更可怕的是，像Log4j2这样的基础组件其实还有很多，它们出现安全漏洞的概率可远远要比新冠病毒的概率要高的多。
我们来看一组数据：
- Log4j2的依赖血缘：我们统计了1～4层的依赖血缘关系，直接和间接Log4j2的开源组件总计有17万个，也就是说有至少17万个开源组件是受Log4j2漏洞影响。
- GitHub作为全球最大的开源代码托管平台，抽样分析发现至少5.8%的java开源项目受该漏洞影响。
- 截止目前，距离官方第一次发布修复版本已近一周时间，GitHub上还有89%的受影响项目仍然没有修复。
- 在java语言的开源组件流行度排行中，Log4j2列第13位，也就意味着至少存在几十个这样的高影响度组件，一旦爆发漏洞，实际带来的影响都是类似的。
这样一组数据背后意味的是什么？是失控。这样的失控让我们不禁要思考，全球开源软件供应链生态风险控制体系是严重缺失的，开源软件蓬勃发展的背后似乎潜藏着巨大的危机，从软件供应链的生产商、分发平台、企业应用方其实都缺乏足够的风险意识和控制能力，这无疑会给企业和企业用户的信息安全带来非常大的潜在风险。
一、关于Log4j2漏洞对开源生态的影响分析
1.其他开源组件的依赖
我们对log4j2的1～4层依赖关系进行了统计分析，可以发现直接依赖log4j2的组件有6921个，第二层依赖有超过3万个，第三层有超过9万个，第四层有超过16万个，总共有超过173104个组件。
将其绘制成图的形式进行展现，可以直观地发现右上黑色点的log4j2不光自身影响的组件多，还间接影响到了很多其他的热门组件，例如中间黄色点的elasticsearch和绿色点的druid，以及左上紫色点jedis、左下红色点mybatis均被大量引用。
2.java应用项目的影响
通过对GitHub和Gitee中的应用级项目依赖进行统计，我们发现约有5.8%的java项目直接使用了log4j2。筛选star大于1000的「高星」项目，其中约有13.3%直接使用了log4j2。
在GitHub中有人创建了项目来展现本次漏洞对企业和项目的影响（https://github.com/YfryTchsGD/Log4jAttackSurface），其公开的列表中包括许多知名的公司和软件，如：
- Apple
- VMWare
3.修复方案的选择
通过在GitHub中针对本次漏洞主要存在的三种修复方案进行统计发现：
- 绝大部分的开发者选择通过升级新版本进行漏洞修复
- 少部分项目通过将formatMsgNoLookups设置为False修复
- 极少项目选择了将jar包中的JndiLookup类移除
- 修复的时效性
通过对GitHub上的受影响项目统计，截止当前仍有89.4%的开源项目未修复。作为顶级基金会，也是本次漏洞的「当事人」，Apache基金会管理了超过1000个java项目，其中仍有33.4%未修复。
二、全球开源软件生态的健康发展亟需加强安全建设
作为整个开源软件生态的主要参与者，包括生产方（供应商）、分发方（开源代码平台、镜像托管平台、云厂商等）、使用方（企业和组织），目前在开源组件的安全控制上都需要加强投入，将开源组件的依赖管理、风险识别、缺陷修复纳入整个开源组件的生产、分发和应用的全过程，并且建立突发安全事件的应急处置机制和配套的工具平台。才能有效的保障一旦这样存在广泛影响的组件漏洞出现，能够及时的控制风险，降低对整个供应链上下游所带来的影响。
1.从生产方来讲，大规模被使用的开源组件应该建立漏洞应急处置的标准和要求，出现漏洞后及时发布修复补丁，且应该建立有效的触达受影响用户的渠道，及时通知用户进行修复，而此次事件的主角Log4j2组件仅仅只是三个开发者业余时间维护的项目。
2.从分发方的角度，以开源代码托管平台为例，在出现如此大的通用组件漏洞的情况下，应该具备更好的管控机制，及时有效的帮助开发者快速修复漏洞，并且在漏洞没有修复之前提示开发者谨慎下载相关有风险的开源项目代码。对于新发布到托管平台的项目应该进行风险的校验，降低有缺陷的开源组件发布，有效降低风险扩散。
3.从使用方的角度，企业和组织应该加入在组件引入、使用、上线的全过程管控，做好内部软件供应链的资产管理，做到全过程可追踪，风险能够及时响应和处置。
很显然从Log4j2漏洞事件的爆发和目前的影响来看，这些方面此次事件的官方项目组和国际主流的开源代码分发平台做的并不够好，反观这一次国内的官方组织、安全研究人员、企业、安全厂商却在此次事件中发挥了非常积极主动的作用，纷纷给出预警和漏洞检查工具。
三、作为企业应该如何有效控制所使用的软件供应链存在的安全风险
墨菲安全认为，可以从以下四个方面着手：
- 建立有效的管理机制：第三方软件供应链资产和风险管理本身可以做到很高的标准化，如同项目代码的bug率管理一样，企业应该将三方软件供应链的缺陷管理纳入研发的日常管理指标，同时提供配套的安全工具给予支撑。
- 供应链资产的识别和管理：从引入第三方供应链软件开始，建立持续的软件供应链资产管理平台，对企业办公及生产环境所有使用的软件供应链资产做到实时和动态的管理，资产要和具体的软件项目、员工做好关联，并建立配套的安全管理制度及配套工具平台，做到风险的持续量化管理。
- 漏洞缺陷的检测：针对识别的第三方软件供应链资产，应该在软件全开发流程中做好漏洞的检测，及时有效的发现存在的漏洞。特别需要关注的是漏洞和组件的匹配准确度和覆盖率，因为大多数外部漏洞库并没有给出准确的漏洞影响范围信息，这使得漏洞准确检测的难度大大提升。
- 高效的修复能力支撑：对于企业来说当前最难的问题应该是如何快速的修复这些漏洞。
对此，墨菲安全结合过往近十年的企业安全建设经验给出几点建议：
- 第三方组件的风险识别应该从组件引入环节开始做好控制，包括禁止高危组件的引入、将漏洞检测插件默认集成到开发者的IDE中；
- 需要在软件构建、测试、部署的全流程中集成三方软件的检测和修复能力；
- 持续获取三方组件最新漏洞情报
- 尽可能的将安全修复方案做得足够简单，这样和研发人员一起推进修复时才能更高效。
