前言
全球新一轮的产业数字化升级对开源软件的依赖日益提升,从而催生开源生态的蓬勃发展,而开源软件的全球化和开放共享的特性使得任何一个非常底层和基础的开源组件的漏洞都有可能像一个新冠病毒一样快速传播,对全球的数字化产业带来无法估量的影响。而这种影响的持续时间可能是3~5年,甚至更长。
一、关于Log4j2漏洞对开源生态的影响分析
01
其他开源组件的依赖
我们对log4j2的1~4层依赖关系进行了统计分析,可以发现直接依赖log4j2的组件有6921个,第二层依赖有超过3万个,第三层有超过9万个,第四层有超过16万个,总共有超过173104个组件。
将其绘制成图的形式进行展现,可以直观地发现右上黑色点的log4j2不光自身影响的组件多,还间接影响到了很多其他的热门组件,例如中间黄色点的elasticsearch和绿色点的druid,以及左上紫色点jedis、左下红色点mybatis均被大量引用。
02
java应用项目的影响
通过对GitHub和Gitee中的应用级项目依赖进行统计,我们发现约有5.8%的java项目直接使用了log4j2。筛选star大于1000的「高星」项目,其中约有13.3%直接使用了log4j2。
在GitHub中有人创建了项目来展现本次漏洞对企业和项目的影响(https://github.com/YfryTchsGD/Log4jAttackSurface),其公开的列表中包括许多知名的公司和软件,如:
Apple
VMWare
03
修复方案的选择
通过在GitHub中针对本次漏洞主要存在的三种修复方案进行统计发现:
绝大部分的开发者选择通过升级新版本进行漏洞修复
少部分项目通过将formatMsgNoLookups设置为true修复
极少项目选择了将jar包中的JndiLookup类移除
04
修复的时效性
通过对GitHub上的受影响项目统计,截止当前仍有89.4%的开源项目未修复。作为顶级基金会,也是本次漏洞的「当事人」,Apache基金会管理了超过1000个java项目,其中仍有33.4%未修复。
二、 全球开源软件生态的健康发展亟需加强安全建设
作为整个开源软件生态的主要参与者,包括生产方(供应商)、分发方(开源代码平台、镜像托管平台、云厂商等)、使用方(企业和组织),目前在开源组件的安全控制上都需要加强投入,将开源组件的依赖管理、风险识别、缺陷修复纳入整个开源组件的生产、分发和应用的全过程,并且建立突发安全事件的应急处置机制和配套的工具平台。才能有效的保障一旦这样存在广泛影响的组件漏洞出现,能够及时的控制风险,降低对整个供应链上下游所带来的影响。
三、 作为企业应该如何有效控制所使用的软件供应链存在的安全风险
建立有效的管理机制:第三方软件供应链资产和风险管理本身可以做到很高的标准化,如同项目代码的bug率管理一样,企业应该将三方软件供应链的缺陷管理纳入研发的日常管理指标,同时提供配套的安全工具给予支撑。
供应链资产的识别和管理:从引入第三方供应链软件开始,建立持续的软件供应链资产管理平台,对企业办公及生产环境所有使用的软件供应链资产做到实时和动态的管理,资产要和具体的软件项目、员工做好关联,并建立配套的安全管理制度及配套工具平台,做到风险的持续量化管理。
漏洞缺陷的检测:针对识别的第三方软件供应链资产,应该在软件全开发流程中做好漏洞的检测,及时有效的发现存在的漏洞。特别需要关注的是漏洞和组件的匹配准确度和覆盖率,因为大多数外部漏洞库并没有给出准确的漏洞影响范围信息,这使得漏洞准确检测的难度大大提升。
高效的修复能力支撑:对于企业来说当前最难的问题应该是如何快速的修复这些漏洞,企业应该考虑如何将安全能力低侵入的融合到企业的开发流程中去。
建议
第三方组件的风险识别应该从组件引入环节开始做好控制,包括禁止高危组件的引入、将漏洞检测插件默认集成到开发者的IDE中;
需要在软件构建、测试、部署的全流程中集成三方软件的检测和修复能力;
持续获取三方组件最新漏洞情报;
尽可能的将安全的修复方案做的足够简单,这样和研发人员一起推进修复的时候才能更高效。