【技术分享】猪八戒网DevOps之Java组件安全检测

标准检测： 开发人员通过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跑批量检测。

诚 邀各位IT大佬加入我们“西南名猿交流群”

一个交流技术、招聘的场地

全国程序猿皆可扫码上车噢～