Apache Log4j 2安全漏洞
最近，Apache Log4j 2 漏洞闹的甚嚣尘上。Apache Log4j 2 是一个基于 java 的日志组件，被广泛应用于与 java 语言相关的软件或组件中。由于 java 在编程语言中的市场份额非常高，所以此次漏洞带来的影响非常大。各企业或组织都采取了积极的措施来应对此次漏洞事件。
此次漏洞的ID为CVE-2021-44228，关于此次漏洞的详细内容及修复手段，我们建议查看CVE官网[1]或者 NVD官网[2]。一切以官网解释为准。
首先，需要说明的一点是极狐GitLab以Ruby，Go为主要语言，所以此次漏洞并未对极狐GitLab产品产生影响。具体的讨论大家可以在这儿[3]查看阅读。但是众所周知，极狐GitLab 是一个一体化的 DevOps 平台，同时具备很强的安全功能，其 DevSecOps 有七大功能：容器镜像扫描、静态应用安全测试 (SAST)、动态应用安全扫描（DAST）、密钥检测、License合规、依赖项扫描以及模糊测试。极狐GitLab DevSecOps 功能能够精准的扫描此次漏洞。
极狐GitLab Dependecny scanning扫描Apache log4j 2漏洞
01 极狐GitLab Dependency scanning
Dependency scanning[4]是极狐GitLab DevSecOps的重要功能之一。可以对多种语言（Ruby、PHP、Java、Python、C#等）进行依赖扫描。核心原理是以 Gemnasium[5]为扫描器（analyzer），对特定语言的特定文件（如 java maven项目的pom.xml）进行扫描，通过和漏洞数据库的对比，进而发现存在漏洞的依赖项，最后出具详细的漏洞报告。当然，最重要的是这种安全扫描可以和MR、CI/CD进行无缝集成，打造端到端的DevSecOps交付。
02 扫描示例
下面以java maven项目为例演示极狐GitLab DevSecOps的Dependency scanning功能。
java maven项目的目录结构如下：
pom.xml文件中，关于log4j的依赖描述如下：
Hello.java 的内容如下：
接着将上述代码放到一个目录下，用如下命令来启动一个analyzer环境：
可以看到，容器里面安装了 analyzer，用 --help 来查看用法：
用 ./analyzer run --target-dir $CODE_PATH 即可完成依赖扫描，如所示：
./analyzer run --target-dir /code/
Using java version adoptopenjdk-11.0.7+10.1
[INFO] [gemnasium-maven] [2021-12-15T04:34:40Z] ▶ GitLab gemnasium-maven analyzer v2.24.2
[INFO] [gemnasium-maven] [2021-12-15T04:34:40Z] ▶ Detected supported dependency files in .. Dependency files detected in this directory will be processed. Dependency files in other directories will be skipped.
[INFO] [gemnasium-maven] [2021-12-15T04:34:46Z] ▶ Using commit edc7d7c91ad784d984dac2ad
of vulnerability database
在扫描路径下有一个名为gl-dependency-scanning-report.json的扫描报告文件:
在报告里面可以看到，已经扫描出此次 log4j 2 的漏洞，ID为CVE-2021-44228，并且给出了CVE和NVE的链接、修复措施等其他详细内容，如下图所示：
当根据扫描报告给的修复策略，将log4j相关组件升级到2.16.0即可修复此次漏洞，接着可以再次扫描，发现报告中没有与log4j相关的漏洞数据了，如下图所示：
为了进一步验证极狐GitLab Dependency Scanning 的准确性，以此次受影响flink(1.14.0)[6]为例进行了一次扫描，在
flink/flink-connectors/flink-connector-elasticsearch-base目录下进行扫描，其 pom.xml 文件对 log4j 的描述如下：
扫描结果如下：
可以看出，扫描出了 CVE-2021-44228 这个漏洞。当然，flink 最新版本已经没有这个漏洞了。上述流程可以无缝和极狐GitLab CI/CD 进行集成，从而真正做到 DevSecOps 提倡的“安全左移”以及“安全持续自动化”。我们会在后续的文章详细解析。
在此，我们也呼吁使用log4j 2组件的用户及时更新相关组件、软件来保证自己软件的安全。
Apache Log4j 2 安全漏洞启示录
此次 Apache log4j 2 漏洞是一个比较典型的软件供应链安全漏洞案例。log4j 是一款开源软件（从漏洞爆发之后的相关新闻可以看到，此项目的维护者是利用自己的的业余时间在维护这个至关重要的组件），是软件供应链的 upstream，而众多用户（企业、组织、个人）是 downstream，这种 upstream 组件受影响，进而导致大面积 downstream 受影响，就是典型的软件供应链安全特征：upstream 的一点可以影响 downstream 整个面，范围广，影响大。
此次漏洞也带来一些思考：
• 安全漏洞无法避免
安全漏洞伴随着软件的诞生而产生，是无法避免的。只要用合适的手段去尽早发现安全漏洞，及时制定修复策略，就可以避免自己所在的企业或组织遭受因安全漏洞带来的重大安全风险甚至经济损失。比如近些年常见的 DevSecOps 就是一种非常好的保障软件安全交付的理念。将安全贯穿在软件研发的整个生命周期中，人人为安全负责，进而保障软件的安全交付。
• 开源软件供应链安全
开源改变了软件的交付模式，开源的采用率也在大大提高。但是开源带来的风险也在增加。像 log4j 这样现代软件基石的开源软件还有很多，比如 openssl。一旦这些基石发生安全漏洞，就会造成很大的影响。因此，软件安全应该上升到软件供应链安全这个层次，也就意味着需要软件研发、分发、流通的各个环节都能够保持足够的透明，加上多方的通力协作与沟通，进而保证软件的安全。关于开源软件供应链安全的详细内容可以查看文章开源时代：开源时代，极狐GitLab 是如何保证软件供应链安全的 。
• Upstream First
Upstream first 理念是参与开源贡献的正确方式：所有的贡献（功能开发、软件分发、漏洞修复、决策制定）都发生在 upstream。一旦有发现安全漏洞，就在 upstream 直接进行修复，这样所有下游只需要更新相关软件版本即可。关于 Upstream first 理念，可以查看文章 Upstream First：参与贡献开源项目的正确方式 。