一、文章摘要
应用安全一直是一个非常重要的课题，2021年12月7日Log4j2爆出核弹级漏洞，Log4j2作为一款优秀的日志框架，其高使用率加上此漏洞利用难度低，导致企业安全风险剧增。那么猪八戒网是如何应对此类漏洞的呢？
此文主要讲述猪八戒在Java组件安全方面实施的防护措施，如何阻断存在安全漏洞的Java应用上线，在出现类似Log4j2这样的漏洞后如何及时发现哪些应用存在安全风险，同时也为猪八戒的研发小伙伴解惑，我们是如何扫描出你代码中的漏洞组件的。
二、检测流程
标准检测：开发人员通过DevOps 发布应用到测试环境，在Jenkins进行构建生成应用Jar包或者War包，此时执行安全检测脚本对生成物进行安全检测，并将应用引入的组件名称和版本号上报至SDLC安全审核平台，安全审核平台使用其配置的安全规则进行检测，例如此次爆发的Log4j2漏洞，会检测上报的log4j-core版本是否是存在漏洞的版本，如果是则同步返回给Jenkins中断本次发布，并发送漏洞信息给相关人员。
批量检测：由于猪八戒网绝大部分应用都是通过DevOps流水线发布，所以绝大部分应用的组件版本信息在SDLC安全审核平台都有记录，但由于某些项目是历史项目，则可以通过非标准流程，即通过CMDB批量作业平台执行安全检测脚本将组件名称和版本号上报至SDLC安全审核平台，至此实现了历史全量Java应用漏洞扫描。
三、如何实现毫秒级检测
Java应用依赖组件的检测，第一种思路就是通过项目所使用的构建工具，使用构建工具的命令列出所有依赖的组件，如Maven可以使用mvn dependency:tree或mvn dependency:list 列出应用所有依赖的组件和组件版本，然而这种方案的缺点也很明显，此种检测比较重，由于依赖特定的构建工具，所以对我们CMDB批量检测不是很好实现，对现有的CI/CD过程也会带来一定风险。由于我们的项目在一个应用中分了多模块开发，要执行mvn dependency:tree 命令，需要使用mvn install将多模块安装在本地仓库，而我们构建Java 项目时执行的是mvn package ，在多模块开发的应用中，并不需要将多模块中的jar安装到本地仓库和私服中。mvn install会将模块打包安装到本地仓库，一是构建耗时增加，二是将模块打到本地但并没有上传到私服，会不会导致被其他项目引用到，导致代码出现非预期情况？虽然此种情况比较极端，但是我们还是要规避。
那么有没有更好的方案呢？第二种思路是绕过构建工具这一层，直接从构建好的Jar包或者War包入手，不管是jar还是war都会将依赖组件放到/lib目录下，基于这些规律，我们做如下实现。
第一步：我们使用jar vtf xx.jar |grep lib 提取lib/目录下的所有包信息。
第二步：用脚本将依赖jar包的artifactId和version解析出来。
第三步：将artifactId和version信息上报至SDLC安全审核平台，触发漏洞检测并返回检测结果，流水线根据结果选择阻断或者继续。
整个过程耗时不超过1秒，实现了毫秒级检测。并且脚本可实现通用，不受构建工具制约，方便通过CMDB跑批量检测
四、如何应对突发漏洞
以上是正常流程，可以规避应用引入已知的漏洞。那么突发安全漏洞，我们怎么快速发现哪些应用存在安全风险呢？由于应用每一次发布都会将组件和版本信息同步至SDLC安全审核平台，所以从SDLC平台筛选组件名称和存在漏洞的版本即可找到哪些应用存在漏洞，并及时通知相关负责人进行漏洞修复。
至此，面对类似Log4j2这样的突发安全事件，我们有了抓手，可以有效从容应对。
希望以上内容能对有需要的人有所帮助
欢迎大家一起探讨交流
